Delete a const pointer?

969 views
Skip to first unread message

Wilka

unread,
Nov 11, 2000, 3:00:00 AM11/11/00
to
Is this legal C++?

int main()
{
const int* p = new int(10);
delete p;

return 0;
}

MSVC 6.3 says "error C2665: 'delete' : none of the 2 overloads can convert
parameter 1 from type 'const int *'"

I assumed it was another MSVC bug, but according to
http://support.microsoft.com/support/kb/articles/Q131/3/22.asp this is
correct behaviour.


--
- Wilka
(address rot13 encoded)


[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]


Christoph Groth

unread,
Nov 12, 2000, 3:00:00 AM11/12/00
to
"Wilka" <jv...@evghnyvfgvp.pbz> writes:

> Is this legal C++?
>
> int main()
> {
> const int* p = new int(10);
> delete p;
>
> return 0;
> }

Why should deleting a `const int' object on the heap be illegal? g++
has no problems compiling this. Probably yet another one of MSVC's
incompatibilities...

Christoph

Ron Hunsinger

unread,
Nov 13, 2000, 3:00:00 AM11/13/00
to
In article <EKbP5.6356$zJ6.7...@news3.cableinet.net>, "Wilka"
<jv...@evghnyvfgvp.pbz> wrote:

> Is this legal C++?
>
> int main()
> {
> const int* p = new int(10);
> delete p;
>
> return 0;
> }
>

> MSVC 6.3 says "error C2665: 'delete' : none of the 2 overloads can convert
> parameter 1 from type 'const int *'"
>
> I assumed it was another MSVC bug, but according to
> http://support.microsoft.com/support/kb/articles/Q131/3/22.asp this is
> correct behaviour.

Just another case of Microsoft getting it wrong. They say (at the
aforementioned URL) that a pointer to const cannot be deleted, because that
changes the thing pointed to. But what the ISO C++ Standard says is:

[expr.delete] 5.3.5/2:

[Note: a pointer to a const type can be the operand of a
delete-expression; it is not necessary to cast away the
constness (5.2.11) of the pointer expression before it
is used as the operand of the delete-expression. ]

-Ron Hunsinger

Ron Natalie

unread,
Nov 13, 2000, 3:00:00 AM11/13/00
to

Wilka wrote:
>
> Is this legal C++?
>
> int main()
> {
> const int* p = new int(10);
> delete p;
>
> return 0;
> }
>
> MSVC 6.3 says "error C2665: 'delete' : none of the 2 overloads can convert
> parameter 1 from type 'const int *'"


VC++ is wrong. const doesn't apply to delete;

Michael Grove

unread,
Nov 13, 2000, 3:00:00 AM11/13/00
to
it's not legal - p is a pointer to a const int. if you want to be able to
delete p, don't make p a constant pointer. the compiler won't let you
delete
p, because that modifies the data p points to, and this is not allowed
since
you've told the compiler that no one should be able to modify what p points
to.

-mike

Wilka wrote:

> Is this legal C++?
>
> int main()
> {
> const int* p = new int(10);
> delete p;
>
> return 0;
> }
>
> MSVC 6.3 says "error C2665: 'delete' : none of the 2 overloads can
convert
> parameter 1 from type 'const int *'"
>

> I assumed it was another MSVC bug, but according to
> http://support.microsoft.com/support/kb/articles/Q131/3/22.asp this is
> correct behaviour.

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Erik Max Francis

unread,
Nov 13, 2000, 3:00:00 AM11/13/00
to
Wilka wrote:

> Is this legal C++?
>
> int main()
> {
> const int* p = new int(10);
> delete p;
>
> return 0;
> }

It sure is.

> MSVC 6.3 says "error C2665: 'delete' : none of the 2 overloads can
> convert
> parameter 1 from type 'const int *'"
>
> I assumed it was another MSVC bug, but according to
> http://support.microsoft.com/support/kb/articles/Q131/3/22.asp this is
> correct behaviour.

They are incorrect. The C++ Standard, section 5.3.5/2 reads:

[Note: a pointer to a const type can be the operand of a
delete-expression; it is not necessary to cast away the constness
(5.2.11) of the pointer expression before it is used as the operand
of the delete-expression.]

--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ God grant me to contend with those that understand me.
\__/ Thomas Fuller
7 sisters productions / http://www.7sisters.com/
Web design for the future.

Ron Natalie

unread,
Nov 13, 2000, 3:00:00 AM11/13/00
to

Michael Grove wrote:
>
> it's not legal - p is a pointer to a const int. if you want to be able to
> delete p, don't make p a constant pointer. the compiler won't let you
> delete
> p, because that modifies the data p points to, and this is not allowed
> since
> you've told the compiler that no one should be able to modify what p points
> to.

The standard does not agree with this. const does not have any affect on
delete.

Carlos Moreno

unread,
Nov 13, 2000, 3:00:00 AM11/13/00
to
Michael Grove wrote:
>
> it's not legal - p is a pointer to a const int. if you want to be able to
> delete p, don't make p a constant pointer. the compiler won't let you
> delete
> p, because that modifies the data p points to, and this is not allowed
> since
> you've told the compiler that no one should be able to modify what p points
> to.

I would like to agree with you -- it does sound strange that delete
is allowed for a pointer to constant -- what action could be more
modifying to an object than deleting it?! And the pointer is actually
stating "you can't use me to modify the object I'm pointing to"

However, if you are forced to drop the constness of every object that
is dynamically allocated, your const correctness would go away. Of
course, it is absolutely scary that you can, for instance, do this:

string s = "....";

delete s.c_str();

And so easily and happily make the program crash! (well, it's not
guaranteed that it will crash, but it is what most likely would happen).

This is one of those vicious circle situations that make you feel so
frustrated...:-(

Carlos
--

Francis Glassborow

unread,
Nov 13, 2000, 3:00:00 AM11/13/00
to
In article <3A0F44E7...@home.com>, Michael Grove
<snow...@home.com> writes

>it's not legal - p is a pointer to a const int. if you want to be able to
>delete p, don't make p a constant pointer. the compiler won't let you
>delete
>p, because that modifies the data p points to, and this is not allowed
>since
>you've told the compiler that no one should be able to modify what p
points
>to.

In a newsgroup with heavy participation by language experts it would
probably be wiser not to post on issues such as this one unless you can
quote chapter and verse to support your belief.

You may find it difficult to accept but deletion is not considered
modification. To give you another example, having write access to a
directory in unix allows you to delete a read only file.

Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

Erik Max Francis

unread,
Nov 13, 2000, 3:00:00 AM11/13/00
to
Carlos Moreno wrote:

> However, if you are forced to drop the constness of every object that
> is dynamically allocated, your const correctness would go away. Of
> course, it is absolutely scary that you can, for instance, do this:
>
> string s = "....";
>
> delete s.c_str();
>
> And so easily and happily make the program crash! (well, it's not
> guaranteed that it will crash, but it is what most likely would
> happen).

I don't really see why this bothers you. You seem to be objecting to
the fact that it's not syntactically incorrect to delete any const
pointer, even ones which you shouldn't. Well, that's true, but that
doesn't make it _correct_; the above fragment, for instance, invokes
undefined behavior because it deletes a pointer that was not returned
from a new.

One can come up with equally contrived situations where you can delete
const-pointers. See:

const int *p = reinterpret_cast<int *>(0xdeadbeef);

delete p;

This is surely syntactically correct, but that doesn't mean it's not
doing something really, really dumb.

As a competent C++ programmer, you have to know what you can delete and
what you can't. Just because a pointer is const doesn't make it fair
game for being deleted (why would it?).

--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE

/ \ Man is a clever animal who behaves like an imbecile.
\__/ Albert Schweitzer
Alcyone Systems' Daily Planet / http://www.alcyone.com/planet.html
A new, virtual planet, every day.

James Kanze

unread,
Nov 14, 2000, 3:00:00 AM11/14/00
to
Francis Glassborow wrote:

> You may find it difficult to accept but deletion is not considered
> modification. To give you another example, having write access to a
> directory in unix allows you to delete a read only file.

I'm not sure the parallel is valid. In the Unix I've worked on, you
can't delete a file. Period. Files are managed by reference counted
pointers, and are deleted automatically by the system when the
reference count drops to zero. All the user can do is delete a
reference, either by deleting a directory entry or closing the file.

--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Andrew Koenig

unread,
Nov 14, 2000, 3:00:00 AM11/14/00
to
Francis> In article <3A0F44E7...@home.com>, Michael Grove
Francis> <snow...@home.com> writes

Francis> You may find it difficult to accept but deletion is not
Francis> considered modification. To give you another example, having
Francis> write access to a directory in unix allows you to delete a
Francis> read only file.

... and if you couldn't destroy a const object, how could you ever
have a const local variable?

--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark

Carlos Moreno

unread,
Nov 14, 2000, 3:00:00 AM11/14/00
to
James Kanze wrote:
>
> Francis Glassborow wrote:
>
> > You may find it difficult to accept but deletion is not considered
> > modification. To give you another example, having write access to a
> > directory in unix allows you to delete a read only file.
>
> I'm not sure the parallel is valid.

I agree with this, but for different reasons :-)

The way I see it, you can delete a read-only file (what you're
describing is "implementation details" -- from the practical point
of view, the user deletes the file), but that *does* represent a
violation to the read-only attribute! It's just that the shell
prompts you to confirm the deletion, since it is a read-only
file -- I see this as an analogy with the use of const_cast,
rather than an argument that deleting an object is not modifying
the object.

Carlos
--

Carlos Moreno

unread,
Nov 14, 2000, 3:00:00 AM11/14/00
to
Erik Max Francis wrote:
>
> > string s = "...";
> > delete s.c_str();

>
> I don't really see why this bothers you. You seem to be objecting to
> the fact that it's not syntactically incorrect to delete any const
> pointer, even ones which you shouldn't. Well, that's true, but that
> doesn't make it _correct_; the above fragment, for instance, invokes
> undefined behavior because it deletes a pointer that was not returned
> from a new.

??? How do you know? I'm pretty sure that the standard does not
specify how c_str returns the string. I'm pretty sure that a valid
implementation *is allowed* to return a pointer to its internal copy
of the string (which *may be* allocated with new), or it could create
a duplicate, also allocated with new.

So, maybe in a particular implementation, it may not be allocated
with new, although I don't see how -- other than with malloc (is
that what you were referring to?).

My point was that const is there to protect us (us programmers,
regardless the fact that we are beginners, experienced, or gurus)
from dumb mistakes -- yes, in my example, it is particularly
dumb, because I made it explicit as an example; but we could
accidentally do something like that without noticing, maybe in
a situation where it's not that obvious that the pointer comes
from a call to c_str, or maybe because the name of the variables
are similar and we confused them, etc.

The bottom line is that if we use the argument that "a competent
programmer would not do that", then we might as well end up
dropping the const keyword from the language, arguing that
"a competent programmer would never modify this", or "would
never do that", because it is really dumb to do it.

> As a competent C++ programmer, you have to know what you can delete and
> what you can't.

Yes. But see my argument above. You could extend this to "as a
competent C++ programmer, you have to know what you can modify and
what you can't, and when you can call member functions that modify
and when you can't". So, the const keyword would become useless.

The bottom line of my argument is that, if you accept that deleting
an object is a modifying action (which in my opinion is), then it
does sound scary that you can delete a pointer that points to
something constant (you are indeed using the pointer to perform
an action that modifies the pointee -- however, if you couldn't, then
you would be forced to drop the constness whenever you use dynamic
allocation; that's why I described the situation as sort of a vicious
circle...

Carlos Moreno

unread,
Nov 14, 2000, 3:00:00 AM11/14/00
to
Andrew Koenig wrote:
>
> ... and if you couldn't destroy a const object, how could you ever
> have a const local variable?

This analogy is pretty nice, but I find it a little bit unfair.

A local variable is managed by the compiler, which in most cases
knows what it's doing. Its lifetime expires in a way that is
controlled by the compiler, not by the programmer.

Destroying an object through a pointer is different... The pointer
has a huge sticker saying "don't use me to modify what I'm pointing
to"... So, it is a matter of agreeing on destruction as being a
modifying action or not. I know it's arguable -- even subject to
a philosophical discussion :-) you could say that when you
destroy it, it doesn't exist anymore, thus, it wasn't modified;
it simply ceased to exist, but during its lifetime it wasn't
modified.

On the other hand, the idea of the const is to protect the
program against accidental actions from the programmer (expert
or incompetent). And deleting in a section of code where the
pointer imposes logical constness to the pointee does sound
contradictory to me.

Of course, I still tend to agree with the solution as it is
in the standard (it would be so horrible that you couldn't
set const an object only because it is dynamically allocated,
or that you had to always use const_cast... Maybe this wouldn't
be too much a hassle in exchange for an increased protection
against mistakes...??)

Erik Max Francis

unread,
Nov 15, 2000, 3:00:00 AM11/15/00
to
Carlos Moreno wrote:

> Andrew Koenig wrote:
>
> > ... and if you couldn't destroy a const object, how could you ever
> > have a const local variable?
>
> This analogy is pretty nice, but I find it a little bit unfair.

It's not unfair at all. If deleting a const object is illegal, then no
const objects can be destructed; an object declared const would never
get its destructor called. That's a sad state of affairs if it's tied
to some external resources that it needs to clean up.

--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE

/ \ My heart is pure as the driven slush.
\__/ Tallulah Bankhead


Alcyone Systems' Daily Planet / http://www.alcyone.com/planet.html
A new, virtual planet, every day.

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Wil Evers

unread,
Nov 15, 2000, 3:00:00 AM11/15/00
to
In article <3A116872...@cyberx.com>, Carlos Moreno wrote:

> The bottom line of my argument is that, if you accept that deleting
> an object is a modifying action (which in my opinion is), then it
> does sound scary that you can delete a pointer that points to

> something constant.

This subject was beaten to death on comp.std.c++ last year. If you
like a heated debate, do a quick search for "What const/is was for" on
Dejanews.

- Wil

--
Wil Evers, DOOSYS IT Consultants, Maarssen, Holland
[Wil underscore Evers at doosys dot com]

Dave Nash

unread,
Nov 15, 2000, 3:00:00 AM11/15/00
to
Michael Grove wrote:

> it's not legal - p is a pointer to a const int.

OK, p is a pointer to a constant int

> delete p, don't make p a constant pointer. the compiler won't let you

Wrong, he hasn't made p a constant pointer. A constant pointer is
different from a pointer to a constant.

Dave

> Wilka wrote:

> > const int* p = new int(10);

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

een...@electeng.leeds.ac.uk

unread,
Nov 15, 2000, 3:00:00 AM11/15/00
to
James Kanze <James...@dresdner-bank.de> wrote:
> Francis Glassborow wrote:

>> You may find it difficult to accept but deletion is not considered
>> modification. To give you another example, having write access to a
>> directory in unix allows you to delete a read only file.

> I'm not sure the parallel is valid. In the Unix I've worked on, you


> can't delete a file. Period. Files are managed by reference counted
> pointers, and are deleted automatically by the system when the
> reference count drops to zero. All the user can do is delete a
> reference, either by deleting a directory entry or closing the file.

Surely Francis was talking about file references? Files as you
termed them (ie. the data chunks) don't have access permissions,
do they?

--
Neil

Erik Max Francis

unread,
Nov 15, 2000, 3:00:00 AM11/15/00
to
Carlos Moreno wrote:

> ??? How do you know? I'm pretty sure that the standard does not
> specify how c_str returns the string.

It sure doesn't say you're allowed to delete it.

> I'm pretty sure that a valid
> implementation *is allowed* to return a pointer to its internal copy
> of the string (which *may be* allocated with new), or it could create
> a duplicate, also allocated with new.

It's _allowed_ that std::string::c_str returns a valid pointer created
by new, but what does that have to do with whether or not it's
reasonable for you to delete it manually? In fact, even if what you are
saying is true, undefined behavior would be invoked when the
std::string's destructor double deleted that block.

> So, maybe in a particular implementation, it may not be allocated
> with new, although I don't see how -- other than with malloc (is
> that what you were referring to?).

The Standard says nothing about the allocation or deallocation of the
pointer returned by std::string::c_str, so you've got no business
presuming what it does or does not do.

> My point was that const is there to protect us (us programmers,
> regardless the fact that we are beginners, experienced, or gurus)

> from dumb mistakes ...

It's there to enforce an implicit contract between the interface
designer and the programmer. Object deleting has no part of that
contract.

> Yes. But see my argument above. You could extend this to "as a
> competent C++ programmer, you have to know what you can modify and
> what you can't, and when you can call member functions that modify
> and when you can't". So, the const keyword would become useless.
>

> The bottom line of my argument is that, if you accept that deleting

> an object is a modifying action (which in my opinion is), ...

It cannot be. If so, no object declared as const could ever be
destructed by this argument, including both local and global variables.
Clearly that isn't what const is trying to get at.

--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE

/ \ The believer is happy; the doubter is wise.
\__/ (an Hungarian proverb)


7 sisters productions / http://www.7sisters.com/
Web design for the future.

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

James Kanze

unread,
Nov 15, 2000, 3:00:00 AM11/15/00
to
Carlos Moreno wrote:

> James Kanze wrote:

> > Francis Glassborow wrote:

> > > You may find it difficult to accept but deletion is not
> > > considered modification. To give you another example, having
> > > write access to a directory in unix allows you to delete a read
> > > only file.

> > I'm not sure the parallel is valid.

> I agree with this, but for different reasons :-)

> The way I see it, you can delete a read-only file (what you're
> describing is "implementation details" -- from the practical point
> of view, the user deletes the file), but that *does* represent a
> violation to the read-only attribute! It's just that the shell
> prompts you to confirm the deletion, since it is a read-only file --
> I see this as an analogy with the use of const_cast, rather than an

> argument that deleting an object is not modifying the object.

Well, it wouldn't be the shell which warned you, but rm. And the
warning wasn't (isn't?) always present; when I learned Unix, it
certainly wasn't there.

But the point stands, I think. I agree that what I described are the
"implementation details", although they are fairly well known, since
they are also behind the trick of deleting a temporary file immediatly
after creating it, so that it will disappear even if the process
crashes. The point is that deleting files in Unix works differently
than deleting objects in C++, so it is normal that different rules
apply.

One can imagine logical arguments for both sides. In as far as delete
invokes the destructor, and the destructor is not a const function, I
tend to favor forbidding the delete, but I can understand the other
side's logic. In the end, from my point of view, you can choose one
or the other, so you might as well choose the one which reduces the
probability of programmer error: forbid the deletion.

--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

Carlos Moreno

unread,
Nov 15, 2000, 3:00:00 AM11/15/00
to

Erik,

I think you totally misunderstood what I was trying to say with my
initial comment... I'll try to clarify (although the discussion
may shift into pointless grounds, since -- believe it or not -- we
are agreeing on most things! :-))

Erik Max Francis wrote:
>
> Carlos Moreno wrote:
>
> > ??? How do you know? I'm pretty sure that the standard does not
> > specify how c_str returns the string.
>
> It sure doesn't say you're allowed to delete it.

Of course!!! And my point was that even though the return value
of string::c_str() is a pointer to const, it *can* be deleted
explicitly, invoking undefined behaviour... My point was that
the fact that you can delete a pointer to const does sound
dangerous -- according to the OP's argument, the const in that
return value should prevent you from being able to delete it;
and this was my example to say that what the standard specifies,
though reasonable, does sound scary.

> It's _allowed_ that std::string::c_str returns a valid pointer created
> by new, but what does that have to do with whether or not it's
> reasonable for you to delete it manually?

My point exactly!!! The standard, in this particular example,
is not enforcing the fact that you're *not allowed* to do what
you're not supposed to do (as the const very often enforces)

> In fact, even if what you are
> saying is true, undefined behavior would be invoked when the
> std::string's destructor double deleted that block.

Of course that was exactly my point!! You're not supposed to
delete that manually because in either of the only two possibilities
(either it was allocated with new, in which case it will be deleted
by its owner -- the string object --, or it wasn't allocated by
new, in which case delete will just invoke undefined behaviour).

Notice that it's not that I don't understand what happens or I'm
trying to predict what will happen -- I was using this as an example
of something that you're not supposed to do (and yes, any minimally
competent programmer will know they're not supposed to do it), and
yet the presence of the const in that pointer does not prevent
you from doing it (when *arguably* it should, or it might, given
that destroying an object is *arguably* a modifying action, and
thus should be prohibited by the presence of the const).

The c_str is an example maybe too obvious (I mean, it is too
obvious that you're not supposed to delete it manually), but there
may be tons of similar situations where it would not be that
obvious that you're not supposed to delete a pointer; it would
just be so nice if you had a way to explicitly prohibit such
action.

> The Standard says nothing about the allocation or deallocation of the
> pointer returned by std::string::c_str, so you've got no business
> presuming what it does or does not do.

I wasn't!! You were the one that stated very definitively that
my fragment's undefined behaviour was due to the fact that I wasn't
deleting a pointer allocated with new... (hmmm, although I think
I see what you probably meant... Since *I* didn't explicitly new'ed
that pointer, then I should think of it as if it wasn't allocated
with new, therefore it's not my business to delete it?? Ok, if
you meant that, then 1) I agree, and 2) I misunderstood what you
were saying :-))

> It cannot be. If so, no object declared as const could ever be
> destructed by this argument, including both local and global variables.
> Clearly that isn't what const is trying to get at.

And I said exactly that in my initial message!! I was describing
the situation as a "vicious circle" precisely because of this!!
My point was (and still is) that it would be really nice if we
had a way of returning a pointer to client code and enforcing
the fact that we don't allow them to delete it -- a pointer to
const *may seem* like the way of doing so, if we accept the fact
that destroying an object is considered modifying it (after all,
before deletion, the object was X, and after deletion, the
object is nothing -- nothing is different from X, thus, the
action did modified the object).

But then your above argument (which I mentioned as well) applies:
you wouldn't be able to delete your own constant objects; thus,
you would have to drop the const for every object that is dynamically
allocated...

I hope I clarified what I meant originally (yes, I know that we
still may disagree on the fact that deleting an object is a modifying
action or not -- at least, I think you must agree that the argument
is reasonable, and that both points of view are bound to be defended)

Carlos
--

Carlos Moreno

unread,
Nov 15, 2000, 3:00:00 AM11/15/00
to
Erik Max Francis wrote:
>
> Carlos Moreno wrote:
>
> > Andrew Koenig wrote:
> >
> > > ... and if you couldn't destroy a const object, how could you ever
> > > have a const local variable?
> >
> > This analogy is pretty nice, but I find it a little bit unfair.
>
> It's not unfair at all. If deleting a const object is illegal, then no
> const objects can be destructed

WAIT!! It's not the same... The original point was not "deleting a
const object is illegal"... The original point was "using a pointer
to non-modifiable object to delete it (arguably *modify* it) is illegal"

The original point is wrong, of course -- the standard explicitly says
so; but I insist that the analogy is unfair: one is automatic
destruction
of a const object, managed by the compiler when the lifetime of the
object expires, and the other is managed (possibly irresponsibly) by
the user, via a pointer that is saying not to mdify the object.

Francis Glassborow

unread,
Nov 15, 2000, 3:00:00 AM11/15/00
to
In article <3A116872...@cyberx.com>, Carlos Moreno
<mor...@cyberx.com> writes

>The bottom line is that if we use the argument that "a competent
>programmer would not do that", then we might as well end up
>dropping the const keyword from the language, arguing that
>"a competent programmer would never modify this", or "would
>never do that", because it is really dumb to do it.

That is a C, not C++ argument. In C++ we need to provide different
behaviour for const qualified objects and our ability to overload on
const provides the mechanism we need.

In C++, const is not designed to protect us from stupidity (nothing can
do that, though some languages try to) but to allow us to distinguish
the requirements of read-only items from modifiable ones.
>

Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Carlos Moreno

unread,
Nov 15, 2000, 3:00:00 AM11/15/00
to
James Kanze wrote:
>
> In as far as delete
> invokes the destructor, and the destructor is not a const function, I
> tend to favor forbidding the delete, but I can understand the other
> side's logic. In the end, from my point of view, you can choose one
> or the other, so you might as well choose the one which reduces the
> probability of programmer error: forbid the deletion.

Phew!!! I thought I was completely alone on this!! But I'm glad to
see that at least one experienced programmer shares (100%, I would
say) my point of view... (sure, forbidding the deletion would either
force you to use const_cast always when you (the owner of the allocated
object) delete, or to drop constness for dynamically allocated
objects...
Either way, it would be too bad -- as is too bad that (accidental)
deletion is allowed

Carlos
--

Erik Max Francis

unread,
Nov 15, 2000, 3:00:00 AM11/15/00
to
Dave Nash wrote:

> Wrong, he hasn't made p a constant pointer. A constant pointer is
> different from a pointer to a constant.

The Standard also allows you to delete a constant pointer to T, in
addition to a pointer to constant T. After all, a constant pointer only
means that you can't change its value; deleting the object that it
points to doesn't involve changing that pointer.

--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE

/ \ When you love somebody, you're always in trouble.
\__/ Col. Sherman Potter
Erik Max Francis' bookmarks / http://www.alcyone.com/max/links/
A highly categorized list of Web links.

Manlio Perillo

unread,
Nov 15, 2000, 3:00:00 AM11/15/00
to

"Ron Hunsinger" <hns...@sirius.com> ha scritto nel messaggio
news:hnsngr-ya0231800...@news.flash.net...
> [...]

> But what the ISO C++ Standard says is:
>
> [expr.delete] 5.3.5/2:
>
> [Note: a pointer to a const type can be the operand of a
> delete-expression; it is not necessary to cast away the
> constness (5.2.11) of the pointer expression before it
> is used as the operand of the delete-expression. ]
>


Only a question:

why a destructor cannot be declared const but we
can delete a const pointer?

Regards
Manlio Perillo

Carlos Moreno

unread,
Nov 15, 2000, 3:00:00 AM11/15/00
to
Francis Glassborow wrote:
>
> In C++, const is not designed to protect us from stupidity

Making mistakes is not stupidity -- it's part of our human nature.
Yes, expert programmers make far less mistakes than beginners, but
they still do!

Const does not protect us from *every* mistake that we do; but
there are many situations in which not using the const (or simply
having placed a comment saying that the item should be read-only)
would have left a mistake go unnoticed. And we all know that
mistakes can go unnoticed for very long, even through reasonably
strict Q.A. protocols.

C++, and more in general, the Object Oriented programming approach,
does make a very good job at protecting us from many of our own
mistakes; I wouldn't claim that OOP or C++ protects us from
stupidity, but they do a much better job than, say, C.

Carlos
--

Erik Max Francis

unread,
Nov 15, 2000, 3:00:00 AM11/15/00
to
Carlos Moreno wrote:

> Of course!!! And my point was that even though the return value
> of string::c_str() is a pointer to const, it *can* be deleted
> explicitly, invoking undefined behaviour...

So what? You're not supposed to delete it, not because it's const, but
because you didn't allocate it with new and it's not yours to delete.

The language can't help you from doing stupid things. Trying to delete
a pointer that you have been handed, const or not, is stupid, unless you
know you created the pointer yourself with new or the Standard
explicitly says that it is all right for you to do so.

> My point was that
> the fact that you can delete a pointer to const does sound
> dangerous -- according to the OP's argument, the const in that
> return value should prevent you from being able to delete it;
> and this was my example to say that what the standard specifies,
> though reasonable, does sound scary.

The same exact argument could be applied to non-const pointers. There
are numerous cases where you could be given a _non-const_ pointer that
you're just as certainly not supposed to delete, so the const-ness of
the pointers we're talking about are immaterial. What you've got there
is a red herring.

> My point exactly!!! The standard, in this particular example,
> is not enforcing the fact that you're *not allowed* to do what
> you're not supposed to do (as the const very often enforces)

The fact that you're not supposed to delete the pointer has absolutely
nothing to do with whether or not the pointer is const; you're not
supposed to delete it because it's not yours and you didn't create it
when new.

As such, it is a very poor illustration of the hazards of being able to
delete const pointers, which is what I pointed out.

> Of course that was exactly my point!! You're not supposed to
> delete that manually because in either of the only two possibilities
> (either it was allocated with new, in which case it will be deleted
> by its owner -- the string object --, or it wasn't allocated by
> new, in which case delete will just invoke undefined behaviour).

And that has no bearing on the fact that the pointer is const.

> The c_str is an example maybe too obvious (I mean, it is too
> obvious that you're not supposed to delete it manually), but there
> may be tons of similar situations where it would not be that
> obvious that you're not supposed to delete a pointer; it would
> just be so nice if you had a way to explicitly prohibit such
> action.

Try a better example, then; the std::string::c_str isn't relevant
because you're not supposed to delete it _regardless_ of its constness.
If it had returned a non-const pointer, it would have invoked undefined
behavior to delete it also.

(Note in the above I use "const pointer" and "non-const pointer" to
reference to pointers to const object and pointers to non-const objects,
respectively; from the context of this thread it should have been clear,
but given this isolated post it might not be.)

--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE

/ \ Hell is other people.
\__/ Jean-Paul Sartre
REALpolitik / http://www.realpolitik.com/
Get your own customized newsfeed online in realtime ... for free!

Erik Max Francis

unread,
Nov 15, 2000, 3:00:00 AM11/15/00
to
James Kanze wrote:

> Well, it wouldn't be the shell which warned you, but rm. And the
> warning wasn't (isn't?) always present; when I learned Unix, it
> certainly wasn't there.

It's given by a command line option, -i. Many default shell profiles
alias rm to 'rm -i' to do this for novice users. (Whether it's useful
or not is a totally separate question, and this diversion is already
off-topic for comp.lang.c++.moderated, so I'll stop here.)

> In as far as delete
> invokes the destructor, and the destructor is not a const function, I
> tend to favor forbidding the delete, but I can understand the other
> side's logic.

It is true that destructors are not const functions, but destructors
_cannot_ be declared const, so that is not very relevant. And, in fact,
there's an even bigger indication that this (const destructors) is a red
herring: There are no const _constructors_, either. So does that mean
that no const object should ever be created? Obviously not, so the fact
that destructors can't be const is not relevant, since constructors
can't be either.

Constructors and destructors are _very_ special member functions, and so
const vs. non-const arguments simply don't apply to them.

--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE

/ \ Love is like war: easy to begin but very hard to stop.
\__/ H.L. Mencken


Alcyone Systems' Daily Planet / http://www.alcyone.com/planet.html
A new, virtual planet, every day.

[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]

Ron Hunsinger

unread,
Nov 16, 2000, 3:00:00 AM11/16/00
to
In article <8uup7r$rgj$1...@nslave3.tin.it>, "Manlio Perillo"
<manl...@tin.it> wrote:

> Only a question:
>
> why a destructor cannot be declared const but we
> can delete a const pointer?

Among other things, for symmetry with the constructor. Constructors and
destructors both convert between raw storage and non-const objects.

When you construct a const object, it doesn't become const until the
constructor completes. [Reference: 12.1/4] This makes sense, because the
constructor must be able to modify the object, if for no other reason than
to form it out of raw storage.

[class.ctor] 12.1/4:

A constructor shall not be virtual (10.3) or static (9.4). A
constructor can be invoked for a const, volatile or const volatile
object. A constructor shall not be declared const, volatile, or
const volatile (9.3.2). const and volatile semantics (7.1.5.1) are
not applied on an object under construction. Such semantics only
come into effect once the constructor for the most derived object
(1.8) ends.

By symmetry, a const object reverts to non-const on entry to the
destructor. [Reference 12.4/2] This also makes sense, because a destructor
must also be able to modify the object, if for no other reason than to turn
it back into raw storage.

[class.dtor] 12.4/2:

A destructor is used to destroy objects of its class type. A
destructor takes no parameters, and no return type can be specified
for it (not even void). The address of a destructor shall not be
taken. A destructor shall not be static. A destructor can be invoked
for a const, volatile or const volatile object. A destructor shall
not be declared const, volatile or const volatile (9.3.2). const and
volatile semantics (7.1.5.1) are not applied on an object under
destruction. Such semantics stop being into effect once the destructor
for the most derived object (1.8) starts.

Constructors and destructors also cannot be volatile. The standard is
somewhat vague about what volatile means, but it does say it means the
object may be modified by agents that the compiler does not know about. But
while the object is being constructed or destructed, it is in an
inconsistent state, and such external modifications would probably be
meaningless anyway. The compiler is not required to preserve the
meaningfulness of meaningless modifications.

-Ron Hunsinger

Erik Max Francis

unread,
Nov 16, 2000, 3:00:00 AM11/16/00
to
Manlio Perillo wrote:

> why a destructor cannot be declared const but we
> can delete a const pointer?

I'll answer your question with another question:

Why can a _constructor_ not be declared const but you can create a const
object?

That is to say, constructors and destructors are special member
functions for which const doesn't have a meaning (which doesn't mean
that they are explicitly non-const).

--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE

/ \ The map is not the territory.
\__/ Alfred Korzybski
Esperanto reference / http://mirror/alcyone/max/lang/esperanto/
An Esperanto reference for English speakers.

rado42

unread,
Nov 16, 2000, 3:00:00 AM11/16/00
to
In article <3A1321B3...@alcyone.com>,

So how about a little language extension: making destructors (and
probably constructors, but not nesseccarily) optionally 'const'? It
looks like con