/* attempt to deal with prototype, bootstrap, jquery conflicts */ /* for dropdown menus */

\$10

### Image of the Day Submit

IOTD | Top Screenshots

## Two classes, same name - solution?

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

20 replies to this topic

### #1Juliean  GDNet+

Posted 02 May 2013 - 03:59 PM

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, 02 May 2013 - 04:00 PM.

### #2Zaoshi Kaba  Members

Posted 02 May 2013 - 04:02 PM

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?

### #3powell0  Members

Posted 02 May 2013 - 04:05 PM

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

Gui::Window
Core::Window

### #4Álvaro  Members

Posted 02 May 2013 - 04:07 PM

POPULAR

The whole point of namespaces is to allow what you are doing. Try to create a minimal program that shows the error. You'll probably discover the true problem in the process of writing that minimal program. And if you don't, you can post it here and we'll help you out.

### #5Juliean  GDNet+

Posted 02 May 2013 - 04:26 PM

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.

#### Attached Files

Posted 02 May 2013 - 04:43 PM

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, 02 May 2013 - 04:44 PM.

### #7SiCrane  Moderators

Posted 02 May 2013 - 04:47 PM

POPULAR

It looks like you're not running into a C++ problem per se, but a problem with MSVC. By default, for every source file, MSVC creates an object file of the same name in Debug/ or Release/. This is still the case if you have two source files with the same name in two different directories. In this case you have A/A.cpp and B/A.cpp, both of which will try to use Debug/A.obj as the object file. One way to get around this problem is to rename the source files so there isn't a clash of object files. Another is to manually change the output file names for the source files in the solution explorer.

### #8Cornstalks  Members

Posted 02 May 2013 - 04:47 PM

POPULAR

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

It looks like you're running into MSVCs issue with files with the same name. At least that's my guess. It's technically a bug in MSVC. It's kind of a pain in the butt; I wish they'd fix it.

Edit: SiCrane... It is unholy how ninja-like you are!

Edit edit: @downvoter: care to expand on the reason behind the downvote? I'm not offended or anything, but I am puzzled about what deserved a downvote, and if there's something I can improve I'd like to know.

Edited by Cornstalks, 02 May 2013 - 09:19 PM.

[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

### #9Juliean  GDNet+

Posted 02 May 2013 - 05:03 PM

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

### #10SiCrane  Moderators

Posted 02 May 2013 - 05:08 PM

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.

### #11Juliean  GDNet+

Posted 02 May 2013 - 05:18 PM

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.

### #12Cornstalks  Members

Posted 02 May 2013 - 06:52 PM

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.

[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

### #13Alpheus  GDNet+

Posted 02 May 2013 - 10:08 PM

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.

External Articulation of Concepts Materializes Innate Knowledge of One's Craft and Science

Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley

If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts

Spoiler

### #14Casey Hardman  Members

Posted 03 May 2013 - 12:31 AM

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

### #15LorenzoGatti  Members

Posted 03 May 2013 - 02:35 AM

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.

Omae Wa Mou Shindeiru

### #16l0calh05t  Members

Posted 03 May 2013 - 03:25 AM

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.

### #17irreversible  Members

Posted 03 May 2013 - 05:39 AM

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

### #18Juliean  GDNet+

Posted 03 May 2013 - 05:44 AM

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.

### #19methinks  Members

Posted 03 May 2013 - 01:28 PM

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

### #20Cornstalks  Members

Posted 03 May 2013 - 01:56 PM

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

[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.