Is it okay to define trivial built-in methods based on the project's debug / release -state twice?
I've always wondered if it's a good or bad practice to define a trivial method twice, depending on
if the project is on debug / release -state. This is for their inlay. For example Foo.h:
class Foo
{
public:
...
const bool& IsBoolean() const;
private:
bool _boolean;
};
#ifndef _DEBUG
/** We're in release, so let advice compiler to inline this...
*
*
*/
inline const bool& Foo::IsBoolean() const
{
return _boolean;
}
#endif
And now, in Foo.cpp:
#include "Foo.h"
...
#ifdef _DEBUG
/** We're debugging this, no need for inlining...
*
*
*/
const bool& Foo::IsBoolean() const
{
return _boolean;
}
#endif
Is it really useless? For example, because of the ability of the compiler (MSVC) to inline / optimize the methods yourself?
However, this is what I have been using for years. Please correct me if I am completely wrong here ...
a source to share
This is a waste of time for several reasons.
The inline keyword is a hint that the compiler can ignore at will. The same as in the public domain, even if the keyword is not specified. So, if you add it, it probably won't change anything for the compiler
Also, any functions defined inside a class definition are implicitly inlined. This is why short functions like getters and setters are almost always defined inside a class definition.
Further, if you want to mark a function inline, there is no reason not to do so in debug builds.
The keyword has inline
almost nothing to do with the compiler actually overlaying the functions. These are separate concepts. A feature marked by the inline
programmer means that the linker shouldn't worry if it sees multiple identical definitions. This usually happens if a function is defined in a header that is included in multiple compilation units. If the function is checked on a line, the linker will merge the definitions together. If not, you will receive an error message. In other words, adding and removing this keyword will cause compiler errors. This may not be what you want.
The only reason there is a match between the C ++ keyword inline
and compiler optimizations is that if a function is marked as inline
, it is # safe to include it in every compilation block, which means the definition will always be visible when the function is called. And it makes it easier for the compiler to inline function calls.
Finally, inlining is not always a performance improvement. It's easy to create a situation where nesting does nothing more than build up your code size, cause more cache misses, and generally slow down your code. This is one of the reasons it is inline
(at best) considered a hint by the optimizer. In the worst case, it is completely ignored.
So what you do is 1) cause compiler errors in debug mode that were not present in release builds, and 2) do not affect performance.
a source to share
Looks like a waste of space and unnecessary code duplication. Usually the compiler is very capable of determining which functions are built in and which are not. Even more so if you are using MSVC which has a /LTCG
(Link Time Code Generation) switch which means your trivial methods are going to be inlined even if they are in cpp.
a source to share
The easiest way to do what you want is to put the code in your own filename.inl, and then conditionally include the file either in the header or in the source file. You also need to prefix the functions in the .inl file with a conditional macro that expands to a line if the file is included in the header and in an empty macro.
a source to share