//file.h
namespace Foo{
namespace{
void func(){}
}
}
vs
namespace Foo{
void func(){}
}
//file2.cpp use file.h's method
What is the consequence (if there is one) in the calling code (in term of visiblity for example) between this two approach ?
This:
namespace Foo {
namespace {
void func() {}
}
}
Is largely equivalent to this:
namespace Foo {
static void func() {}
}
The difference is that in the static case, the function has internal linkage, so it is not visible to the linker. In the unnamed namespace case, the function has external linkage (is visible to the linker), but under a name which none of your other source files can "normally" access. You might still call the function from a different source file if you reverse-engineer the compiler's name mangling scheme, and the function is still listed among the object file's symbols, for example.
But the common point is that each source file which includes the code (perhaps by #includeing the header file) will contain its own copy of the function. This can have an impact on the size of your binary.
Also, if you need the first one for some reason, you should heavily document it. An unnamed namespace in a header file is generally a "WTF" point, and you do not want these in your code. I must say I can't think of a viable use case for this.
Both variants will allow the function to be found under the name Foo::func().
The compiler might generate different code in the two cases though. Declaring a function inside an anonymous namespace makes that function local to the .cpp file. That is, every .cpp file that includes the header might end up with their own (identical) instantiation of the code for func. This might lead to some bloat in the final executable, due to the duplicated code.
Note that if you define the function inline (as is suggested by your question) this is not really an issue, as the code will be duplicated anyway due to inlining.
Still, as pointed out in the comments: Anonymous namespaces in headers are unusual and will draw the suspicion of however reviews this code. You should always prefer the second option, unless you have very good reason not to.
The first is the equivalent of:
namespace Foo
{
namespace TranslationUnitSpecific
{
void func();
}
}
It means that every time you include the header, you declare
a new, unrelated instance of func. If func is not inline,
you would have to define it in every source file that uses it.
(On the other hand, it does mean that you can provide an
implementation in the header without making the function
inline.)
It also means that you cannot use the function in inline or
template functions defined in a header with risking undefined
behavior, due to violations of the one definition rule.
In general, there are very few, if any cases where you should
use an unnamed namespace in a header.
Related
In the code below, foo should be a function accessible by anyone, but foo_helper should not, which is why I've put it in an anonymous namespace. Obviously I'm leaving out include guards and includes in this example, but they are there.
foo.h:
namespace
{
void foo_helper() {}
template <typename T, typename... Tail>
void foo_helper(T head, Tail... tail)
{
bar(head);
foo_helper(tail...);
}
}
void foo();
template <typename... Args>
void foo(Args... args)
{
before();
foo_helper(args...);
after();
}
foo.cpp:
void foo() {}
The problem is that in order for foo_helper's variadic template to work, it needs to have that initial version with no argument. But, this forces me to define a non-template function is a header file, which would break after including this file in multiple source files. I cannot move the definition of foo_helper to a source file because it is in an anonymous namespace, since it is not supposed to be accessible.
Is there a way to solve this issue?
inline void foo_helper() {};
solves your problem.
inline mostly means "conflicting definitions of this function are to be discarded, and one of the versions kept".
It also non-bindingly suggests "inlining" in a vague way (in that the standard doesn't really cover what inlining is). Compilers may or may not pay attention to that suggestion.
Note that an anonymous namespace does not "make it unusable" or whatever. Anonymous namespaces are designed to block linker collisions, and that is about it. Create a namespace called details and ... well, trust users not to go and poke inside.
Using an anonymous namespace in a header is a very bad idea.
If there is an inline function (or template function) within another header file that accesses a symbol or function within the anonymous namespace, you are almost certainly going to have an ODR (one definition rule) violation. That is where the same object, function, etc has two definitions that differ, and isn't allowed to.
For example:
inline void bob() {
foo(1,2,3);
}
if that is #included in two different .cpp files, you just made an ill-formed program (no diagnostic required).
Often such ill formed programs "behave the way you expect", but sometimes they do not. As an example, if somewhere along the line you get a static local variable whose existence depends on ODR violation, you can have multiple compilation units disagree asto which one exists and what its properties are.
In a more general sense, the link order of your program could change its behavior, as different definitions are "chosen" (with possibly extremely subtle differences). Or the phase of the moon could do the same.
ODR violations are surprisingly benign, until they byte you with non-local bugs that are hard to track down.
I'll start with an aside: using an anonymous namespace here doesn't serve your purpose. Since you're defining it in a header file, it's not protected at all: it will still be in scope in any file that includes your header. Additionally, since you've defined it in an anonymous namespace, a separate copy of the function will be emitted in each translation unit that uses it, and the linker can't collapse them. If you really want it to be private, I'm not on the up-and-up of the best C++ style these days, so perhaps someone else will correct me, but I would be inclined to use a private namespace:
namespace my_stuff {
void foo_helper();
}
void foo() {
my_stuff::foo_helper();
}
As Yakk indicated, you could use an inline function, and that will allow the compiler to collapse the definitions into one. In modern practice, there shouldn't really be another reason to avoid the inline keyword, because compilers will nowadays decide on their own whether or not to inline functions rather than listening to the hints you give.
Since you have defined the function in an anonymous namespace, as I mentioned above, you actually don't need to do anything else to avoid linker errors if you retain that. The downside to this approach is that you will have separate copies of foo_helper() in each translation unit and those can't be merged by the linker.
There are other gymnastics you could do, mostly involving sizeof..., but I don't think those are ideal.
I have what seems a relatively simple question, but one that keeps defying my efforts to understand it.
I apologise if it is a simple question, but like many simple questions, I can't seem to find a solid explanation anywhere.
With the below code:
/*foo.c*/
#include "bar.h"
int main() {
return(my_function(1,2));
}
/*bar.h*/
int my_function(int,int);
/*bar.c*/
#include "bar.h" /*is this necessary!?*/
int my_function(int x, int y) {
return(x+y);
}
Simply, is the second inclusion necessary? I don't understand why I keep seeing headers included in both source files. Surely if the function is declared in "foo.c" by including "bar.h," it does not need to be declared a second time in another linked source file (especially the one which actually defines it)??? A friend tried to explain to me that it didn't really matter for functions, but it did for structs, something which still eludes me! Help!
Is it simply for clarity, so that programmers can see which functions are being used externally?
I just don't get it!
Thanks!
In this particular case, it's unnecessary for the reason you described. It might be useful in situations where you have a more complex set of functions that might all depend on each other. If you include the header at the top of the .cpp file, you have effectively forward-declared every single function and so you don't have to worry about making sure your function definitions are in a certain order.
I also find that it clearly shows that these function definitions correspond to those declarations. This makes it easier for the reader to find how translation units depend on each other. Of course, the names of the files might be sufficient, but some more complex projects do not have one-to-one relationship between .cpp files and .h files. Sometimes headers are broken up into multiple parts, or many implementation files will have their external functions declared in a single header (common for large modules).
Really, all inclusions are unnecessary. You can always, after all, just duplicate the declarations (or definitions, in the case of classes) across all of the files that require them. We use the preprocessor to simplify this task and reduce the amount of redundant code. It's easier to stick to a pattern of always including the corresponding header because it will always work, rather than have to check each file every time you edit them and determine if the inclusion is necessary or not.
The way the C language (and C++) is designed is that the compiler processes each .c file in isolation.
You typically launch your compiler (cl.exe or gcc, for example) for one of your c files, and this produces one object file (.o or .obj).
Once all your object files have been generated, you run the linker, passing it all the object files, and it will tie them together into an executable.
That's why every .c file needs to include the headers it depends on. When the compiler is processing it, it knows nothing about which other .c files you may have. All it knows is the contents of the .c file you point it to, as well as the headers it includes.
In your simplified example inclusion of "bar.h" in "bar.c" is not necessary. But in real world in most cases it would be. If you have a class declaration in "bar.h", and "bar.c" has functions of this class, the inclusion is needed. If you have any other declaration which is used in "bar.c" - being it a constant, enum, etc. - again include is needed. Because in real world it is nearly always needed, the easy rule is - include the header file in the corresponding source file always.
If the header only declares global functions, and the source file only implements them (without calling any of them) then it's not strictly necessary. But that's not usually the case; in a large program, you rarely want global functions.
If the header defines a class, then you'll need to include it in the source file in order to define member functions:
void Thing::function(int x) {
//^^^^^^^ needs class definition
}
If the header declares functions in a namespace, then it's a good idea to put the definitions outside the namespace:
void ns::function(int x) {
//^^^^ needs previous declaration
}
This will give a nice compile-time error if the parameter types don't match a previous declaration - for which you'd need to include the header. Defining the function inside its namespace
namespace ns {
void function(int x) {
// ...
}
}
will silently declare a new overload if you get the parameter types wrong.
Simple rule is this(Considering foo is a member function of some class):-
So, if some header file is declaring a function say:=
//foo.h
void foo (int x);
Compiler would need to see this declaration anywhere you have defined this function ( to make sure your definition is in line with declaration) and you are calling this function ( to make sure you have called the function with correct number and type of arguments).
That means you have to include foo.h everywhere you are making call to that function and where you are providing definition for that function.
Also if foo is a global function ( not inside any namespace ) then there is no need to include that foo.h in implementation file.
I have a header file I want to include in another cpp file. I want to know what is the difference if I write the header file like this,
#include <iostream>
#include <string>
using namespace std;
string ret()
{
return "called";
}
===================================
#include <iostream>
#include <string>
using namespace std;
static string ret()
{
return "called";
}
I can access the ret() function anyway!! So, what's the use of the static?
That is a pretty evil header file you're showing.
Never put using namespace std; into a header file. This forces anyone including the header to have all of std in the global namespace.
Use some form of include guards.
static makes the function invisible outside the .cpp where it's included. This means that every .cpp which includes the header will have its own copy of the function. static (non-member) functions should only be used if you specifically need this behaviour.
If you don't use static, you should either move the definition from the header into a source file (if you want it defined once), or declare the function inline (its code will then be inlined on every call site, if possible). If you do neither of these, you'll get multiple definition errors if you include the header in more than one source file.
The first header file defines a function called ret with external linkage in every translation unit that includes it. This is incorrect if more than one such TU is linked in the same program.
The second header file defines a function called ret with internal linkage in every translation unit that includes it. This means that each TU has its own private copy of the function (with a different address) no matter how many are linked together.
There are three correct ways to share code using a header file:
function with internal linkage (as in your second header, or in C++11 by putting it in a nameless namespace).
inline function with external linkage (replace static with inline). The meaning of inline is that although there is only one copy of the function in the program, every TU that uses the function contains its definition.
declare the function in the header, and define in it exactly one .cpp file (for example ret.cpp).
In C++03 there was a fourth way:
function with external linkage in a nameless namespace
I believe this is still available in C++11, but in C++11 functions in nameless namespaces have internal linkage by default. I'm not aware of any use in C++11 for making a function in a nameless namespace have external linkage. So as far as functions are concerned, nameless namespaces are a nice way of giving the function internal linkage.
Which one you use depends on your needs. The third option means that you can change the definition of the function without re-compiling the calling code, although you'd still need to re-link the executable unless the function is in a dll.
The first two (static or inline) differ in their behaviour if:
the function contains static local variables,
you compare function pointers to ret taken in different TUs,
you examine your executable size or symbol table,
the definition of the function is different in different TUs (perhaps due to different #defines), which is forbidden if the function has external linkage but not if internal.
Otherwise they're much the same.
According to the standard, inline is also a hint that the compiler should optimize calls to that function for fast execution (which in practice means, inline the code at the call site). Most compilers ignore this hint most of the time. They will happily inline a static but non-inline function if they assess it to be a good candidate for inlining, and they will happily avoid inlining an inline function if they assess it to be a bad candidate for inlining.
Use header guards.
Don't use "using namespace" in header files. (Actually, don't use "using" in header files. Use identifiers fully qualified.)
And use a header for declaring functions, not for defining them. You will want the code for ret() to be present in the resulting executable only once. You achieve this by putting the definition (code) of ret() in a .cpp file. One .cpp file, not multiple ones (by including the definition).
The header file lists the declaration of the function ret() so that other code "knows" that the function exists, which parameter it takes, and what it returns.
If you define c++ methods as static in the header file, each translation unit ( each .cpp file which includes that header file ) will have different versions of those static methods - they will not have the same address space.
Hence the size of your program will increase unnecessarily.
Also, just for clarity:
Defining a method as static only in the .cpp file means that the method has static linkage and is only accessible from other methods within the same .cpp file.
I was once told in a programming class that C++ had achieved a better readability by letting the programmer declare its variable anywhere in a function block. This way, the variables were grouped together with the section of the code that dealt with it.
Why don’t we do the same for includes?
Put differently, why is it discouraged to put the include file next to the definition that will actually use it?
parser::parser()
{
// some initialization goes there which does not make use of regex
}
#include <boost/regex.hpp>
parser::start()
{
// here we need to use boost regex to parse the document
}
One of the reasons for this is that #include are context-less, they are just plain text inclusion, and having it in the middle of the code might have some unwanted effects. Consider for example that you had a namespace, and all your code in this file belongs to the namespace:
// Include on demand:
namespace ns {
void f() {} // does not need anything
//... lots of other lines of code
#include <vector>
void g() { std::vector<int> v; }
}
Now that might even compile fine... and wrong. because the inclusion is inside a namespace, the contents of the file are dumped inside ns and the included file declares/defines ::ns::std::vector. Because it is header only it might even compile fine, only to fail when you try to use that in an interface with a different subsystem (in a different namespace) -- This can be fixed, you only need to close all contexts, add the inclusion and reopen the same contexts...
There are other situations where the code in your translation unit might actually affect the includes. Consider, for example, that you added a using namespace directive in your translation unit. Any header included after that will have the using namespace directive in place, and that might also produce unwanted effects.
It could also be more error prone in different ways. Consider two headers that defined different overloads of f for int and double. You might add one (say the int version) towards the beginning of the file and use it, then add the other and use it. Now if you call f(5.0) above the line where the second header is included, the int version will be called --only overload available to the compiler at this point--, which would be a hard to catch error. The exact same line of code would have completely different meaning in different places in your file (admittedly that is already the case, but within the declarations in your file it is easier to find which is the one being picked up and why)
In general, the includes declare elements that you will be using in your component, and having them on the top provides a list of dependencies in a quick glance.
Imagine the following file:
#include <someheader>
namespace myns {
void foo() {
}
void bar() {
// call something from someheader:
func();
}
}
It might be tempting to put #include <someheader> nearer the point of usage. That would be fine iff you wrote the following instead:
namespace myns {
void foo() {
}
}
#include <someheader>
namespace myns {
void bar() {
// call something from someheader:
func();
}
}
The problem is in a medium/large sized file it's rather easy to loose track of quite how deeply nested you are inside namespaces (and other #ifdefs), depending on your indentation style. You might come back later and decide to move things around, or add another nested namespace.
So, if you write the #include at the top always you can never get bitten by accidentally writing something like:
namespace myns {
void foo() {
}
// Whoops, this shouldn't be inside myns at all!
#include <someheader>
void bar() {
// call something from someheader:
func();
}
}
which would be somewhere between wrong and very wrong depending on what exactly is in <someheader>. (You could for example end up with UB, by violating the ODR having multiple definitions which although otherwise legal and identical sequence of tokens match different functions and so violate § 3.2.5).
It's discouraged because most programmers are used to includes at the top of the file. Force of habit I think, and for consistency with 99% of existing code.
When I personally want to see what headers are included, I only look at the top. In special (and thankfully rare) cases where something is fishy, I might look for includes in the whole file.
To the compiler it makes no difference anyway.
When we design classes in Java, Vala, or C# we put the definition and declaration in the same source file. But in C++ it is traditionally preferred to separate the definition and declaration in two or more files.
What happens if I just use a header file and put everything into it, like Java?
Is there a performance penalty or something?
The answer depends on what kind of class you're creating.
C++'s compilation model dates back to the days of C, and so its method of importing data from one source file into another is comparatively primitive. The #include directive literally copies the contents of the file you're including into the source file, then treats the result as though it was the file you had written all along. You need to be careful about this because of a C++ policy called the one definition rule (ODR) which states, unsurprisingly, that every function and class should have at most one definition. This means that if you declare a class somewhere, all of that class's member functions should be either not defined at all or defined exactly once in exactly one file. There are some exceptions (I'll get to them in a minute), but for now just treat this rule as if it's a hard-and-fast, no-exceptions rule.
If you take a non-template class and put both the class definition and the implementation into a header file, you might run into trouble with the one definition rule. In particular, suppose that I have two different .cpp files that I compile, both of which #include your header containing both the implementation and the interface. In this case, if I try linking those two files together, the linker will find that each one contains a copy of the implementation code for the class's member functions. At this point, the linker will report an error because you have violated the one definition rule: there are two different implementations of all the class's member functions.
To prevent this, C++ programmers typically split classes up into a header file which contains the class declaration, along with the declarations of its member functions, without the implementations of those functions. The implementations are then put into a separate .cpp file which can be compiled and linked separately. This allows your code to avoid running into trouble with the ODR. Here's how. First, whenever you #include the class header file into multiple different .cpp files, each of them just gets a copy of the declarations of the member functions, not their definitions, and so none of your class's clients will end up with the definitions. This means that any number of clients can #include your header file without running into trouble at link-time. Since your own .cpp file with the implementation is the sole file that contains the implementations of the member functions, at link time you can merge it with any number of other client object files without a hassle. This is the main reason that you split the .h and .cpp files apart.
Of course, the ODR has a few exceptions. The first of these comes up with template functions and classes. The ODR explicitly states that you can have multiple different definitions for the same template class or function, provided that they're all equivalent. This is primarily to make it easier to compile templates - each C++ file can instantiate the same template without colliding with any other files. For this reason, and a few other technical reasons, class templates tend to just have a .h file without a matching .cpp file. Any number of clients can #include the file without trouble.
The other major exception to the ODR involves inline functions. The spec specifically states that the ODR does not apply to inline functions, so if you have a header file with an implementation of a class member function that's marked inline, that's perfectly fine. Any number of files can #include this file without breaking the ODR. Interestingly, any member function that's declared and defined in the body of a class is implicitly inline, so if you have a header like this:
#ifndef Include_Guard
#define Include_Guard
class MyClass {
public:
void DoSomething() {
/* ... code goes here ... */
}
};
#endif
Then you're not risking breaking the ODR. If you rewrite this as
#ifndef Include_Guard
#define Include_Guard
class MyClass {
public:
void DoSomething();
};
void MyClass::DoSomething() {
/* ... code goes here ... */
}
#endif
then you would be breaking the ODR, since the member function isn't marked inline and if multiple clients #include this file there will be multiple definitions of MyClass::DoSomething.
So to summarize - you should probably split up your classes into a .h/.cpp pair to avoid breaking the ODR. However, if you're writing a class template, you don't need the .cpp file (and probably shouldn't have one at all), and if you're okay marking every single member function of your class inline you can also avoid the .cpp file.
The drawback of putting definition in header files is as follows:-
Header file A - contains definition of metahodA()
Header file B - includes header file A.
Now let us say you change the definition of methodA. You would need to compile file A as well as B because of the inclusion of header file A in B.
The biggest difference is that every function is declared as an inline function. Generally your compiler will be smart enough that this won't be a problem, but worst case scenario it will cause page faults on a regular basis and make your code embarrassingly slow. Usually the code is separated for design reasons, and not for performance.
In general, it is a good practice to seperate implementation from headers. However, there are exceptions in cases like templates where the implementation goes in the header itself.
Two particular problems with putting everything in the header:
Compile times will be increased, sometimes greatly. C++ compile times are long enough that that's not something you want.
If you have circular dependencies in the implementation, keeping everything in headers is difficult to impossible. eg:
header1.h
struct C1
{
void f();
void g();
};
header2.h
struct C2
{
void f();
void g();
};
impl1.cpp
#include "header1.h"
#include "header2.h"
void C1::f()
{
C2 c2;
c2.f();
}
impl2.cpp
#include "header2.h"
#include "header1.h"
void C2::g()
{
C1 c1;
c1.g();
}