I have two header files that I'm including from my main.cpp that have the following definition in an anonymous namespace: const string strToken = ("%");
Compiling using g++ version 4.9 results in this:
In file included from main.cpp:25:0:
libraries/trace.h:31:14: error: redefinition of ‘const string {anonymous}::strToken’
const string strToken = ("%");
^
In file included from libraries/debuglogger.h:12:0,
from libraries/packet.h:10,
from main.cpp:20:
libraries/strformat.h:23:14: note: ‘const string {anonymous}::strToken’ previously declared here
const string strToken = ("%");
^
I had thought that putting something in an anonymous namespace limited it to file scope, making this a non-issue. Am I missing something, or is this some sort of defect in GCC? If anyone wants the full code I would be willing to include it, but I'm hoping I've included enough information in my question to not need it.
I had thought that putting something in an anonymous namespace limited it to file scope
You were just a bit off. Putting things in an anonymous namespace limits their visibility to the translation unit they appear in. A translation unit is everything that turns into a single object file, which is typically one source file (.cpp file) along with all the code from the header files that are included from that source file. So, when you have main.cpp which includes two headers that have the same declarations (in an anonymous namespace or not), you get an error.
Always think about the #include statements as being essentially just a copy-paste of the content of the header in place of the include statement. These kinds of issues become a lot easier to deal with once you understand that. For example, your particular case basically boils down to having this code after the include-statement have been resolved (copy-pasted into the source file):
// from first header:
namespace {
const string strToken = ("%");
};
// from second header:
namespace {
const string strToken = ("%");
};
int main() { ... };
where the error is pretty obvious, and anonymous namespace really won't change anything to the basic problem that you have multiple definitions of the same thing.
Anonymous namespaces are mainly there so that you can create things inside a translation unit (usually in the .cpp file itself) without having any traces of them appearing after compilation of the translation unit into an object file. You might find this tutorial helpful in understanding the whole compilation and linking process.
I've discovered after doing some research that anonymous namespaces in headers are a bad idea. See here for possible solutions: Hiding a C++ class in a header without using the unnamed namespace
Related
working on a college assignment, we're required to write around a provided main.cpp file, giving a translator.h and translator.cpp file. This code compiles and works if I combine it all together into a single .cpp file, but as separate files, it looks as if the header file isn't being recognized, and the compiler throws a load of
I tried using namespace std in the header file, I realize I shouldn't use namespace std as it's bad practice, but it didn't make a difference anyway.
Much appreciated.
These are the errors (continuing in this fashion all the way down)
Translator.cpp:1:1: error: 'Translator' does not name a type
Translator::Translator(const char dictFileName[]) : dictionary(dictFileName)
^
Translator.cpp:5:6: error: 'Translator' has not been declared
void Translator::toElvish(char * outputline, const std::string inputline)
^
Translator.cpp:5:52: error: 'string' in namespace 'std' does not name a type
void Translator::toElvish(char * outputline, const std::string inputline)
^
The code is linked http://pastebin.com/Nwh7mh6D (I think it's probably a bit long for the body of a post like this.
Thanks again.
The problem is that your translator.cpp doesn't #include "translator.h". It also needs to be able to see the class definition and member function declarations. The compiler doesn't care that the two files both happened to be named in the same way and so doesn't automatically connect them together.
I know that include is for classes and using is for some built-in stuff, like namespace std... When you include something, you can create objects and play around with them, but when you are "using" something, then you can use some sort of built-in functions. But then how am I supposed to create my own "library" which I could "use"?
Simply put #include tells the pre-compiler to simply copy and paste contents of the header file being included to the current translation unit. It is evaluated by the pre-compiler.
While using directive directs the compiler to bring the symbol names from another scope in to current scope. This is essentially put in effect by the compiler.
But then how am I supposed to create my own "library" which I could "use"?
Namespaces are something which are used for preventing symbol name clashes. And usually every library implementer will have their functionality wrapped up in one or many namespaces.
'include' basically does a copy-paste the value of a file to the location of the "include" line. This is used to make your source code (usually .c file) aware of a declaration of other source code (usually sits in .h file).
'using' basically tells the compiler that in the next code you are using something (usually a namespace) so you won't have to do it explicitly each time:
Instead of:
std::string a;
std::string b;
std::string c;
You could write:
using namespace std;
string a;
string b;
string c;
You can say both gives the same functionality but #include is not done by compiler where as using is done by compiler. In #include all the code is placed in file where #include is given where as namespace gives the definition of function and variables from one scope to another. If you have function with same name in two header files and both are included then there will be an error of redeclaration but you can use same name functions if they are from different namespaces.
I am defining a namespace across multiple files. In one file, within the namespace I have declared a type called MyType. In another file and still within the namespace, shouldn't I be able to see that type, without having to include a header file as well? Below is an example :
FILE A
namespace EE
{
typedef int MyType;
}
FILE B
namespace EE
{
MyType a = 10;
}
Again, to my understanding namespaces helped to clean up inclusion. If I define a type that 30 files will use, I shouldn't have to include the header in all of them if I am using a namespace, or so I thought.
Namespaces were introduced to fight the problem of the names collision. Pretty much that is it. When you compile one file, an object file is generated. Information from this object file is not enriching the knowledge of the compiler when it is compiling the next file. This means that that you need to include your typedef definition as part of some header fine into each C/C++ file. And it is not important if your typedef is part of the namespace or not.
Note that typedefs are exception to the "one definition rule". You can have several identical typedefs in one translation unit, like the following:
typedef int MyInt;
....
typedef int MyInt;
This will not cause a syntax error.
There is one exception to the rule of "not enriching the knowledge" for exported templates. But this applies only to templates and this feature is not supported by compilers. After deliberation it was even removed from the standard.
Sample.h
namespace Testing
{
enum Type
{
DATA = 0,
MORE_DATA
};
}
Now in Sample2.h, using the same namespace, can I access the DataType defined in Sample.h, without including it?
namespace Testing
{
Type test;
}
The question has come up, because I have files that implement this, and seem to build with no problem.
Another user is trying to build, but reports that he has to #include "Sample.h" in Sample2.h in order to build.
Most likely the files build because some earlier include file is including Sample.h for you. When the earlier include file is omitted (or moved after Sample2.h) the files will no longer compile.
Forward enum declarations are not supported in most current compilers. It is a planned feature of up coming C++0x. You can create pointers to Type probably, but cannot instantiate, this is compatible with other types (structs and classes) as well.
Ow, my bad, I saw it wrong i guess. Anyway, read the others and read this as well. Headers are not compiled stand alone. Therefore, if you don't include a required heading in your header and included that in the cpp file you will not run into any errors. As long as all the cpp files contain both headers with the required order there will be no problems at all. However, this is not a good idea, it is best to include any necessary files within your header and use header guards to ensure they are not added twice. I hope this makes sense.
Yes, you will need to include Sample.h within Sample2.h. The definition of Type is not visible to the compiler within Sample2.h simply because the namespace name is the same within the 2 files.
The only thing you gain by having the same namespace names in the 2 files is that Type does not need to have its namespace stated explicitly in Sample2.h. For instance, if the 2 namespaces were not the same:
Sample.h
namespace Testing
{
enum Type
{
DATA = 0,
MORE_DATA
};
}
Sample2.h
#include "Sample.h"
namespace Testing1
{
Testing::Type test;
}
I am compiling C++ on VS 2005.
When and why use #include and when and why use pre-decleration as class XXXX?
What is the benefit of using each option and which one is preffered?
I would also glad for a good tutorial on compiling.
Always prefer forward declaration whenever possible. Changes to the referred class file will not trigger recompilation of cpp files including the class using the pre-declared one. This reduces a bit the dependencies.
On each place where you are effectively using the class XXXX, you will have to include that header. If you derive from class XXXX, you will also have to include the header.
A header file is used to contain the declaration of entities that are defined in separate compilation units. If you did not have a header file, you'd have to enter such declarations in every compilation unit (which is essentially what #include does for you, it inserts the contained text at that point in the file, however if you did not use a header, you'd have to do it multiple times and that is both error prone and difficult to maintain when the code changes.
You'd use a declaration directly in the .cpp file for example if the symbol being defined is only ever used within that compilation unit and therefore did not need global visibility. In the case of data declarations, you also typically declare them static to give them scope limited to the compilation unit.