Reputation: 36050
There are lots of similar answers to this question such as this one:
Stack overflow will prbably say I have a duplicate question but I still do not understand after looking into all the similar questions why people discourage this code:
#ifndef _FOO
#define _FOO
// my comment that I only have to write once
int some_method()
{
return 1;
}
#endif
Call this foo.cpp
. Why will it be bad practice to do something like this where foo.h
is excluded? Compile time will be slower but how much slower? I believe it will be milliseconds slower. Why is being lazy a bad thing (https://stackoverflow.com/a/9253825/637142). I just want to write something that works, is well documented etc..
Benefits I see when using this technique are:
I do not have to write comments twice. If I decide to change the comments of a function I will also have to change the comments on the header file.
If I change the signature of a method then I will also have to change it on the header file.
I use F12 shortcut on visual studio a lot to go to the definition of a method for example. Visual studio by default will go to the header file. I want to go to the actual implementation. Seeing code plus comments is better for me than just seeing comments.
The only negative side I see is https://stackoverflow.com/a/1001667/637142 . But that is less work than having to write everything twice. Just a few includes and thats it.
I know I am probably wrong and I a missing something. Since I am a C# developer its hard for me to understand it. I just do not understand why this file will be included multiple times. Yes it will be included multiple times but only the first time will be compiled. The other times it will not be compiled correct?
Upvotes: 0
Views: 607
Reputation: 30579
You should never #include
a .cpp file, because the .cpp extension tells people that a file is a separately compiled translation unit. There is nothing technically wrong with it, but it is misleading to other programmers and will make your code confusing and difficult to maintain.
If you change the file extension of the file in your question to .h or .hpp then it's fine to include the entire definition of a function in a header file as long as you mark it inline
.
That is, if you have a file named "foo.hpp" with the following contents then that's totally fine.
#ifndef FOO_HPP_
#define FOO_HPP_
// my comment that I only have to write once
inline int some_method()
{
return 1;
}
#endif
This will slow down your compile times by a not-insignificant amount in a large project though. Compiling all (or most) of you code as one huge compilation unit will take less time overall than compiling 200 individual compilation units, but it will require re-compiling it all every time you make a change anywhere. That's the problem that separate compilation units exist to solve. If you make a change in one part of your code you want to avoid re-compiling unrelated code. In a large project this can save quite a bit of time. I've worked on projects that take over an hour to fully re-compile, and having to do that every time I make a change would be really painful.
Upvotes: 3
Reputation: 238401
include .cpp with #ifndef instead of .h considered bad practice?
Yes, including .cpp files is considered a bad practice.
int some_method() { return 1; }
Header files are quite often included into multiple translation units. If you include that file into multiple TU, then you have defined some_method
in multiple TU. This violates the One Definition Rule and your program would be ill-formed.
Even if you pinky promise to include that file into exactly one other TU, .cpp files are conventionally compiled - possibly automatically depending on build system - in which case foo.cpp file will be one TU and the including file will be another TU and you end up with having multiple definitions.
- I do not have to write comments twice.
You do not need to write comments twice even if you do not include .cpp files.
- If I change the signature of a method then I will also have to change it on the header file.
This is a trivial change that can be automated.
#define _FOO
That identifier is reserved to the language implementation. You should use another macro as a header guard.
Upvotes: 3