global variables - an alternate approach
in [C++]
|
From: Francis Glassborow on 15 Feb 2010 13:10 Christian Kandeler wrote: > forums_mp(a)hotmail.com wrote: > >> For starters the emphasis is on 'global' variables common to muliple >> translation units >> >> Coding standard states that global variables should be defined as >> static variables' within a class at public scope. One instance of >> this class should exist and the recommendation is to use the singleton >> design patten. IOW: >> >> //common_data_b.h >> # ifndef COMMON_DATA_B_H >> # define COMMON_DATA_B_H >> >> #include <iostream> >> class common_data_b { >> public : >> static int const a = 5 ; >> static const double pi ; >> static >> common_data_b& intance() { >> static common_data_b cd_b; >> return cd_b; >> } >> }; >> #endif > > Other aspects aside, it is just silly to create an instance of a class that > has only static members. The Singleton pattern doesn't buy you anything > here, because the members are not created on-demand anyway. > Use a namespace instead: namespace math_constants ( long double const pi(3.145926) long double const e()2.7...) etc. } Has the advantage that it is expendable. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Nick Hounsome on 16 Feb 2010 02:18
On 15 Feb, 22:42, forums...(a)hotmail.com wrote: > On Feb 14, 6:30 pm, Nick Hounsome <nick.houns...(a)googlemail.com> > wrote: > > > > > On 13 Feb, 03:40, forums...(a)hotmail.com wrote: > > > > For starters the emphasis is on 'global' variables common to muliple > > > translation units > > > > Coding standard states that global variables should be defined as > > > static variables' within a class at public scope. One instance of > > > this class should exist and the recommendation is to use the singleton > > > design patten. IOW: > > > Putting aside the singleton issue it is wrong to lump stuff together > > just because it is all used by multiple translation units. > > > globals.h is just as bad an idea as the all too common errors.h > > > Lumping stuff together in this way creates artificial coupling that > > makes it hard or impossible to reuse parts of your code independently. > > > The longer the code is maintained the worse it will get (This is > > always true but particularly so for "common" files). > > True! but do I then have every translation unit/developer carry around > 'his' own copy of - say - PI and /those/ MAX number variables that's > universal to a system? No. You have common headers but you have more than one and each should contain a LOGICALLY realated set of constants. e.g. PI almost certainly belongs in a namespace "math" in a file "mymath.h" (unfortunately math.h is taken) You don't actually give a good example (what is a?) but MAX type limits would normally go in the header of the thing that they limit e.g. If I have a Person class and for some strange reason (it's not very C++) I want to limit a name length to 42 then I make that a constant in the Person class. If I am constraining a library Person class for a particular app then I may well need a separate PersonLimits.h It's true that we all tend to have an urge to have all files be similar sizes, none too big and none too small but that doesn't make it right - If you logically require a header with only a single constant then so be it. It is better than stuffing it in somewhere it doesn't belong and over the years and revisions it may well acquire some logical companions. Another way to look at it is like this - You've called your class common_data_b. What does that name tell a reader? Nothing at all except that there is probably a common_data_a somewhere and you have no LOGICAL reason for separating them whereas names like math and numeric_limits have meaning. Usually it's not even true that it is common in the sense that typically there is no compilation unit that uses all of its members All this has actually deviated from the OP which is actually about global VARIABLES rather than CONSTANTS. If you find that you have a load of global mutable variables then you have almost certainly failed to identify some objects in your analysis and you are just writing (bad) C. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |