Why define constants in a class versus a namespace? [duplicate]

This question already has answers here: Closed 11 years ago.

Possible Duplicate:

Static members class vs. normal c-like interface

I am looking at somebodies code and there are several dozen constants defined in a class like this:

// header file

class Defines
{
public:
    static const int Val1;
    static const int ValN;
    static const char* String1;
    static const char* StringN;
...
}

// .CPP
const char* Defines::String1 = "some value"
etc.

Is there some reason to do things this was as opposed to using a namespace instead? Are there advantages/disadvantages of one over the other

--------- Edit ----------

I'm sorry, I obviously should have pointed this out explicitly, as nobody has inferred it from the name of the class - which is "Defines". i.e. these constants are not associated with a particular class, there has been a class created specifically just to hold constants and nothing else, that is all the class Defines contains.

My question is not why should you place constants in a particular class, the question is is there any value in collecting dozens of them t开发者_如何学Pythonogether and placing them in a class whose only purpose is to collect together constants, as opposed to collecting them together in a namespace, or just collecting them together in a header file specifically for that purpose etc.

(There is no currently existing namespace in the project therefore potential issues of polluting the namespace as mentioned in answers are not relevant in this case.)

----- 32nd edit -----------

and a follow up question --- is placing const char* Defines::StringN = "Somevalue"

in the .h file inefficient versus placing it in the .cpp file?

---

Because those constants may be tightly coupled to that class. IE Maybe members of the class take those constants as arguments or return them. Maybe the only place they are meaningful is in the interface to this class, so putting them in a separate namespace doesn't make sense because they only matter to that class.

---

There is no reason to do it the way it is done here; just like there is not really a reason to use class Defines { public: ... }; instead of struct Defines { ... };. Perhaps whoever wrote the code had previously been writing in a language that does not support namespaces/global variables in namespaces, or thought that this looked `neater' than a lot of extern statements and a namespace.

There is some practical use for this, however, if you intend to make some of these constants private, and then give access to only a few functions/classes. From the looks of it, however, this isn't the case, and it would make sense to change this to be a namespace -- that way, one could use using Defines::constant; and similar.

Response to first edit: The global namespace is also a namespace, and it is more dangerous to pollute than other namespaces, as things are more likely to leak into it. In that sense, it is better to put the variables in a class, but still not as good as putting them in a namespace of their own.

Response to second edit: const char* Defines::StringN = "Somevalue"; in a header would lead to the constant being defined multiple times, and the program would fail to link. However, if you prepend an extern to that, and put the definition in a .cpp file, everything will be fine, and there should be no performance penalty.

---

For a few reasons:

1. You're not cluttering your namespace with potentially random constants.
2. You're adding meaning to both the class and the constants themselves by including them with their associated class.

If I were to define a global/namespace constant named NAME, then what is it associated with? If I added into the class itself, then you're forced to reference is with the class name, which adds meaning to the usage and makes the code more readable and less error prone.

Of course, this can be abused. You can misplace constants. You can improperly put truly global constants in specific classes. You can, in both cases, give bad names.

---

In general, there's no reason to use a type this way. I have seen it argued that if the "collection of constants" evolves into a concrete object, starting this way makes the transition easier. In practice, I've never seen this happen. It just hides intent, and potentially flutters the code with private constructors.

One could argue that classes work with templates, while namespaces do not. So something like the following would only work if Defines is a class:

template<typename T> int function() {
    return T::x + T::y;
}
//later
cout << function<Defines>() << function<OtherDefines>() << endl;

In most cases, there's probably a redesign that would work better, particularly if all you have are "constants" that aren't really. Occasionally, this may come in handy, though.

At times, it can also fight argument dependent lookup. In brief, the compiler is allowed to expand it's search for eligable function names to different name namespaces based on the parameters passed to the function. This does not extend to static functions of a class. This applies more to the general case, though, where the "static class" also includes nested types and functions in addition to the collection of constants.

Why people do this varies. Some come from languages where can't be used this way, others just don't know any better.

---

For most things, it makes sense to give them the smallest scope possible. In this case its not so much an issue of visibility, but in clarity.

If you see String1 in a method, you have no idea where it came from. If you see Defines::String1, you can say "OK, this is a variable from the class Defines, let me go there and see what it is and what it's supposed to be". Looking in one class is a lot better than looking through an entire namespace that might even be spread across multiple source files. Obviously if the variable is in a class because its used primarily in that class, there's no doubt whatsoever that's that's where it should be. :D