Sign in to follow this  
Juliean

Two classes, same name - solution?

Recommended Posts

Juliean    7068

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

Share this post


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

Gui::Window
Core::Window

Share this post


Link to post
Share on other sites
Juliean    7068

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.

Share this post


Link to post
Share on other sites
Madhed    4095

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?

Edited by Madhed

Share this post


Link to post
Share on other sites
Juliean    7068

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...

Share this post


Link to post
Share on other sites
SiCrane    11839
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.

Share this post


Link to post
Share on other sites
Juliean    7068

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.

Share this post


Link to post
Share on other sites
Cornstalks    7030

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.

Share this post


Link to post
Share on other sites
Alpha_ProgDes    6921

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.

Share this post


Link to post
Share on other sites
CaseyHardman    2765

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).

Share this post


Link to post
Share on other sites
LorenzoGatti    4442

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.

Share this post


Link to post
Share on other sites
l0calh05t    1796

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.

Share this post


Link to post
Share on other sites
Juliean    7068

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.

Share this post


Link to post
Share on other sites
methinks    222

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?)

Share this post


Link to post
Share on other sites
Cornstalks    7030

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).

Share this post


Link to post
Share on other sites
Juliean    7068

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?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this