Why can operator delete be called on a const pointer?

181 views
Skip to first unread message

Thomas J

unread,
Dec 4, 2005, 2:47:23 PM12/4/05
to
Hi!

I wondered when i saw a method like this:

void MyClass::selfDestruction() const
{
delete this;
}

void iAmNotEvil(MyClass const* pMyClass)
{
p->selfDestruction();
}

Why is this possible? When I call a const method i recommend nothing
being changend, and in this case the object is being deleted. In my
eyes this shouldn't be possible, maybe I overlooked something.

Greetings


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

Alf P. Steinbach

unread,
Dec 4, 2005, 7:25:58 PM12/4/05
to
* Thomas J:

> Hi!
>
> I wondered when i saw a method like this:
>
> void MyClass::selfDestruction() const
> {
> delete this;
> }
>
> void iAmNotEvil(MyClass const* pMyClass)
> {
> p->selfDestruction();
> }
>
> Why is this possible? When I call a const method i recommend nothing
> being changend, and in this case the object is being deleted. In my
> eyes this shouldn't be possible, maybe I overlooked something.


Destruction is simply construction in reverse.

During construction and destruction the object is not const, even if it
is const in between these two end-points of the life cycle.

Consider

struct Ballooba {};

Ballooba const* const p = new Balloba;

This is much of the point of constness: a guarantee that at least via
this pointer the object won't be modified between initialization and
destruction.

But if you couldn't call delete with that pointer as argument, you
couldn't have a const dynamically allocated object: const would then
only be for locals, statics and members -- or for cast-ridden code...

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Thomas Maeder

unread,
Dec 4, 2005, 7:57:04 PM12/4/05
to
"Thomas J" <qui...@googlemail.com> writes:

> I wondered when i saw a method like this:
>
> void MyClass::selfDestruction() const
> {
> delete this;
> }
>

> Why is this possible?

The reasoning is that const extends to the lifetime of the object
only. The lifetime of an object starts when its constructor has been
fully executed and ends when its destruction starts.


> When I call a const method i recommend nothing
> being changend, and in this case the object is being deleted. In my
> eyes this shouldn't be possible, maybe I overlooked something.

You are in good company (not mine, though, but I'm sure you can live
with that) AFAICT. What you are asking seems to be a religious
question.

David Abrahams

unread,
Dec 5, 2005, 5:34:49 AM12/5/05
to
"Thomas J" <qui...@googlemail.com> writes:

> Hi!
>
> I wondered when i saw a method like this:
>
> void MyClass::selfDestruction() const
> {
> delete this;
> }
>
> void iAmNotEvil(MyClass const* pMyClass)
> {
> p->selfDestruction();
> }
>
> Why is this possible?

For the same reason that a const object can be destroyed when it goes
out of scope. Ending the lifetime of an object is not considered a
mutating operation.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Maciej Sobczak

unread,
Dec 5, 2005, 7:27:40 AM12/5/05
to
Thomas J wrote:

> When I call a const method i recommend nothing
> being changend, and in this case the object is being deleted.

This is philosophical, but try to think this way: after deleting, you
have absolutely no possibility to check whether anything has changed in
the given object (you cannot access it), so you also have no possibility
to *prove* that its constness was violated. ;)


--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/

Dave Harris

unread,
Dec 5, 2005, 11:52:40 AM12/5/05
to
mae...@glue.ch (Thomas Maeder) wrote (abridged):

> > When I call a const method i recommend nothing
> > being changend, and in this case the object is being deleted. In my
> > eyes this shouldn't be possible, maybe I overlooked something.
>
> You are in good company

In particular, the C++ Annotated Reference Manual agrees with the original
poster. It has some discussion in $5.3.4, which concludes:

Without the restriction against deleting pointers to const
objects the delete operator would have the effect of implicitly
removing the const attribute from a pointer. No operator
should have that property.

-- Dave Harris, Nottingham, UK.

Sektor van Skijlen

unread,
Dec 6, 2005, 5:31:06 AM12/6/05
to
Dnia 5 Dec 2005 11:52:40 -0500, Dave Harris skrobie:

> mae...@glue.ch (Thomas Maeder) wrote (abridged):
> > > When I call a const method i recommend nothing
> > > being changend, and in this case the object is being deleted. In my
> > > eyes this shouldn't be possible, maybe I overlooked something.
> >
> > You are in good company

> In particular, the C++ Annotated Reference Manual agrees with the original
> poster. It has some discussion in $5.3.4, which concludes:

> Without the restriction against deleting pointers to const
> objects the delete operator would have the effect of implicitly
> removing the const attribute from a pointer. No operator
> should have that property.

This seems to be completely wrong for me.

The 'delete' operator is not just a normal operator, which receives normal
arguments. You could define, for example, operator +, which will take a pointer
to appropriate type and its variance must be saved.

In case of both 'new' and 'delete' operators, there is no direct passing from
the form of its call to its implementation. And it does not change anything
that the "operator delete" function receives void* type, which can accept any
other data pointer type. Such a conversion does not happen in this case, nor
does it happen in case of 'new' operator.

Similarly, we could ask, why 'new' operator converts implicitly from void* to
pointer to an object. Moreover, why there's no different versions for operator
new( void* ) and operator new( const void* ), selected according to if the
user requested "new Obj()" or "new const Obj()". Consequences in case of
different method of allocation, permissions for these operations etc., I give
up to your imaginary.

If we want to look deeper into this topic, we could also ask, why you can
destroy an object, which's destructor is not const. You can be pushed to an
angle seeing that making it so strict would make you also unable to delete the
object at all (unless you violate the variance with const_cast).

I'd prefer to stop this paranoia.

It's best to accept that the 'operator delete' function is called INTERNALLY
by the language runtime (from within delete expression) and no pointer
conversion rules apply here. This same rule applies to 'new' operator and
'operator new' function as well.

Note: you can still use 'operator delete' and 'operator new' functions as
well. But in such a case the rules of pointer conversion do apply, as they do
in case of any other function called directly (in particular, which's call
expression directly refers to definition of its interface).


Regards,
Sektor

--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)wp.pl>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

benben

unread,
Dec 6, 2005, 5:39:58 AM12/6/05
to
> This is philosophical, but try to think this way: after deleting, you
> have absolutely no possibility to check whether anything has changed in
> the given object (you cannot access it), so you also have no possibility
> to *prove* that its constness was violated. ;)
>
>

That said, it is bad practice to destroy const objects anyway. How do
you know the object is heap-allocated. If you can be certain, you should
be able to delete the non-const version anyway.

Ben

Sektor van Skijlen

unread,
Dec 6, 2005, 8:12:15 AM12/6/05
to
Dnia 6 Dec 2005 05:39:58 -0500, benben skrobie:

> > This is philosophical, but try to think this way: after deleting, you
> > have absolutely no possibility to check whether anything has changed in
> > the given object (you cannot access it), so you also have no possibility
> > to *prove* that its constness was violated. ;)
> >
> >

> That said, it is bad practice to destroy const objects anyway. How do
> you know the object is heap-allocated. If you can be certain, you should
> be able to delete the non-const version anyway.

I got a feeling that you are mixing two separate things. If you want to
perform 'delete' on a pointer to object, you must ensure that it is
appropriate (two things should be taken into consideration: whether the object
was allocated with 'new' rather than created by any other way, including
automatic on the stack, and whether the information provided for this pointer
is enough to destroy it correctly - that is, if it points to object's base
class, whether this base class is polymorphic with virtual destructor).

The pointer/reference variance (CV-q) does not mean anything in this case.


--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)wp.pl>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

[ See http://www.gotw.ca/resources/clcm.htm for info about ]

Martin Bonner

unread,
Dec 6, 2005, 8:34:57 AM12/6/05
to

benben wrote:
> > This is philosophical, but try to think this way: after deleting, you
> > have absolutely no possibility to check whether anything has changed in
> > the given object (you cannot access it), so you also have no possibility
> > to *prove* that its constness was violated. ;)
> >
> >
>
> That said, it is bad practice to destroy const objects anyway. How do
> you know the object is heap-allocated. If you can be certain, you should
> be able to delete the non-const version anyway.

Not necessarily. Consider:
const int *p = new const int(0);

There /is/ no non-const version to delete. (You could use const_cast
to get an int* to delete, and I think that is even required by the
standard to work. However I would be happy to be proved wrong, and
even it is legal it is certainly not moral.)

Dave Harris

unread,
Dec 7, 2005, 9:36:40 AM12/7/05
to
etho...@pl.wp.spamu.lubie.nie.invalid (Sektor van Skijlen) wrote
(abridged):

>> In particular, the C++ Annotated Reference Manual agrees with the
>> original poster. It has some discussion in $5.3.4, which concludes:
>>
>> Without the restriction against deleting pointers to const
>> objects the delete operator would have the effect of implicitly
>> removing the const attribute from a pointer. No operator
>> should have that property.
>
> This seems to be completely wrong for me.

The premise here is that the delete operator effectively modifies the
object. Given that, I think the ARM reasoning is sound. (I only quoted a
small snippet of it.)


> Similarly, we could ask, why 'new' operator converts implicitly from
> void* to pointer to an object.

It can safely do that because it has constructed the object. Indeed,
that's its job.


> Moreover, why there's no different versions for operator new( void* )
> and operator new( const void* ), selected according to if the
> user requested "new Obj()" or "new const Obj()".

Placement new conceptually modifies the memory it's given. So does
operator delete(). Even if the object has no user-defined state, the
compiler itself may need to modify it, eg to install a vtable pointer or
other book-keeping/debugging info.

I don't think anyone is asking for const overloads of these in this
thread. There's clearly a difference between the delete operator and
operator delete.


> If we want to look deeper into this topic, we could also ask, why you
> can destroy an object, which's destructor is not const.

Indeed, in a case like:
static const Object obj;

the const must be removed before the object's destructor is run. However,
it doesn't follow that the delete operator is what should do this job.

-- Dave Harris, Nottingham, UK.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]

Dave Harris

unread,
Dec 7, 2005, 9:34:59 AM12/7/05
to
martin...@yahoo.co.uk (Martin Bonner) wrote (abridged):

> Not necessarily. Consider:
> const int *p = new const int(0);
>
> There /is/ no non-const version to delete.

In non-template situations you can add one, perhaps wrapped in a smart
pointer, like:

template <typename T>
class Const {
T *p;
public:
Const( T *p = new T() ) : p(p) {}
const T *operator->() const { return p; }
const T &operator*() const { return *p; }
void destroy() { delete p; }
};

void test1() {
Const<int> p = new int();

p.destroy(); // Replaces delete p.
}

The wrapper makes sure the non-const version does not escape - the only
(purported) non-const operation you can do to Const::p is delete.

I suspect the persuasive examples involve template code:

template <typename T>
void test2( T *p1 ) {
T *p2 = new T();
delete p2;
}

would be an error if instantiated with (const int). Despite that, I
personally agree with the ARM: the delete operator conceptually modifies
its argument. I'd gladly sacrifice test2() to get const-correctness back.
There are other ways to write it.

-- Dave Harris, Nottingham, UK.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]

Seungbeom Kim

unread,
Dec 9, 2005, 10:13:38 AM12/9/05
to
Dave Harris wrote:
> etho...@pl.wp.spamu.lubie.nie.invalid (Sektor van Skijlen) wrote
> (abridged):
>
>>>In particular, the C++ Annotated Reference Manual agrees with the
>>>original poster. It has some discussion in $5.3.4, which concludes:
>>>
>>> Without the restriction against deleting pointers to const
>>> objects the delete operator would have the effect of implicitly
>>> removing the const attribute from a pointer. No operator
>>> should have that property.
>>
>>This seems to be completely wrong for me.
>
> The premise here is that the delete operator effectively modifies the
> object. Given that, I think the ARM reasoning is sound. (I only quoted a
> small snippet of it.)

This is a matter of whether to consider deleting as a kind of modifying.
I could argue against it because modifying x means (old x) != (new x)
and in the case of delete (new x) doesn't even exist and the inequality
doesn't hold. :)

(I say "I 'could'" because I mean that it is reasonable to argue so,
though I admit that other interpretations are also possible.)

>>If we want to look deeper into this topic, we could also ask, why you
>>can destroy an object, which's destructor is not const.
>
> Indeed, in a case like:
> static const Object obj;
>
> the const must be removed before the object's destructor is run. However,
> it doesn't follow that the delete operator is what should do this job.

Why not?

const Object* p = new const Object;
// what 'new' does:
// (a) creates an Object
// (b) labels it const
// (c) returns the const object
delete p;
// what 'delete' does:
// (c) receives the const object
// (b) removes its const label
// (a) destroys the Object

This symmetry seems perfectly reasonable to me.

--
Seungbeom Kim

Niklas Matthies

unread,
Dec 9, 2005, 1:35:15 PM12/9/05
to
On 2005-12-09 15:13, Seungbeom Kim wrote:
:

> const Object* p = new const Object;
> // what 'new' does:
> // (a) creates an Object
> // (b) labels it const
> // (c) returns the const object
> delete p;
> // what 'delete' does:
> // (c) receives the const object
> // (b) removes its const label
> // (a) destroys the Object
>
> This symmetry seems perfectly reasonable to me.

One could argue that it is not reasonable for the same reason that
normally non-const implicitly converts to const but not vice versa.

-- Niklas Matthies

Paavo Helde

unread,
Dec 9, 2005, 9:16:49 PM12/9/05
to
"Thomas J" <qui...@googlemail.com> wrote in news:1133719758.592458.17710
@g44g2000cwa.googlegroups.com:


> Why is this possible? When I call a const method i recommend nothing
> being changend, and in this case the object is being deleted. In my
> eyes this shouldn't be possible, maybe I overlooked something.

Yes, you are mixing up the goal and the means to achieve the goal. The
const modifier lets you know that you don't have to worry about the object
state in the *subsequent* operations on that object - the object content
will (or at least should appear to) remain the same. In case of deletion
however there is no subsequent operation, thus no worry!

hth
Paavo

gerg

unread,
Dec 10, 2005, 7:56:00 AM12/10/05
to
declaring something const doesn't stop you from doing something with
its pointer value... ie strcpy ect ect. of course this is (in
general) a pretty dirty thing to do.

Sektor van Skijlen

unread,
Dec 11, 2005, 7:04:56 PM12/11/05
to
Dnia 7 Dec 2005 09:36:40 -0500, Dave Harris skrobie:

> etho...@pl.wp.spamu.lubie.nie.invalid (Sektor van Skijlen) wrote
> (abridged):
> >> In particular, the C++ Annotated Reference Manual agrees with the
> >> original poster. It has some discussion in $5.3.4, which concludes:
> >>
> >> Without the restriction against deleting pointers to const
> >> objects the delete operator would have the effect of implicitly
> >> removing the const attribute from a pointer. No operator
> >> should have that property.
> >
> > This seems to be completely wrong for me.

> The premise here is that the delete operator effectively modifies the
> object.

Incorrect. Modification is such an activity that causes an object have
prospectively changed its contents. It means, simultaneously, that after this
modification the object still exist - otherwise we could not see that some
value was modifier, while it didn't exist. So, if we are talking about
modification, we state that the object exists both before and after the
modification.

> Given that, I think the ARM reasoning is sound. (I only quoted a
> small snippet of it.)

And given that it's incorrect, this is wrong.

> > Similarly, we could ask, why 'new' operator converts implicitly from
> > void* to pointer to an object.

> It can safely do that

We do not discuss if this is safe or not, but why that is allowed to happen
regardless of the safety.

> because it has constructed the object. Indeed,
> that's its job.

So is delete operator's job to destroy the object. No matter if it is constant
or not.

> > Moreover, why there's no different versions for operator new( void* )
> > and operator new( const void* ), selected according to if the
> > user requested "new Obj()" or "new const Obj()".

> Placement new conceptually modifies the memory it's given.

No. The operator new does not do anything by itself. This can be done
indirectly by calling the constructor (however there are objects, which are
trivially constructible, so the memory still need not be written).

> So does operator delete().

Same, it does not. All possible modifications have been done already in
destructor. The 'operator delete()' function need not do any modifications
inside the object. Morover, it does not know that what it receives is an
object (indeed, it is not); it just receives a pointer to memory and frees it.

> Even if the object has no user-defined state, the
> compiler itself may need to modify it, eg to install a vtable pointer or
> other book-keeping/debugging info.

If we are talking about special features provided by the compiler, then it has
nothing to do with cv-qualification. The compiler is allowed to do anything
that does not break the rules of the standard, including write any memory
anywhere at any time.

> I don't think anyone is asking for const overloads of these in this
> thread. There's clearly a difference between the delete operator and
> operator delete.

This does not change anything. Object deletion means that everything is being
cleaned up and the object will be no longer used. The variance of the object
is then orthogonal to the matter of its removal.

> > If we want to look deeper into this topic, we could also ask, why you
> > can destroy an object, which's destructor is not const.

> Indeed, in a case like:
> static const Object obj;

> the const must be removed before the object's destructor is run.

Rather the cv-qualification does not apply for destructor.

> However,
> it doesn't follow that the delete operator is what should do this job.

Indeed, it does. In case of using 'delete' operator, it is something that is
responsible of calling the destructor. Should the destructor be called from
within 'delete' operator, the 'delete' operator should be already passed
cv-unqualified pointer. So is it passed then to the destructor and the
operator delete() as well.


Regards,

--
// _ ___ Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `| /^\ ,() <ethourhs(O)wp.pl>
// \_ |\ \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

[ See http://www.gotw.ca/resources/clcm.htm for info about ]

Dave Harris

unread,
Dec 13, 2005, 1:07:14 PM12/13/05
to
musi...@bawi.org (Seungbeom Kim) wrote (abridged):

> This is a matter of whether to consider deleting as a kind of modifying.
> I could argue against it because modifying x means (old x) != (new x)
> and in the case of delete (new x) doesn't even exist and the inequality
> doesn't hold. :)

In practice, for example when passing &x to a routine which takes a const
pointer argument, I want to rely on (old x) == (new x) being true. I can't
rely on that if the routine can delete x. In my view arguments such as
yours are irrelevant sophistry. They are not useful for real programming.


> > Indeed, in a case like:
> > static const Object obj;
> >
> > the const must be removed before the object's destructor is run.
> > However, it doesn't follow that the delete operator is what should
> > do this job.
>
> Why not?

Because we can arrange things otherwise. By "doesn't follow" I mean it is
not a necessary logical implication.


> This symmetry seems perfectly reasonable to me.

Yes. Reasonable (according to some lights), but not in itself compelling.

As I think I said elsewhere, I suspect the more compelling argument
involved templates. It still doesn't convince me, but it's a judgement
call. Reasonable men may differ. Anyway, too late to change now.

-- Dave Harris, Nottingham, UK.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]

Kurt Stege

unread,
Dec 14, 2005, 7:53:36 AM12/14/05
to
Dave Harris wrote:

> In practice, for example when passing &x to a routine which takes a const
> pointer argument, I want to rely on (old x) == (new x) being true. I can't
> rely on that if the routine can delete x. In my view arguments such as
> yours are irrelevant sophistry. They are not useful for real programming.

I see it the other way around:

When you have a pointer (or a reference), you can rely on that you may
use this pointer, until the owner of the underlying object decides to
delete that object. Of course, in a well designed system, you can rely
on that the owner does not delete the object as long you need it.

When you call a routine which takes your const pointer, and this routine
is the owner of the object, it is probably OK when this routine deletes
that object. For this behaviour, it is not relevant that you pass a
pointer to that object at all.

When you have a pointer Rectangle *x, and call a function
delete_all_rectangles_in_the_world(), you probably may not
rely on that your pointer x still is valid. As a consequence,
using your words, you cannot even check if (old x) == (new x)
is true.

Best regards,
Kurt.

Dave Harris

unread,
Dec 19, 2005, 5:21:11 AM12/19/05
to
kurt....@siemens.com (Kurt Stege) wrote (abridged):

> I see it the other way around:
>
> When you have a pointer (or a reference), you can rely on that you may
> use this pointer, until the owner of the underlying object decides to
> delete that object. Of course, in a well designed system, you can rely
> on that the owner does not delete the object as long you need it.
>
> When you call a routine which takes your const pointer, and this routine
> is the owner of the object, it is probably OK when this routine deletes
> that object. For this behaviour, it is not relevant that you pass a
> pointer to that object at all.
>
> When you have a pointer Rectangle *x, and call a function
> delete_all_rectangles_in_the_world(), you probably may not
> rely on that your pointer x still is valid. As a consequence,
> using your words, you cannot even check if (old x) == (new x)
> is true.

As far as I can tell, all of this applies also to other const member
functions. Passing a const pointer does not guarantee the object won't be
modified, if someone has a non-const alias. I don't see this as an
argument for allowing non-const functions to be callable via a const
pointer. Similarly the existence of aliases is not an argument for
allowing delete to be invoked via a const pointer.

If you are saying, ignore the type system and only believe the
documentation, then that would seem to go against the design of C++. Yes,
there may be a documented rule that only the owner can delete the object.
I want to use const to help enforce and verify that rule.

-- Dave Harris, Nottingham, UK.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]

Kurt Stege

unread,
Jan 16, 2006, 11:31:16 AM1/16/06
to
(I have been on holidays, therefore sorry for the long time to answer.)

Dave Harris wrote:
> kurt....@siemens.com (Kurt Stege) wrote (abridged):
>
>>I see it the other way around:
>>
>>When you have a pointer (or a reference), you can rely on that you may
>>use this pointer, until the owner of the underlying object decides to
>>delete that object. Of course, in a well designed system, you can rely
>>on that the owner does not delete the object as long you need it.
>>
>>When you call a routine which takes your const pointer, and this routine
>>is the owner of the object, it is probably OK when this routine deletes
>>that object. For this behaviour, it is not relevant that you pass a
>>pointer to that object at all.
>>
>>When you have a pointer Rectangle *x, and call a function
>>delete_all_rectangles_in_the_world(), you probably may not
>>rely on that your pointer x still is valid. As a consequence,
>>using your words, you cannot even check if (old x) == (new x)
>>is true.
>
>
> As far as I can tell, all of this applies also to other const member
> functions. Passing a const pointer does not guarantee the object won't be
> modified, if someone has a non-const alias.

Yes, you are right.

> I don't see this as an
> argument for allowing non-const functions to be callable via a const
> pointer.

Correct.

> Similarly the existence of aliases is not an argument for
> allowing delete to be invoked via a const pointer.

No. It is meant to stop your argument. You said:
: I want to rely on (old x) == (new x) being true. I can't


: rely on that if the routine can delete x.

And for that reason you wanted to forbid deleting an object
via a const pointer.

My argument is, you can't rely on it anyway.

On the other side, the following are completely different
actions that should be (and are) treated separately when
handling access rights:
- creating an object,
- reading an object,
- writing/modifying an object,
- deleting an object.

A const pointer does not allow to modify that object (via
the pointer). It does _not_ forbid deleting reading it, or
deleting it, so both still is allowed.

This thread mentioned one or two arguments that this behaviour
is a good behaviour, and I didn't see a valid argument to see
this as bad definition.


> If you are saying, ignore the type system and only believe the
> documentation, then that would seem to go against the design of C++.

No, of course not...

> Yes,
> there may be a documented rule that only the owner can delete the object.
> I want to use const to help enforce and verify that rule.

But const is about modifying objects, and not about ownership.
Why (and how) do you want to use const to state the ownership
of the object?

You might change the language C++ in a way that const is about
access rights to modify or delete the object. But even this
change would have nothing to do with ownership.

Perhaps, an std::auto pointer would help. But in my opinion,
a class where the assignment operator modifies the right side,
cannot be taken seriously.

Best regards,
Kurt.

Dave Harris

unread,
Jan 17, 2006, 6:30:40 AM1/17/06
to
kurt....@siemens.com (Kurt Stege) wrote (abridged):
> > Similarly the existence of aliases is not an argument for
> > allowing delete to be invoked via a const pointer.
>
> No. It is meant to stop your argument. You said:
> : I want to rely on (old x) == (new x) being true. I can't
> : rely on that if the routine can delete x.
> And for that reason you wanted to forbid deleting an object
> via a const pointer.
>
> My argument is, you can't rely on it anyway.

I can in the absence of aliases. Which often can be discounted when
reasoning about code.


> A const pointer does not allow to modify that object (via
> the pointer).

What does that mean? Why is it important? How is it useful to know that a
routine has not modified the object, if it might have deleted it?


> > Yes, there may be a documented rule that only the owner can delete
> > the object. I want to use const to help enforce and verify that rule.
>
> But const is about modifying objects, and not about ownership.
> Why (and how) do you want to use const to state the ownership
> of the object?

As the language stands, const doesn't help. In ARM C++, it could help.

-- Dave Harris, Nottingham, UK.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]

Reply all
Reply to author
Forward
0 new messages