• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Juliean

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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?

Edited by Madhed
0

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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

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  
Followers 0