Using a function declaration at the top of your function, then later defining it under main seems a bit redundant. Considering the practices of DRY, is standard practice in the C++ community to simply declare the function fully at the top (or even just define in a seperate functions.cpp file, with declarations in the header.hpp file), rather than declare then later define?
I realize that all ways would produce the same result, but I would like to hone in on my formatting skills, and eliminate redundancy. Why declare then later define as opposed to just defining at the top before main? Perhaps this is a tabs vs. spaces type of debate, but maybe thats all I need to know lol
Thanks!
There are cases where you have no choice other than first providing a declaration and then the definition. For example when there is mutual dependency:
int bar(int x);
int foo(int x) {
if (x == 1) return bar(x);
return x;
}
int bar(int x) {
if (x==0) return foo(x);
return x;
}
Seperating declaration and definition is not considered a violation of DRY or as redundant. Probably the most common is to have declarations in headers and definitions in source files.
There may be some cases that you have to provide function signature in advance, and its implementation only later at some point. The best example is the cyclic dependency of functions, so one needs to be defined before the other one, making a closed loop.
Related
I am learning multiple file compilation in C++ and found practice like this:
#ifndef MY_LIB_H
#define MY_LIB_H
void func(int a, int b);
#endif
Some people say that this practice is adopted to avoid repeating declarations.
But I try to declare a function twice and the code just runs well without any compilation error (like below).
int func();
int func();
int func()
{
return 1;
}
So is it really necessary to avoid repeating declarations? Or is there another reason for using #ifndef?
Some people say that this practice is adopted to avoid repeating declarations.
If some people say that then what they say is misleading. Header guards are used to avoid repeating definitions in order to conform to the One Definition Rule.
Repeating declarations is okay. Repeating definitions is not.
int func(); // declaration
int func(); // declaration; repetition is okay
class X; // declaration
class X; // declaration; repetition is okay
class Y {}; // definition
class Y {}; // definition; repetition is not okay
If a header consists only of declarations it can be included multiple times. But that's inefficient: the compiler has to compile each declaration, determine that it's just a duplicate, and ignore it. And, of course, even if it consists only of declarations at the moment, some future maintainer (including you) will, at some point, change it.
So is it really necessary to avoid repeating declarations?
You can have multiple declarations for a given entity(name). That is you can repeat declarations in a given scope.
is there another reason for using #ifndef?
The main reason for using header guards is to ensure that the second time a header file is #included, its contents are discarded, thereby avoiding the duplicate definition of a class, inline entity, template, and so on, that it may contain.
In other words, so that the program conform to the One Definition Rule(aka ODR).
what's the difference between the following 3 cases:
1) in point.h:
class point
{
int x,y;
public:
int getX();
};
int point::getX() {
return this->x;
}
2) in point.h:
class point
{
int x,y;
public:
int getX()
{
return this->x;
}
};
3) in point.h:
class point
{
int x,y;
public:
int getX();
};
int point.cpp:
int point::getX() {
return this->x;
}
Note: I read that it's somehow connected to inline but not sure which one of them makes the compiler to treat int getX() and inline int getX()
Avoid this first one:
struct point
{
int x,y;
int getX();
};
int point::getX() {
return this->x;
}
If multiple source files include point.h, you will get multiple definitions of point::getX, leading to a violation of the One Definition Rule (and modern linkers will give an error message).
For the second one:
struct point
{
int x,y;
int getX()
{
return this->x;
}
};
This implicitly inlines the function. This means that the function definition may be copy-pasted everywhere it is used, instead of resolving a function call. There are a few trade offs here. On one hand, by providing definitions in headers, you can more easily distribute your library. Additionally, in some cases you may see performance improvements due to the locality of the code. On the other hand, you may actually hurt performance due to instruction cache misses (more instructions around == it won't all fit in cache). And the size of your binaries may grow as the inlined function gets copied around.
Another tradeoff is that, should you ever need to change your implementation, all clients must rebuild.
Finally, depending on the sensitivity of the function, you may be revealing trade secrets through your headers (that is, there is absolutely no hiding of your secret sauce) (note: one can always decompile your binary and reverse engineer an implementation, so putting the def in the .cpp file won't stop a determined programmer, but it keeps honest people honest).
The third one, which separates a definition into a .cpp file:
// point.h
struct point
{
int x,y;
int getX();
};
// point.cpp
int point::getX() {
return this->x;
}
This will cause a function to get exported to your library (at least for gcc. In Windows, you need to be explicit by using __declspec directives to import/export). Again, there are tradeoffs here.
Changing the implementation does not require clients to recompile; you can distribute a new library for them to link to instead (the new library is ABI-compatible if you only change the impl details in the .cpp file). However, it is more difficult to distribute your library, as your binaries now need to be built for each platform.
You may see a performance decrease due to the requirement to resolve function pointers into a library for running code. You may also see a performance increase over inlining due to the fact that your code may be friendlier to the instruction cache.
In the end, there is a lot to consider. My recommendation is to go with #3 by default unless you are writing templates. When you want to look at improving performance, you can start to measure what inlining does for you (binary size as well as runtime perf). Of course you may have other information up front that makes approach #2 or #3 better suited for the task (e.g., you have a Point class, and you know that accessing X will happen everywhere and it's a really small function, so you decide to inline it).
what's the difference between the following 3 cases
The function definition is outside of the class definition. Note that in this example you've defined a non-inline function in a header. Including this header into more than one translation unit violates the One Definition Rule. This is most likely a bug.
The function definition is inside of the class definition. In this case, the function is implicitly inline. As such, it is fine to include it into multiple translation units.
The function definition is outside of the class definition again. The function is not declared inline. This time the function is defined in a separate translation unit, thereby conforming to the ODR even if the header is included into multiple translation units.
what's the problem if both b.cpp & a.cpp includes my header file
The problem is that then both b.cpp and a.cpp will define a non-inline function. The One Definition Rule says that there must be at most one definition of any inline function. Two is more than one. Therefore doing this violates the ODR and therefore such program would be ill-formed.
I'm too much confused why it's an error to write the same function in two different cpp files?
It is an "error" because the rules of the language (explained above) say that it is an "error".
what if both want to use that function?
Then declare the function in both translation units. Only define the function in one translation unit unless you declare the function inline, in which case define the function in all translation units (where the function is used) instead. Look at the examples 2. and 3. of your question to see how that can be done.
so the code in method 1 is not automatically inlined?
No. Functions are not automatically declared inline. Function is declared inline only if A. inline keyword is used, or if B. it is a non-static member function that is defined within the class definition (or in a case involving constexpr that I shall omit here). None of those cases apply to the example 1, therefore it is not an inline function.
Consider the following four member function declarations and definitions:
// ==== file: x.h
#ifndef X_H
#define X_H
class X {
public:
int a(int i) { return 2 * i; }
inline int b(int i) { return 2 * i; }
int c(int i);
int d(int i);
};
inline int X::c(int i) { return 2 * i; }
int X::d(int i) { return 2 * i; }
#endif
For completeness, here's the .cpp file that instantiates an X and calls the methods...
// ==== file: x.cpp
#include "x.h"
#include <stdio.h>
int main() {
X x;
printf("a(3) = %d\n", x.a(3));
printf("b(3) = %d\n", x.b(3));
printf("c(3) = %d\n", x.c(3));
printf("d(3) = %d\n", x.d(3));
return 0;
}
My question: are there any salient differences among the four methods? I understand from a comment in this post that the compiler may automatically inline methods that are defined in the class definition.
update
Many answers assume that I'm asking about the difference between inlining and not. I'm not. As I mentioned in the original post, I understand that defining a method in the header file gives the compiler license to inline the method.
I also (now) understand that method d is is risky as written: since it is not inlined, it will be multiply defined if there are multiple translation units.
My question remains: are there any salient differences among the four methods? (As noted, I know that method d is different). But -- just as important -- are there stylistic or idiomatic considerations that would make a developer choose one over the others?
Since this answer keeps getting upvotes, I feel obligated to improve it. But much of what I'm adding has already been stated in other answers and comments, and those authors deserve the credit.
On the subject of whether there's a difference between placing a function body inside the class definition or just below it (but still in the header file), there are 3 different cases to think about:
1) The function is not a template and is not declared to be inline. In this case it must be defined in the class definition or a separate cpp or you will get a linker error as soon as you try to include the h in more than one compilation unit.
2) The function is a template, but is not declared inline. In this case, putting the body within the class definition provides a hint to the compiler that the function can be inlined (but the final decision is still at its own discretion).
3) The function is declared to be inline. In this case there is no semantic difference, but it may sometimes be necessary to place the function body at the bottom in order to accommodate dependency cycles.
Original answer, which provides good info but does not address the actual question:
You've already noted the inline difference. In addition, defining member functions in the header means your implementation is visible to everyone. More importantly, it means everyone who includes your header also needs to include everything needed to make your implementations work.
If you are going to inline it regardless, then you'd move it out of the class if you want to be able to see all your members in one screen, or you have a cyclic dependency as mentioned below. If you don't want to inline it, then you have to move it out of the class and into an implementation file.
In the cases of classes that cyclically refer to each other, it may be impossible to define the functions in the classes so as to inline them. In that case, to achieve the same effect, you need to move the functions out of the classes.
Doesn't compile:
struct B;
struct A {
int i;
void foo(const B &b) {
i = b.i;
}
};
struct B {
int i;
void foo(const A &a) {
i = a.i;
}
};
Does compile, and achieves the same effect:
struct B;
struct A {
int i;
inline void foo(const B &b);
};
struct B {
int i;
inline void foo(const A &a);
};
inline void A::foo(const B &b) {
i = b.i;
}
inline void B::foo(const A &a) {
i = a.i;
}
Oops, just realised you had the definitions in the header file. That creates problems if the include file is included in more than one place.
If the functions are defined in a CPP file then there is no difference.
The only time it makes sense to implement a function inline is when the function is very clearly trivial and/or it has performance implications.
For all other times, it's best to put them in a .cc file and keep its implementation not exposed to the user of the class.
As pointed out by user3521733, it is impossible to implement some functions in the header file when there are cyclic dependencies. Here you are forced to put the implementations in a .cc file.
Update
As far as the compiler, and the runtime, is concerned, there is no difference that I can think of between defining the function inside the body of the class or outside if you use inline when defining it outside the body of the class.
X::a, X::b and X::c are all inlined. X::d is not. That's the only real differnce between these functions, aside from the fact that they are all different functions. The fact that X::c is defined in the header is irrelevant. What is relevant there is that the definition is marked inline.
In order to understand what the differences are, it's important to understand what inline is and is not. inline is not a performance tweak. It's not about making your code faster, and it's not about blowing the code out inline.
What it is about is the ODR. A function marked inline will have the exact same definition in each translation unit where it is used.
This comes in to play when you try to #include your file above in two or more CPP files and call X::d in those translation units. The linker will complain that X::d is defined more than once -- you've violated the ODR. The fix to this is to either mark the function inline or move the definition to it's own translation unit. (eg, to a CPP file)
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.
Learning C++ and see the class laid out like this:
class CRectangle {
int x, y;
public:
void set_values (int,int);
int area () {return (x*y);}
};
void CRectangle::set_values (int a, int b) {
x = a;
y = b;
}
I know Java and methods(functions) in Java are written within the class. The class looks like a Java interface. I know I can write the class like this:
class CRectangle {
int x, y;
public:
void set_values (int a, int b) {
x = a;
y = b;
};
int area () {return (x*y);}
};
But is there a difference or standard?
There's a difference. When you write the definition of the function within the class definition (case 2), then the function is considered to have been declared inline. This is standard C++.
Usage, is to declare the member functions (Java methods) within the class definition, in a header file (.h), and to define these member functions in a C++ file (.cpp, .cc, or .C, …) This reduces compilation time, when you change the body of a function, only the C++ file has to be compiled, whereas if you change something in the header file, all C++ files that include this header are to be compiled.
It's much cleaner if you only define prototypes in the class definition (which belongs into a header file) and implement the methods in a cpp file.
When you have very small classes doing everything in the class definition might sound easier since everything is at the same place, but as soon as your class grows any developer using it will hate you since he'll have your code between the method prototypes he might look at to find out something (not everyone uses an IDE which shows all available methods!).
However, there is one exception: Template class methods needs to be implemented in the header as they need to be compiled for every specialization of the template.
The usual way is to put the implementation of functions within a separate cpp file, which is not included by other files, just compiled. This way it is easier to manage dependencies.
If the implementation of a function is given within the class definition (as in your 2nd example), this is a hint for the compiler to inline that function (which it may or may not do in the end, depending on e.g. the internals of the function). As a rule of thumb, function bodies longer than a few lines of code are better put into the cpp file, as these are probably not going inlined, however these may include extra dependencies and clutter the class definition.
The exception is template functions, where the bodies need to be in the header too, for the compiler must see them in order to instantiate the template.
I believe that if the method body is inside the class definition, then it is inlined everywhere is it called.
In C++, member functions which are defined in class are implicitly inline, member functions defined outside the class are not.
This affects the linkage of your two examples - the linker will complain about multiple definitions if the first example is #included in multiple source files, whereas the second example will not.
In terms of what's standard/normal:
The first form is used for complex classes, where the implementation of the functions requires extra headers to be pulled in.
The second form is used for simple classes which don't have extra dependencies.
Either form is used for template classes based on developer preference.
There is a slight difference in that functions defined inside the class are automatically inline. The latter definition can be put into a separate file. Otherwise there is no difference nor preference.
Note that we usually don't write semicolons after function definitions (though they are allowed inside a class definition).
void set_values (int a, int b) {
x = a;
y = b;
} // no semicolon here