15

Suppose I have two translation units:

//A.cpp
class X
{
};

//B.cpp
class X
{
   int i;
};

Is the above program well-formed?

If not, no further questions. If the answer is yes, the program is well-formed (ignore the absence of main), then the second question. What if there is a function with the same name in those?

//A.cpp
class X
{
    void f(){}
};

//B.cpp
class X
{
    int i;
    void f(){}
};

Would this be a problem for the linker as it would see &X::f in both object files? Are anonymous namespaces a must in such a situation?

Armen Tsirunyan
  • 130,161
  • 59
  • 324
  • 434

2 Answers2

17

Is the above program well-formed?

No. It violates the One-Definition Rule:

[basic.def.odr]

There can be more than one definition of a

  • class type ([class]),
  • ...

in a program provided that each definition appears in a different translation unit and the definitions satisfy the following requirements. Given such an entity D defined in more than one translation unit, for all definitions of D, or, if D is an unnamed enumeration, for all definitions of D that are reachable at any given program point, the following requirements shall be satisfied.

  • ...
  • Each such definition shall consist of the same sequence of tokens, where the definition of a closure type is ...
  • ...

Are anonymous namespaces a must in such a situation?

If you need different class definitions, they must be separate types. A uniquely named namespace is one option, and an anonymous namespace is a guaranteed way to get a unique (to the translation unit) namespace.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
eerorika
  • 232,697
  • 12
  • 197
  • 326
1

Short version

Well, no... C++ bases on assumption that every name in a namespace is unique. If you break that assumption you have 0 guarantee it will work.

For example if you have methods with the same name in two translation units (*.o files). Linker wont know which one to use for given call so it will just return an error.

Long version

... but actually yes!

There is actually quite a few situation when you could get away with classes/methods with the same name.

Do not actually use any of these tricks in your programs! Compilers are free to do pretty much anything if they think it will optimize the resulting program so any of the assumption bellow may break.

Classes are the easiest. Let's take some class with only non-static members and no functions. Such a thing don't even leave any trace in the compiled program. Classes/structs are only tools for a programmer to organize data so there is no need to deal with memory pools and offsets. So basically if you have two classes with the same name in different compilation units, it should work. After the compiler is done with them, they will consist of just a few instruction of how much to move a pointer in memory to access a specific field. There is hardly anything here that would confuse the linker.

Functions and variables (including static class variables) are more tricky because compiler often creates symbols for them in the *.o file. If you're lucky linker may ignore them if such a function/variable is not used but I wouldn't even count on that. There are ways, though, to omit creating symbols for them. Static global elements or ones in anonymous namespaces are not visible outside their translation units so linker shouldn't complain on them. Also, inlined functions don't exist as separate entities so they also don't have symbols, which is especially relevant here because functions defined inside classes are inlined by default. If there is no symbol, linker won't see a conflict and everything should compile.

Templates are also using some dirty tricks because they are compiled on demand in each compilation unit that uses them but they end up as a single copy in the final programs. I don't think this is the same case as multiple different things with the same name so let's drop the topic.

In conclusion, if your classes don't have static members and they do not define functions outside of their bodies, it may be possible to have two classes with the same name as long as you don't include them in the same file. This is extremely fragile, though. Even if it works right now, a new version of the compiler may have some fix/optimization/change that would broke such program. Let alone the fact that includes tends to be pretty interwoven in bigger projects so there is decent chance that at some point you will need to include both files in the same place.

Piotr Siupa
  • 3,929
  • 2
  • 29
  • 65