Prev: CoW and reference counting in the STL
Next: Template expansion during function template matching?
From: Kris Prad on 15 Apr 2010 07:34
This is a bad code, but I would like to know the behaviour of dtor.

The dtor is supposed to be const agnostic?
So, the following is a valid with respect to calling S::Set()?


struct S
{
int val_;

S() : val_(0) {}
~S()
{
Set(10); // ok even for const S.
}
void Set(int v)
{
val_ = v;
}
};


void TestS()
{
const S s;
//s.Set(10); // error: s is const. But dtor calls the same method
}


Kris

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

From: Daniel Krügler on 15 Apr 2010 09:31
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


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

From: Seungbeom Kim on 15 Apr 2010 09:32
On 2010-04-15 15:34, Kris Prad wrote:
> This is a bad code, but I would like to know the behaviour of dtor.
>
> The dtor is supposed to be const agnostic?
> So, the following is a valid with respect to calling S::Set()?

Yes, constness is active only after the constructor finishes and
before the destructor starts, i.e. during the lifetime of the object.

[ snipped code calling non-const S::Set(int) in S::~S() ]

--
Seungbeom Kim

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

From: Stuart Golodetz on 16 Apr 2010 04:00
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?

Regards,
Stu


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

From: Francis Glassborow on 16 Apr 2010 09:53
Stuart Golodetz 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?
>
> Regards,
> Stu
>
>

No it means that the compiler has to know enough about the hardware to handle it correctly. For example, if the hardware is really read-only then the object cannot be physically destroyed so instead the program has to make the the object accessible in the
ctor and not accessible in the dtor. However read-only normally means that there is some trap that detects attempts to write to the memory, now the compiler must produce code that wqorks round that trap both for the ctor and the dtor.


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

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