Thread View: comp.std.c++
2 messages
2 total messages
Started by Wil Evers
Thu, 28 Mar 1996 16:20
Re: initialization of nonlocal static objects
Author: Wil Evers
Date: Thu, 28 Mar 1996 16:20
Date: Thu, 28 Mar 1996 16:20
57 lines
2640 bytes
2640 bytes
In article <KANZE.96Mar27134634@gabi.gabi-soft.fr> kanze@gabi-soft.fr (J.
Kanze) writes:
> class X
> {
> public :
> enum DontInit { dontInit } ;
> X( DontInit ) {}
> X() : i( 5 ) {}
> private :
> int i ;
> } ;
>
> Objects to be initialized by the nifty_counter would be defined thus:
>
> X obj( X::dontInit ) ;
>
> Nifty counter then becomes:
>
> class NiftyCounter
> {
> static int cnt ;
> public :
> NiftyCounter()
> {
> if ( cnt == 0 )
> new( &obj ) X ;
> cnt ++ ;
> }
> } ;
>
> (Note that for NiftyCounter to work, it is absolutely essential that the
> definition of the object invoke a no-op constructor, since the object
> may in fact already be constructed.)
>
> As you can see, this works equally well for const objects.
I don't think so. For this to work on a const object, you would at least have
to cast away its constness - after all, the standard placement new operator
takes a void * as its second argument, not a const void *.
In my opinion, the `dummy constructor' technique is fundamentally bad. It
requires that all base classes and member variables have dummy constructors
too, so it is not always applicable.
When I use the nifty counter idiom, I normally construct the global
object in a suitably aligned raw memory buffer (a character array).
Users access the constructed object through a properly typed global
reference pointing to the raw memory buffer.
- Wil
---
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu ]
Re: initialization of nonlocal static objects
Author: J. Kanze
Date: Fri, 29 Mar 1996 17:06
Date: Fri, 29 Mar 1996 17:06
71 lines
3589 bytes
3589 bytes
In article <009A0041E919D6E0.3D60EEDA@ittpub.nl> "Wil Evers"
<wil@ittpub.nl> writes:
|> In article <KANZE.96Mar27134634@gabi.gabi-soft.fr> kanze@gabi-soft.fr (J.
|> Kanze) writes:
|> > class X
|> > {
|> > public :
|> > enum DontInit { dontInit } ;
|> > X( DontInit ) {}
|> > X() : i( 5 ) {}
|> > private :
|> > int i ;
|> > } ;
|> >
|> > Objects to be initialized by the nifty_counter would be defined thus:
|> >
|> > X obj( X::dontInit ) ;
|> >
|> > Nifty counter then becomes:
|> >
|> > class NiftyCounter
|> > {
|> > static int cnt ;
|> > public :
|> > NiftyCounter()
|> > {
|> > if ( cnt == 0 )
|> > new( &obj ) X ;
|> > cnt ++ ;
|> > }
|> > } ;
|> >
|> > (Note that for NiftyCounter to work, it is absolutely essential that the
|> > definition of the object invoke a no-op constructor, since the object
|> > may in fact already be constructed.)
|> >
|> > As you can see, this works equally well for const objects.
|> I don't think so. For this to work on a const object, you would at least have
|> to cast away its constness - after all, the standard placement new operator
|> takes a void * as its second argument, not a const void *.
You're right. I'm getting careless. (And the last time I did this, my
compiler still didn't enforce const-ness in this case.)
|> In my opinion, the `dummy constructor' technique is fundamentally bad. It
|> requires that all base classes and member variables have dummy constructors
|> too, so it is not always applicable.
|> When I use the nifty counter idiom, I normally construct the global
|> object in a suitably aligned raw memory buffer (a character array).
|> Users access the constructed object through a properly typed global
|> reference pointing to the raw memory buffer.
IMHO, the nifty counter idiom is in general not very good. I much
prefer to avoid the global or class static, and require the user to call
a function which returns a reference to a local static.
--
James Kanze (+33) 88 14 49 00 email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
-- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads