Prev: C++ boxing
Next: Passing pointers across implementation boundaries
From: forums_mp on 14 Feb 2010 06:27
On Feb 13, 6:24 pm, Paul Bibbings <paul.bibbi...(a)gmail.com> wrote:

>
> Having not come across this `idiom' before, I have to say that at the
> outset I'm a little unsure about it too. I'm trying to figure (albeit
> with a very tired head on) what the advantage of the singleton pattern
> gives here, in returning a reference to a single static instance of an
> object whose only purpose is to expose two public static data members,
> access to which do not require instantiation of common_data_b at all.
> Or am I just /too/ tired today?

I think it's an aberration myself so that could imply i was just /too/
tired myself. In all fairness the coding standard is in it's infancy
so I suspect nows the time to 'change it/get it right'. Having said
that I'm curious to know how - in general others handle global const
data?


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Nick Hounsome on 14 Feb 2010 06:30
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).


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Ulrich Eckhardt on 15 Feb 2010 05:41
forums_mp(a)hotmail.com wrote:
> On Feb 13, 6:24 pm, "Martin B." <0xCDCDC...(a)gmx.at> wrote:
>> In you case I would do:
>> namespace my_consts {
>> static int const a = 5;
>> static double const pi = 3.141;
>>
>> }
>
> True but of course - if memory serves - this violates the ODR rule.

No, the above is stupid but fine. In every TU it declares another set of
file-static variables that don't conflict with each other.

> Every translation unit that include either (common_data_a.h or
> common_data_b.h) file will get a/their own copy of 'a' and 'PI'

Right, but does it matter? Any halfway-decent compiler will throw them out
if unused and not even create them but insert them inline if they are used.

Also, the reason I called above stupid is that you can write just as well
this:

namespace my_constants {
int const pi = 3;
}

The point is that constants have internal linkage by default, exactly so
that you can easily declare constants in a header file, and that is also
the way I would do it.


Uli

--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: forums_mp on 15 Feb 2010 05:42
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?


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Christian Kandeler on 15 Feb 2010 05:55
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.

Christian

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: C++ boxing
Next: Passing pointers across implementation boundaries