From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-10-30 12:02:30
Martin Bonner wrote:
> It is a requirement of the standard that static objects are zero
> initialized before the constructor runs. Compilers sometimes fail to
> implement the standard for various reasons (backwards compatibility,
> bugs, etc). What I am saying is that the natural way of implementing
> static objects on most implementations will automatically meet this
> requirement of the standard - so it is fairly safe to rely on.
Ok. I think in the meantime I understood what you wanted to tell me.
Sorry, that I didn't understand you on the first reading.
However designing an object in this manner still sounds very odd to me.
Indeed we have two different states of this so called object:
1) The object is kind of an aggregate (before the ctor has been run).
Of course it may be accessed at this stage if properly designed,
but it still is dangerous because a user might think it already
_is_ an object.
2) The object got live (ctor has been run). Now if it happens, that
the object gets onto the stack, the user must not forget to
initialize it! She must not use the ctor in this case of course.
And this looks very dangerous to me, since I normally would
expect a ctor to properly initialize the object!
(Why would one ever put a mutex on the stack? Obviously not
directly, but this can happen all to easily when embedded in
For this reason I believe letting the programmer know that the
mutex is POD, is far more safe, since this is something common.
You always need to specify initializations for POD's.
Beeing not able to prevent the copy ctor I think is not such a big
problem at all. One already is used to think about this when having
pointers in the object. Perhaps it would even be better to make the
pointer characteristic of mutex explicit to alert the user?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk