Style: Inline on the function declaration [duplicate] - c++

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
When should I write the keyword 'inline' for a function/method?
I am not 100% sure, but as far as I know, if I declare a function on an hpp file with the body it will be treated as it is marked as inline(the compiler will decide what to do), I mean:
//myfile.hpp
class StackOverflow{
public:
void overflow(){_overflow = true;}
...
}
would be the same than:
//myfile.hpp
class StackOverflow{
public:
***inline*** void overflow(){_overflow = true;}
...
}
If I am wrong then the question is over, but otherwise, I really like to mark as inline a function even it is not necessary, does general code style guidelines say soemthing about it?
Thanks so much

As the mention of the keyword inline in this context gives no information whatsoever, leave it out. It’s simply visual clutter.
If there were an option to make an inline-defined function non-inline, this would be a different matter (consider private-by-default as such an example): here, it could be argued that even though it’s the default, making the choice explicit makes it easier to understand. But there’s no choice here. No matter what you do, a member function defined inside the body of a class is inline.
In fact, marking it explicitly as inline would be akin to providing other inferred information. You wouldn’t write the following, would you?
#define member
#define function
class StackOverflow{
public:
member function inline void overflow() { _overflow = true; }
}

Defining a function body inside the class definition makes the function implicitly same as marking it with keyword inline.
As a matter of coding style,
Just defining the function body inside the class is not a good practice.
class Foo {
public:
void method(); ← best practice: don't put the inline keyword here
...
};
inline void Foo::method() ← best practice: put the inline keyword here
{ ... }
This C++ Faq explains the rationale:
class Fred {
public:
void f(int i, char c)
{
...
}
};
Although this is easier on the person who writes the class, it's harder on all the readers since it mixes "what" a class does with "how" it does them. Because of this mixture, we normally prefer to define member functions outside the class body with the inline keyword.
The insight that makes sense of this: in a reuse-oriented world, there will usually be many people who use your class, but there is only one person who builds it (yourself); therefore you should do things that favor the many rather than the few.

If you declare a function as inline inside of the class, for one just like the register keyword, it's open for the compiler to determine (it's a suggestion) if it's a wise optimization to make. Generally, it's a rule of thumb to use inline functions programmed inline inside of the class itself, however it can be done in the implementation of the class as well, though is not common and the only benefit it offers is the linkage, should you decide to pass out the .h/.hpp file as an API header.

Related

In C++, how to write full implementation in header for classes and functions (possibly templated)

I usually declare in header file and implement in cpp file, but now I am doing an assignment, and, apparently for brevity, the instructor doesn't want me to do that, but insists that I write all the code in header files.
So, what is the best way to do that?
For classes, should I declare everything first, and then go to the bottom of the page and start implementing?
class myClass
{
void myMethod();
}
void myClass::myMethod() { //.... }
or should I just implement as I declare
class myClass
{
void myMethod() { //... } ;
}
What about free functions?
And when should I write "inline"?
or should I just implement as I declare
Yes, implement them in class, not out of class. When the (questionable) reasoning of your instructor for putting everything into a header refers to brevity, this is obviously the way to go.
What about free functions?
Same as with member functions, define them on the go.
And when should I write "inline"?
You should add inline to all ordinary free functions. It's unnecessary for function templates or in-class member function definitions. When you can use C++17, consider inline variables, too.

inline constructor and destructor in cpp file

As weird as the question sounds, I meant when a class is defined solely in cpp file because it is more of less a helper class for the implementation of another class and doesn't deserve to be in its private section. I understand that inlining constructor and destructors is a bad practice, but what about this situation, demonstrated as follows? Thank you very much
EDIT: I should have reworded it. In some cases inlining constructor and destructors causes bloated code unexpectedly(as discussed in Effective C++ Item 30, "Understand the ins and outs of inlining"). However I would like to know if such inlining demonstrated resulted in that as well
// my_class.cpp
#include <my_class.h>
namespace {
class Helper
{
public:
Helper() {...} // should I inline the constructor here?
~Helper() {...} // should I inline the destructor here?
};
/* alternative implementation looks like
Helper::Helper()
{...}
Helper::~Helper()
{...}
*/
} // end of anonymous namespace
// implementation of my_class
This is probably a moot point. Another discussion here discusses this to a good degree. The basic take away is that the compiler may ignore your "inline" or it may choose to "inline" the function/constructor/whatever without your input. The inline command is simply a suggestion that the compiler is free to ignore.
TL;DR Go for it; it probably isn't going to make a difference.
It's fine either way. If ever a helper function becomes a performance bottleneck because it is not inlined, you might consider making it an inline function.
Many times I find that a single instance of the Helper class is adequate for use by the main class. Hence, whether the constructor and destructor are inlined or not does not make any difference at all.
namespace {
class Helper
{
public:
Helper() {...}
~Helper() {...}
};
// The sole instance of the Helper class.
static Helper helper;
}
void main_class::foo()
{
helper.foo();
}

C++: Do function wrappers work with inline?

If you've enabled full optimizations in your compiler and have classes setup like this:
class A
{
void Do_A_Stuff();
};
class B
{
A a;
void Do_B_Stuff() { a.Do_A_Stuff(); }
};
class C
{
B b;
void Do_C_Stuff() { b.Do_B_Stuff(); }
};
class D
{
C c;
void Do_D_Stuff() { c.Do_C_Stuff(); }
};
Is there ever a situation where calling Do_D_Stuff() would be slower than directly calling Do_A_Stuff()? Also, would this require the inline keyword on each wrapper 'chain' or, since it is only a suggestion, could the compiler decide to optimize this without the keyword?
I realize there is a lot of information about inlining available, but I could not find any information specifically about chaining many wrappers together.
Also, would this require the inline keyword on each wrapper 'chain' or, since it is only a suggestion, could the compiler decide to optimize this without the keyword?
Yes, the compiler could decide to optimize it anyway, and it could also decide not to optimize it even if you specified the inline keyword (possibly producing a warning if the appropriate compiler options are set) - notice, that member functions defined in a class definition are implicitly marked as inline.
In general, if inlining is possible, the compiler will decide whether to inline or not based on the body of the function being called. However, inlining may not be possible at all if the function is a virtual function, or if the definition of the function is not visible to the compiler.
Provided that the conditions for inlining are satisfied and that the compiler considers it appropriate, there is no technical problem in inlining over a chain of function calls.
As a minor remark, notice that the functions in your classes should be public, otherwise they won't be accessible to your wrappers.
The functions are defined inside the class definition, so the inline keyword is implicit in this case.

Template meta programming inlining

First look at these templates.
struct INIWindows{
inline int GetInteger(){
return 100;
}
};
struct INILinux{
inline int GetInteger(){
return 120;
}
};
template <class Reader>
class SettingsManager : public Reader{
};
Edit: Addendum because it was not clear what i was doing.
int main(){
SettingsManager<INIWindows> Settings;
printf("Integer Reads %i\n",Settings.GetInteger());
system("pause");
return 0;
}
Is my understanding correct that this will result in SettingsManager having an inline function called get integer that will then be inlined properly by the compiler?
Is my understanding correct that this will result in SettingsManager having an inline function called get integer that will then be inlined properly by the compiler.
Yes, your understanding is correct. Your methods are going to be placed in the SettingsManager class, without a virtual dispatch, because the base classes (INIWindows and INILinux) do not have virtual methods.
The inline keyword is only a command for the compiler to try to inline the method - nothing else. It is free not to do it.
inline makes no sense inside a class. If you had defined the functions outside a class then it would indicate internal linkage. But in your current code does not serve any purpose whatsoever: all functions defined in a class are inline.
For the compiler, inline simply means that the name is no visible outside the compilation unit. In this regard, it’s similar to global static. Other than that, the compiler is free to perform function call inlining any way it wants.
In particular, the optimiser may choose to replace a call by the contents of a function. This is what you want, but it’s (almost completely) unrelated to the inline keyword, despite its name.
(By the way, this is unrelated to templates and template metaprogramming.)

Putting all methods in class definition

When I use the pimpl idiom, is it a good idea to put all the methods definitions inside the class definition? For example:
// in A.h
class A {
class impl;
boost::scoped_ptr<impl> pimpl;
public:
A();
int foo();
}
// in A.cpp
class A::impl {
// method defined in class
int foo() {
return 42;
}
// as opposed to only declaring the method, and defining elsewhere:
float bar();
};
A::A() : pimpl(new impl) { }
int A::foo() {
return pimpl->foo();
}
As far as I know, the only problems with putting a method definition inside a class definition is that
(1) the implementation is visible in files that include the class definition, and
(2) the compiler may make the method inline.
These are not problems in this case since the class is defined in a private file, and inlining has no effect since the methods are called in only one place.
The advantage of putting the definition inside the class is that you don't have to repeat the method signature.
So, is this OK? Are there any other issues to be aware of?
I think you answered your own question : both solutions are equivalent.
However, I wouldn't be so sure that 'inlining has no effect since the methods are called in only one place' : an additional call could exists when the functions are not inlined. But chances are that the compiler is smart enough to optimize them away from the one-line forwarding calls in the outer class.
In the end, I believe it's just a matter of taste.
Advantages:
all code of the class is localized
Disadvantages:
for larger classes: when scrolling is needed, it becomes more difficult to know to which class the function belongs.
dependencies are more easily solved when functions reside after all class declarations. Otherwise, it might be needed that some class declarations are moved after others and some functions still have to be moved after the class declaration when there are mutual dependency of internal classes.
Usually I don't add methods to the Impl inner class, but I can't see any issue if you define the methods inline. It seems to me much more readable than having seperate declaration and definition.
Whether the compiler inlines the methods depends on the compiler and the passed parameters.
In the case of the pimpl idiom, I don't think it matters whether the methods are defined within the Imp's body or not. I personally like them defined outside, because it is easy to see what is really important (like member variables and list of methods).