why does nobody use them in game design? (at least no commercial project i know about) i found namespaces extremely useful to organize your code. so is there a (performance?) drawback opposing to plain c code organizations or single instaniated classes? ridcully

I am sure they are used, I just haven''t heard of anyone really discussing them in their .plan or anything.

I *think* I can remember an article by Paul Nettle ( Terminal Reality ) briefly discussing namespaces...but don''t quote me on that.

I don''t see how their would be a performance hit for using namespaces.

I use them, but only for large projects. They are of most benefit to writers of libraries, because otherwise, most people can just use the global namespace without problems. It really does work good for organizing things though


- null_pointer
Sabre Multimedia

Just for clarification, there is NO penalty hit when using namespaces. It''s purely a syntactical/scoping issue, and doesn''t alter the generated executable at all.

-Brian

I am currently writing a game project where we use a namespace for our 3D math stuff - Vectors, Matrices, etc. This was because we had a few different options early on on which implementation we were going to use, and it''s really easy to switch between the different implementations with a single line of code if you use namespaces. Haven''t used them for more, though. I think it''s kinda like the throw/catch/try thing... Game programmers don''t really give a crap how nice they can make life, it''s too much trouble to remember how it all works.

Pythius

Actually, I use try/throw/catch in most of my functions, especially initialisation. When loading in a file, there are usually loads of different places that it can go wrong, so I just throw an informative string and I output that in a message box 2 or 3 functions further down the hierarchy Kinda like this:

void Init()
{
try
{
InitGraphics();
InitSound();
InitOtherStuff();
}
catch(const char* msg)
{
MessageBox(msg);
}
}

InitGraphics()
{
LoadBitmap(1)
LoadBitmap(2)
LoadOtherFile()
}

LoadBitmap()
{
DoSomething()
if (filenotfound)
throw "LoadBitmap - file not found";
if (invalid)
throw "LoadBitmap - invalid file";
}

That way, I only need to write the MessageBox stuff once, avoiding clutter in the other functions. I can also save return values for functions that really need them. Sure, it''s not the most elegant use of exception handling, but it works better than cascading return values, and I can stick any new function in Init() without having to worry about what it might return, as long as I keep using char* exceptions to report errors.

quote:
I think it''s kinda like the throw/catch/try thing... Game programmers don''t really give a crap how nice they can make life, it''s too much trouble to remember how it all works.

I think a lot of game programmers are using exceptions now. They are really a good way of handling errors.

My game development library uses exceptions (as well as namespaces). They are very clean and very elegant. They also make error handling very simple and controlled. I hate having to check every single return value.

Exceptions are also very simple to understand and use. I doubt any competant game programmer would have problems understanding them.


Josh
http://www.jh-software.com