can anyone with his experience suggest which one is better : global constants or static constant data members? I know there won't be much difference in either approaches but still am searching for good reasons to stick with one approach.
If you are using the word 'members' you mean inside of a class. You can't have a 'global' member, you can only have static members.
So use staticconst if the constant has a meaning in a class, otherwise use a global const
Just define the constants wherever it makes the most sense to define them. If you are writing an object oriented application there should be a logical place for each constant to be defined. If a constant is defined inside of a class then it should have some logical connection to the class. I find global's to be a bit trickier because you then have to worry about whether to define them completely in the header or in the cpp. Then the extern keyword could be important. Global constants are more confusing to me which is why I try to avoid using them completely. There are many different options as far as how to define the scope of global constants and frankly they always confuse me. The simplest thing is to define them and initialize them completely within a header file (preferably within a namespace). Also, with global constants I have seen that project engineers tend to start a bad trend where you end up with a couple of files that end up as dumping grounds for hundreds of unrelated constants and every other file in the system ends up with a dependency on that file.
Hi Bazzy, well that is not exactly true. Consider this -
class Globals{
static const int a;
static const std::string y;
........
}
Now good thing is that all globals are logically grouped together within a class and they can be reference anywhere by including the header file containing Globals header file and using Globals::a.
Yes but they are static members. The OP was asking for global or static members
BTW I may have wrongly connected 'data members' to 'global' when reading that post...
Well, maybe my initial post is not very clear but what I am asking is : what is the correct strategy for maintaining common data of a project. Two ways I am aware of 1. Global consts 2. a class containing static const data members as shown in example above.
See what kempofighter said. If a const is related to a class, use it as class member. If it will be used by many unrelated casses/functions/whatever use a global.
It is always tough to decide where to put some constants. I don't really see any benefit for creating a class called globals that ends up as a dumping ground for constants. Put each constant where it makes sense. I definitely agree with the principle but not the specific execution that parihu suggested. If there are a bunch of constants related to a logservice then put those constants in a logservice package (not necessarily a class but at the very least a namespace in a header file). Don't just create one class and put hundreds of unrelated things into it. You might have a package where you define the integer types for the project and you might also have some size constants that are related and they could be colocated. Just use common sense and define constants in logically related packages or classes.
By the way, I'm using the term packages as it relates to an object oriented modeling tool. A package is simply a set of .h/.cpp files but not necessarily with classes. It could just contain a namespace with constants and/or functions. Perhaps the original question was, should I create classes that have no purpose other than to define a bunch of constants? I'm not really sure if that is better/worse than just defining the constants within a namespace, honestly. It could be done either way. In C# everything must be within a class. if you are trying to write an OO project and you want all things to exist within the scope of some class, you could certainly do that.
Thanks kempofighter, that does make sense and I have now moved constants into a header file within a namespace. I agree there is no benefit of using the class for grouping them.