Followers 0

Two classes, same name - solution?

20 posts in this topic

Hello,

after refactoring some of my old gui code by removing the "Gui" - prefixes and instead putting them into a gui-namespace, plus putting the file into a seperate folder, I've come across a problem. Now I've got some classes that share the same name, and also the same file-name:

// in "Gui/Window.h"
namespace gui
{
class Window {};
}

// in "Core/Window.h"
namespace core
{
class Window {};
}



Those two classes doesn't have anything in common. Before starting, I supposed this was safe, since both files are in different locations, and both classes are in different namespaces. However, when compiling the libary I get a compiler warning about multiple object-files with the same name, and upon compiling the actual game project, I get a lot of unresolved symbol linker errors.

Now I ask, is there any way to solve this, without adding some provisorical pre/postfix to the class?

Edited by Juliean
1

Share on other sites

There shouldn't be any linker errors. Are you sure it's caused by this? Did you refactor your .cpp files as well, not only headers?

0

Share on other sites
If both classes are still in separate namespaces then you can refer to them by prefixing them with the namespace:

Gui::Window
Core::Window
2

Share on other sites

Here you go. The errors I get are basically:

1>Debug\A.obj : warning LNK4042: Objekt mehrmals angegeben; zusätzliche Objekte werden ignoriert.
1>main.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""public: __thiscall a::A::A(void)" (??0A@a@@QAE@XZ)" in Funktion "_main".
1>main.obj : error LNK2019: Verweis auf nicht aufgelöstes externes Symbol ""public: __thiscall a::A::~A(void)" (??1A@a@@QAE@XZ)" in Funktion "_main".
1>S:\Users\Juli\Documents\Visual Studio 2012\Projects\TestProject\Debug\TestProject.exe : fatal error LNK1120: 2 nicht aufgelöste Externe


Sorry for the german, I hope you get what it means. LNK4042: translates to "object referenced multiple times", and the other ones to "unsolved refernece to extern symbol".

I know how I can reference the classes, but this errors are just... weird, or am I missing something? Using visual studio 2012 ultimate, if that helps.

0

Share on other sites

This is indeed very weird. I got the same error bilding the project in MSVC++ Express 2012.

Renaming the files in B to B.h and B.cpp "fixed" it. Is this a compiler/linker bug?

0

Share on other sites

Please use a "normal" archiving format, like zip. Using something weird, like rar, will make people less likely to download the code.

Wait, rar a weird archiving format? In all due honesty, thats a new one for me, rar has been my "standard" for years now. But, never mind, I strongly suppose you know what you are talking about, so, yeah, will relate to zip in the future.

Anyway, thanks both of you for pointing that out. I wasn't able to find a feasable solution in the solution explorer - while I could change the obj output directory for a project, that doesn't work for a single class - I'll have no choice than renaming it. I might as well split the modules into seperate projects somewhere, but right now, the complexity doesn't justify that. Man, thats really a pain, I'd too like them to fix that...

0

Share on other sites
You don't need to change the output directory for the project, but you can change the generate object file name for a specific file. Go to the solution explorer, right click on the file name and hit properties, go to the output files page and change the output file name.
1

Share on other sites

Ah, got it, its under the .cpp-files settings, and somewhere hid beyond the dozens of c++-settings that there are. Thank god for the search option. Needless to say, now its working, thanks.

0

Share on other sites

Please use a "normal" archiving format, like zip. Using something weird, like rar, will make people less likely to download the code.

Wait, rar a weird archiving format? In all due honesty, thats a new one for me, rar has been my "standard" for years now. But, never mind, I strongly suppose you know what you are talking about, so, yeah, will relate to zip in the future.

Well, given the fact that neither Windows nor OS X can extract files from .rars without some 3rd party software, I consider it a "weird" format.

2

Share on other sites

Please use a "normal" archiving format, like zip. Using something weird, like rar, will make people less likely to download the code.

I don't know if this is the reason you got downvoted, but it certainly caught my eye when I read it. Namely, because it's weird to call "rar" weird. But anyway, I had no problem with your actual answer. Maybe @downvote clicked the wrong arrow by accident.

0

Share on other sites

I also think 'rar' files are kind of "weird".  I don't have anything installed that can open them, and Windows lets me make and extract zip files very easily.  I'm not sure if other operating systems can extract or create zip files without installing special software for it (like I would have to install something to extract rar files).

0

Share on other sites

Complaining about "weird" archive formats is quite strange, given that they are obviously not weird (compressing better than ZIP is good) and not a problem (7-Zip and other free tools deal with them perfectly) and given that there is a weird compiler to whine about.

I was under the impression that MSVC was approaching standard compliance and technical dignity, but learning about such a ridiculously basic known bug destroys all my confidence.

0

Share on other sites

Interestin bug. Never ran into it so far because I tend to use CMake which automatically tells MSVC to place object files in correspondingly named subdirectories preventing such collisions.

0

Share on other sites

While the solution has likely been proposed above my first reaction would have been checking the code for overlapping "using gui;" and "using core;".

0

Share on other sites

While the solution has likely been proposed above my first reaction would have been checking the code for overlapping "using gui;" and "using core;".

Well,  I'm not using "using namespace xyz" anymore, for the given reason. Sure it can happen, but it would be kinda "dumb" putting classes into namespaces and then "removing" this namespace elsewhere, wouldn't it.

0

Share on other sites

It doesn't look like a namespace issue, because they are showing the same namespace (a::A::A)

Could it be that the project is trying to compile the same class multiple times? (Do you have an include guard in the header?)

0

Share on other sites

While the solution has likely been proposed above my first reaction would have been checking the code for overlapping "using gui;" and "using core;".

using ***; doesn't create double definition linker errors. It might create compile time ambiguity errors, but it doesn't cause linker issues.

@methinks: the solution was that Visual Studio outputs compiled object files into the same folder, so if you have the same filename, the generated object files will (be default) conflict because they have the same name in the same folder. The solution is to either change the filename or change the target filename (or wait until Microsoft fixes this bug, but it's been around for ages so I'm not counting on them fixing it any time soon).

0

Share on other sites

The solution is to either change the filename or change the target filename (or wait until Microsoft fixes this bug, but it's been around for ages so I'm not counting on them fixing it any time soon).

Well, I kinda see why they aren't putting much effort into fixing this, since the easiest and probably best solution actually consits of only changing one option, namely the "output object file as"-option for the whole project to:

%(RelativeDir)\\$(IntDir)


That way every object file gets put where it should automatically. Would be nice still as a default. Or is there any drawback by that?

0

Create an account

Register a new account