next »

[davidv]

I am working on a strategy/roguelike in C++. I have some functions for generating maps (generating random points, voronoi) and other functions that are not dependent on game code. Then of course I have classes like Map, Entity etc.

I haven't used C++ for some time now and I can't decide how to best organize my code. Should I create a namespaces for these functions, e.g. "voronoi" with generate function and other required functions for voronoi algorithm. Another approach would be to create classes with static methods.

What approach do you use in your games? It would be great if you could show some examples.

[kamac]

Class with static methods would be the thing I'd go for. I'd also avoid namespaces.

[oahda]

I say the exact opposite to what kamac says. Unless you can somehow find a way to use voronoi objects – which you shouldn't try to if you already have a good functional system – there is no reason at all to use a class with static methods only. This isn't Java. You don't have to use a class at all times. A namespace comes with the exact same syntax (double colon) when calling these functions anyway.

[Average Software]

I am working on a strategy/roguelike in C++. I have some functions for generating maps (generating random points, voronoi) and other functions that are not dependent on game code. Then of course I have classes like Map, Entity etc.

I haven't used C++ for some time now and I can't decide how to best organize my code. Should I create a namespaces for these functions, e.g. "voronoi" with generate function and other required functions for voronoi algorithm. Another approach would be to create classes with static methods.

What approach do you use in your games? It would be great if you could show some examples.

Namespaces are the proper C++ solution.  Classes with static methods are largely a hack used by languages like Java that don't support free functions.

[oahda]

[kamac]

Prinsessa and Average Software are right 

[Boreal]

The only reason I would ever use a struct (not class) with only static methods over a namespace is if it needs to go into a template.  Namespaces can't be template parameters.

[Average Software]

Namespaces can't be template parameters.

How I wish they could.  I'd also like to be able to make templated namespaces.  I was going to write both of those up as proposals for the next language revision, but got lazy and didn't do it.

[Cheezmeister]

Namespaces are the proper C++ solution.  Classes with static methods are largely a hack used by languages like Java that don't support free functions.

In other words, Namespaces are what JC would do.

[Average Software]

Namespaces are the proper C++ solution.  Classes with static methods are largely a hack used by languages like Java that don't support free functions.

In other words, Namespaces are what JC would do.

I'm assuming that's John Carmack, in which case no, he would just do it in C.

[anthnich]

A namespace will be fine, but I personally only use namespaces for "global" free functions that need containment, or to resolve anything that might cause a name conflict. If I'm going to be storing any sort of data, I prefer to use a Singleton.

[Average Software]

A namespace will be fine, but I personally only use namespaces for "global" free functions that need containment, or to resolve anything that might cause a name conflict. If I'm going to be storing any sort of data, I prefer to use a Singleton.

This is what the unnamed namespace is for.  You put the data in the source file like so:

Code:

#include "my_header.h"

namespace
{
    // Unit data.
    int thing;
    int the_other_thing;
}

This makes the data completely inaccessible from outside the source file.  Singletons, like "static classes," are a hack used in a pure object-oriented languages like Smalltalk in order to fake this sort of internal linkage.  There's really no place for them in C++, which natively supports the features that singletons simulate.

[InfiniteStateMachine]

^^^ assuming the build system you use doesn't use source merging. Otherwise that flies out the window.

[Sik]

I'm assuming that's John Carmack, in which case no, he would just do it in C.

I avoid C++ like the plague, but if I were to use it, I'd use namespaces for this as well.

This makes the data completely inaccessible from outside the source file.  Singletons, like "static classes," are a hack used in a pure object-oriented languages like Smalltalk in order to fake this sort of internal linkage.  There's really no place for them in C++, which natively supports the features that singletons simulate.

Don't forget the part that the initialization order of singletons is completely unpredictable so you can never tell for sure when initializing if they're ready to use yet.

[InfiniteStateMachine]

What do you mean about initialization order. What if you explicitly call init on the singleton?

Are you saying the initialization order is bad because you're expecting someone to just get the singleton and have it initialize if it's the first attempt to get it? Because that's entirely avoidable and you would have a similar issue with a namespace that holds state.

[Sik]

Classes that get constructed before main executes (which is normally what singletons do) can end up being constructed in any completely arbitrary order, meaning you have to be careful that they don't rely on each other during that period or you'll hit a bug sooner or later. Note that this is not an issue with POD types (including the basic types) since they don't have constructors to be called.

[Cheesegrater]

Singletons normally get constructed the first time you ask for an instance, not before main executes.

[InfiniteStateMachine]

Yeah a singleton gets constructed on first get. If I have to use them I do like having an explicit init that must be called before the first get to prevent human error.

[Average Software]

Singletons normally get constructed the first time you ask for an instance, not before main executes.

I find this behavior completely obnoxious and it amazes me that people sometimes claim this is a benefit of singletons (not that I'm saying you're arguing that).  I want my stuff to either initialize when I tell it to so I can handle errors, or before main() so I don't even start running if there are problems.  Having possibly critical code initialize at some undisclosed future time is just a bug waiting to happen.

[InfiniteStateMachine]

That's why I'm a fan of the explicit init.

namespace with state would be like

SomeThingThatHasState::Init();

or singleton

SomeThingThatHasState::Init();

But back on topic, yes, I agree that singletons in C++ don't need to be used. It's probably just that a lot of people initially used languages where singletons are more necessary that force a class on everything and picked up singletons as a habit. I suppose you could make the argument that even in those languages you could have a static class with an init function but that would be more tedious to enforce an init call on.

I have spoken to some people that are in favor of singletons in c++ because they imply that they are holding state while a namespace might imply non-mutating functions that hide data in the cpp file via anonymous namespaces etc. I don't personally agree but it's certainly an argument.