Prev: CoW and reference counting in the STL
Next: Template expansion during function template matching?
From: Daniel Krügler on 16 Apr 2010 09:53
On 16 Apr., 21:00, Stuart Golodetz
<sgolod...(a)NdOiSaPlA.pMiPpLeExA.ScEom> wrote:
> Daniel Kr�gler wrote:
> > On 16 Apr., 00:34, Kris Prad <krisp...(a)yahoo.co.uk> wrote:
> >> This is a bad code, but I would like to know the behaviour of dtor.
>
> >> The dtor is supposed to be const agnostic?
>
> > Yes.
>
> >> So, the following is a valid with respect to calling S::Set()?
>
> > Yes.
>
> > Now a bit more details: While on a first view the above
> > observation (dtor is const agnostic) may look like an
> > odd rule, there is some simple principle that helps to
> > understand the rationale for this: Consider cv- (i.e.
> > const-volatile) qualifications as characteristics of
> > a full-fledged object. An object is "full-fledged"
> > when it's life-time has started and not yet ended.
> > The life-time of an object is a dynamic property and
> > begins after it has been initialized, for class types
> > this is the successful invocation of the constructor.
> > The life-time for a class type ends, when the destructor
> > call begins. Both within the constructor and within the
> > destructor a class type may change any of it's (non-const)
> > members - even, if the actual object is const! At some
> > point the transition between a "living"/full-fledged
> > object and a no-longer living object must happen and
> > this is the point, where the destructor is called. Up
> > to this point, const objects can only call const member
> > functions, but the destructor must be callable even for
> > const objects, because otherwise it would be impossible
> > to end the life-time of these.
>
> > HTH & Greetings from Bremen,
>
> > Daniel Kr�gler
>
> Just out of interest: how does this interact with the whole thing of trying to modify a physically const object leading to undefined behaviour? Regardless of whether the object is currently fully-fledged or not, its members are stored in memory somewhere
> at the point where the destructor call begins, correct? So if val_ has to be modifiable in the destructor, does this mean that if you actually do this, the compiler isn't allowed to put physically const instances of S in read-only memory?
>

I'm not an expert for different memory
representation techniques, but at least
for some dynamic forms of read-only
memory protections it is possible to
activate the read-only protection in
a second step (e.g. memory-mapped files
on Windows). Second, the argument only
applies to non-trivial destructors, so
it might simply be that non-trivial
destructors prevent such a protection
at least for some scenarios/implementations.

Greetings from Bremen,

Daniel Kr�gler


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

From: red floyd on 16 Apr 2010 16:49
On 4/16/2010 12:00 PM, Stuart Golodetz wrote:

[redacted]
> Just out of interest: how does this interact with the whole thing of
> trying to modify a physically const object leading to undefined
> behaviour? Regardless of whether the object is currently fully-fledged
> or not, its members are stored in memory somewhere at the point where
> the destructor call begins, correct? So if val_ has to be modifiable in
> the destructor, does this mean that if you actually do this, the
> compiler isn't allowed to put physically const instances of S in
> read-only memory?
>

I think it's not an issue, because it wouldn't be able to do the
construction (set val_ to 0) either.


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

First  |  Prev  | 
Pages: 1 2
Prev: CoW and reference counting in the STL
Next: Template expansion during function template matching?