next »

[Orz]

I have a handful of functions and variables in my project that I'd like to make global.  Right now they are in a utility class, so I have to keep typing out "global::randomFloat()" and so forth.  There are a couple of strategies for putting globals in a C++ project so they're accessible to any file, and I wondered what other folks were using.

[kamac]

Uhm. Do you simply want to share your utility class between files, so that it's accessible from anywhere?

The only way to do that is to have a .h file, and an optional .cpp file to it.

Example, utility.h:

Code:

#ifndef MYUTILITY_H
#define MYUTILITY_H

class utility
{
    public:
    void someFunc();
};
#endif

utility.cpp:

Code:

#include "utility.h"

void utility::someFunc()
{
    // do something
}

Then just include utility.h from anywhere.

Or is that not what you wanted?

[zacaj]

I usually just do extern in a header and then just declare them in some random source file

[Eigen]

What kind of global variables are these? First of all, do you really need them? If you do and if they are each specific to one feature of the game I would divide them up into singletons along with whatever functionality you might have relating to them.

[Orz]

I usually just do extern in a header and then just declare them in some random source file

I will probably do that.  It really is just because I'm anal about having to type out "global::" every time.

[Kekskiller]

Why don't you just put them into a namespace with no wrapper class so you can use the namespace in the files were you need them (no "global::"). And if you really want to have the constructor of the utility singleton you can put it there, too, and access the vars like they were in the class (same namespace).

[Eigen]

Again, what kind of variables are these, what do you use them for and do you really need to use them in such a way?

[Orz]

do you really need to use them in such a way?

What is this, Stack Overflow?

Why don't you just put them into a namespace with no wrapper class so you can use the namespace in the files were you need them (no "global::"). And if you really want to have the constructor of the utility singleton you can put it there, too, and access the vars like they were in the class (same namespace).

Thanks, that might work too.  I'll try a couple methods and keep the one which is least annoying.

[Average Software]

I write namespace modules.  The art of the module (well known to C programmers) seems to be lost on a lot of C++ developers, possibly because they have drunk too deeply of the OOP Kool-aid.

Since your example mentioned random numbers, here's a simple module that I use for my own:

Code:

// Pseudo-random number generator

#ifndef RANDOM_H
#define RANDOM_H

namespace Random
{
    // Traits type for the enumeration random.
    template <typename>
    struct Traits;

    // Seed the generator.
    void seed(unsigned n);

    // Get a new value.
    unsigned get();

    // Get a new value within a certain range.
    int get_in_range(int min, int max);

    // Get a random value for an enumeration.
    template <typename Type>
    Type get_enum();

    // Get a random enumeration value within a certain range.
    template <typename Type>
    Type get_enum_in_range(Type min, Type max);
}

// Inline functions and templates.
template <typename Type>
inline
Type Random::get_enum()
{
    return static_cast<Type>(get_in_range(Traits<Type>::min, Traits<Type>::max));
}

template <typename Type>
inline
Type Random::get_enum_in_range(Type min, Type max)
{
    return static_cast<Type>(get_in_range(min, max));
}

// Macros.
// Macros for conveniently declaring and defining enum traits.
#define DECLARE_RANDOM_ENUM_TRAITS(Type, minimum, maximum) \
namespace Random \
{ \
    template <> \
    struct Traits<Type> \
    { \
        static \
        const Type min = minimum; \
        static \
        const Type max = maximum; \
    }; \
}

#define DEFINE_RANDOM_ENUM_TRAITS(Type) \
const Type Random::Traits<Type>::min; \
const Type Random::Traits<Type>::max;

#endif

Code:

// Pseudo-random number generator

#include "random.h"
#include <cassert>
#include <inttypes.h> // Not standard as of C++98.

using namespace Random;

namespace
{
    // State values.
    uint32_t seed_low;
    uint32_t seed_high;
}

void Random::seed(unsigned n)
{
    seed_low = n;
    seed_high = ~n;
    get();
}

unsigned Random::get()
{
    seed_high = (seed_high << sizeof(unsigned) * 4) + (seed_high >> sizeof(unsigned) * 4);
    seed_high += seed_low;
    seed_low += seed_high;

    return seed_high;
}

int Random::get_in_range(int min, int max)
{
    assert(min <= max);

    int value = get() % (max - min + 1);

    return value + min;
}

The key to the whole thing is the unnamed namespace, which contains data local to the translation unit.  This allows you to keep "global" variables while still controlling access to them through the functions in the external namespace.

[Eigen]

do you really need to use them in such a way?

What is this, Stack Overflow?

With that attitude no one should be interested in helping you. I'm not, not anymore.

[InfiniteStateMachine]

I write namespace modules.  The art of the module (well known to C programmers) seems to be lost on a lot of C++ developers, possibly because they have drunk too deeply of the OOP Kool-aid.

Since your example mentioned random numbers, here's a simple module that I use for my own:

Code:

// Pseudo-random number generator

#ifndef RANDOM_H
#define RANDOM_H

namespace Random
{
    // Traits type for the enumeration random.
    template <typename>
    struct Traits;

    // Seed the generator.
    void seed(unsigned n);

    // Get a new value.
    unsigned get();

    // Get a new value within a certain range.
    int get_in_range(int min, int max);

    // Get a random value for an enumeration.
    template <typename Type>
    Type get_enum();

    // Get a random enumeration value within a certain range.
    template <typename Type>
    Type get_enum_in_range(Type min, Type max);
}

// Inline functions and templates.
template <typename Type>
inline
Type Random::get_enum()
{
    return static_cast<Type>(get_in_range(Traits<Type>::min, Traits<Type>::max));
}

template <typename Type>
inline
Type Random::get_enum_in_range(Type min, Type max)
{
    return static_cast<Type>(get_in_range(min, max));
}

// Macros.
// Macros for conveniently declaring and defining enum traits.
#define DECLARE_RANDOM_ENUM_TRAITS(Type, minimum, maximum) \
namespace Random \
{ \
    template <> \
    struct Traits<Type> \
    { \
        static \
        const Type min = minimum; \
        static \
        const Type max = maximum; \
    }; \
}

#define DEFINE_RANDOM_ENUM_TRAITS(Type) \
const Type Random::Traits<Type>::min; \
const Type Random::Traits<Type>::max;

#endif

Code:

// Pseudo-random number generator

#include "random.h"
#include <cassert>
#include <inttypes.h> // Not standard as of C++98.

using namespace Random;

namespace
{
    // State values.
    uint32_t seed_low;
    uint32_t seed_high;
}

void Random::seed(unsigned n)
{
    seed_low = n;
    seed_high = ~n;
    get();
}

unsigned Random::get()
{
    seed_high = (seed_high << sizeof(unsigned) * 4) + (seed_high >> sizeof(unsigned) * 4);
    seed_high += seed_low;
    seed_low += seed_high;

    return seed_high;
}

int Random::get_in_range(int min, int max)
{
    assert(min <= max);

    int value = get() % (max - min + 1);

    return value + min;
}

The key to the whole thing is the unnamed namespace, which contains data local to the translation unit.  This allows you to keep "global" variables while still controlling access to them through the functions in the external namespace.

I remember you posting about this before and I really took a shining to it since then. Thanks for sharing that 

[Orz]

I write namespace modules.  The art of the module (well known to C programmers) seems to be lost on a lot of C++ developers, possibly because they have drunk too deeply of the OOP Kool-aid.

That is a great trick.  I was doing something like that before, but only in single-file programs...I never tried to include it as a header.  I'm quite fond of OOP for games, but I had to be dragged in kicking and screaming.

[Klaim]

Stop coding right now and go learn how the compilation process works. I'm serious. You will be baffled regularly by code you'll see around if you don't and ask such strange questions again. That's my first and last advice as your stackoverflow remark also makes me think it's not worth loosing more of my time.

[Kekskiller]

This thread is a good example for why humans will never stop waging wars against each other, figuratively speaking.

[darkhog]

Dunno about c==, but in Java/C# I'm using static classes with static members for this. Again, dunno if c++ has thing like that.

Declaration:

Code:

public static Globals{
public static string HerosName;
public static string HerosLifeCount;
//...
}

Then when I want to change/get value, I'm doing thing like:

Code:

Globals.HerosName = "The Savior of The Universe"

[motorherp]

Since I've seen it suggested a couple times here already I just want to add that Singletons are for specifically enforcing that a class can only ever be instantiated once.  Singletons are not a good solution for solving global access issues.  I'm always seeing people suggest singletons for solving these sorts of problems .... stop it, its wrong  .

[powly]

Wtf guys, he just wants to skip writing a few letters

Code:

#define randomFloat(a) global::randomFloat(a)

[darkhog]

Since I've seen it suggested a couple times here already I just want to add that Singletons are for specifically enforcing that a class can only ever be instantiated once.  Singletons are not a good solution for solving global access issues.  I'm always seeing people suggest singletons for solving these sorts of problems .... stop it, its wrong  .

Can you explain why it's wrong? Seriously, I can't see issue there with it - it works, it doesn't leak memory, doesn't crash software...

[motorherp]

Since I've seen it suggested a couple times here already I just want to add that Singletons are for specifically enforcing that a class can only ever be instantiated once.  Singletons are not a good solution for solving global access issues.  I'm always seeing people suggest singletons for solving these sorts of problems .... stop it, its wrong  .

Can you explain why it's wrong? Seriously, I can't see issue there with it - it works, it doesn't leak memory, doesn't crash software...

Discounting the instantiation restriction, singletons are really little more than thinly veiled globals anyway, they dont in any way solve any of the issues associated with global state.  Many people use (or advice use of) singletons not because they want to restrict instantiation but simply because they want the simplicity of global access but they've heard that globals are bad.  If you're using singletons in this way you're not actualy solving anything, but you're placing additional restrictions on your project that likely aren't necessary and could be problematic in the future.  Stop lying to yourself and just use a global, or if you are concerned about global state then use dependancy injection or a factory pattern.  Singletons are only appropriate in the case were you really do need to restrict instantiation to one object instance.

[Daid]

Since I've seen it suggested a couple times here already I just want to add that Singletons are for specifically enforcing that a class can only ever be instantiated once.  Singletons are not a good solution for solving global access issues.  I'm always seeing people suggest singletons for solving these sorts of problems .... stop it, its wrong  .

Can you explain why it's wrong? Seriously, I can't see issue there with it - it works, it doesn't leak memory, doesn't crash software...

Same for using tape to keep a painting to the wall. It works, but tape was not intended for that use. Same for singletons.

However, I think singletons are the most overjust abused pattern there is. Usually things do not need to be a singleton. And who-ever says that globals are always bad just needs to be shot.

Now, I do not recommend naming something "Global", not a namespace or static class. Your global state clearly belongs to something. "Random::currentSeed", "PlayerState::name" is better then "Global::randomSeed" "Global::PlayerName"