Delete a const pointer?

910 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 constructors & desstructors not being const is somewhat
inconsistent with the rest of the language, which causes confusion
sometimes (even for compiler vendors), as this thread shows.

Lacking of 'const' destructor would prevent deleting (and destructing
in other way) a 'const' object. It also gives the possiblity to have 2
destructors: one for 'const', and another for 'normal' objects.

I know it is kinda too late for it and it would break a lot of existing
code, but anyway, I find the idea interesting.

A workaround to keep the existing code compiling would be to threat
dtors to be const by default, and being able to declare them
optionally 'mutable'. An object with only a mutable destructor has to
be mutable (i.e. non-const) in order to be destructed.

And, BTW, I use MSVC60, use const a lot, and have never come to a
situation where I had to delete a 'const' pointer (which MSC60 does not
allow, as someone mentioned). I personally don't like the possibility
to be able to delete a const pointer, although the standard allows it.
Having to do it looks like a design flow to me. So, in this case, I
appreciate the MSVC60 bug - it would expose my design flow.

Last word to the compiler vendors: at least some diagnostics (warning)
when a const pointer is deleted is easily achievable.

Any opitions?

Radoslav Getov


Sent via Deja.com http://www.deja.com/
Before you buy.

Carlos Moreno

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

Erik,

Though I agree with most of your arguments, practically all of
them are totally unrelated from what I have been trying to say
(that is, you're still misunderstanding my point)

Erik Max Francis wrote:
>
> 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.

Ok, let's put it this way. Can you assign something (say, with
strcpy) to the characters pointed to by the pointer returned by
string::c_str? Well, you could argue that since the pointer is
not yours, and the standard does not tell you that you're supposed
to modify it, then it would be plain stupidity to do it.

Whether or not stupidity is too strong to describe this, the point
is that you could argue that you can't do such thing regardless of
the fact that the returned pointer points to const.

However, as a class designer, I would prefer to return a pointer
for which I am able to enforce the fact that nobody out there will
be able to use it to modify the data! So, I use const. Yes, const
protects me from other people stupidity and/or mistakes.

PLEASE understand that all I'm trying to say with the example of
string::c_str is the fact that, as a class designer, since I'm
returning a pointer that client code should NEVER delete for any
reason, wouldn't it be just great that I was able to syntactically
prohibit them to do it??

> The language can't help you from doing stupid things.

Oh yes it can!!! We deeply disagree on this one. I'll give you
that the language can't help you from all possible stupid things;
but many stupid things and not-so-stupid mistakes are caught by
the compiler -- and const accounts for some of those situations
where the language protects you from stupidity.

> Trying to delete
> a pointer that you have been handed, const or not, is stupid

And doing strcpy to a pointer that you have been handed this way,
const or not, is stupid. That doesn't mean that it's not a good
idea to cover your back and protect your code against client code's
stupidity.

> The fact that you're not supposed to delete the pointer has absolutely

> nothing to do with whether or not the pointer is const

I know!! That's precisely what the OP was complaining about (well, sort
of), and I partly agree with that argument. My point is that it seems
logical that it should have to do with the fact that is const. The use
of const always is redundant to some other factor. You put const to
the return value of c_str because no client code should modify it.

So, why is it that client code is not supposed to modify it? Because
of the const?? No, because they're not supposed to, period. So, should
that mean that the const is unnecessary there?

> 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.

Once again, try to understand this: you are not supposed to modify
the characters pointed to by it regardless of its constness. Still,
the const is there helping you, because it enforces the fact that you
will not be able to do something that you're not supposed to do.

The string::c_str argument is relevant if you accept that it all
boils down to the following argument: do we consider delete an action
that modifies the object pointed to by a pointer?? The standard --
and many people -- says NO. Many other people tend to think that yes.

If you accept for a second that deletion is a modifying operation
(just for the sake of the argument, assume for a second that deletion
of a pointer is an action that modifies the pointee), then you would
see that the example of string::c_str is relevant to the original
argument: you are not supposed to delete the pointer returned by
c_str, **regardless of anything**. Now, given that you're not
supposed to do it (because it would be stupid doing so), why not
enforcing it with the use of const, that would prevent deletion
given that it is a modifying operation? (it goes so well with the
idea of "you put const and sleep in peace").

> If it had returned a non-const pointer, it would have invoked undefined
> behavior to delete it also.

I know. But this has nothing to do with my argument. Look at it
this way: writing on an array beyond its capacity invokes undefined
behaviour no matter what, right? However, if that array had been
const, you wouldn't have been able to do it, would you? So, the
fact that undefined behaviour is invoked with or without the const
is no argument to put or not the const.

> (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.)

I think it was clear, given the discussion (then again, I've been
following the discussion from the beginning...)

James Kanze

unread,
Nov 17, 2000, 3:00:00 AM11/17/00
to
Erik Max Francis wrote:

> 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.)

The -i option causes rm to ask on every file. On the AIX, at least,
the current rm always asks if the file is write protected, whether the
option is given or not.

> > 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.

It's certainly not a very strong argument, and it works both ways.
The fact that I can destruct a local const argument is, from what I
understand, the main argument for being able to delete a const.

In the end, for me, the determining factor is which way will cause
less errors. And that would seem to argue for not deleting const.

--
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

James Kanze

unread,
Nov 17, 2000, 3:00:00 AM11/17/00
to
een...@electeng.leeds.ac.uk wrote:

> 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?

It depends on the OS. Under Unix, it is the files that have the
access permissions, not the references.

Francis Glassborow

unread,
Nov 17, 2000, 3:00:00 AM11/17/00
to
In article <3A12ED86...@alcyone.com>, Erik Max Francis
<m...@alcyone.com> writes

>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.

You sure about that? Do you know what value is stored in p after:

delete p;

??

Nonetheless, you can delete a const pointer.

>

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 ]

Francis Glassborow

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

>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!

However any function that deletes a pointer better be written by someone
who fully understands the implications. This has nothing to do with
const.

Erik Max Francis

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

> PLEASE understand that all I'm trying to say with the example of
> string::c_str is the fact that, as a class designer, since I'm
> returning a pointer that client code should NEVER delete for any
> reason, wouldn't it be just great that I was able to syntactically
> prohibit them to do it??

The way you do that is by documentation. A programmer that deleting
pointers (const or not) willy nilly is going to be trouble to any API
designer. Such a programmer should know that he or she _shouldn't_
delete any pointer he comes across unless the documentation for what
he's using _explicitly_ states that he can. This is true in the
Standard library as much as any other API you might put together.

> > The language can't help you from doing stupid things.
>
> Oh yes it can!!! We deeply disagree on this one. I'll give you
> that the language can't help you from all possible stupid things;
> but many stupid things and not-so-stupid mistakes are caught by
> the compiler -- and const accounts for some of those situations
> where the language protects you from stupidity.

It doesn't make sense to use constness to do this, because constness
means something else.

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

/ \ Men live by forgetting -- women live on memories.
\__/ T.S. Eliot
Fat Boy and Little Man / http://www.fatboyandlittleman.com/
Watch Fat Boy and Little Man go about their antics.

bran...@cix.compulink.co.uk

unread,
Nov 17, 2000, 3:00:00 AM11/17/00
to
mor...@cyberx.com (Carlos Moreno) wrote (abridged):

> Phew!!! I thought I was completely alone on this!!

There's me as well. I argued stridently against allowing the delete in
the c.l.s.c++ debate last year.

Here are a few points from that debate which I don't think have yet been
mentioned. The first is that deleting const *was* forbidden by the ARM.
See $5.3.4 for a good explanation of why. Briefly, "The reason is that
the deletion in principle modifies the object pointed to."

Thus the people who think it should be forbidden are in good company, and
the people who thought it is forbidden were right until recently.
Microsoft's compiler used to be correct, and is merely being slow in
tracking changes made by the ISO standard.

In last year's debate, the main practical reason given for allowing the
delete concerned templates. In a template, you may not know whether a
typename argument is const or not. The ISO rule thus makes templates
easier to write.

However, this difficulty is not insurmountable. Several idioms were
presented. I believe we showed every template that could be written with
the ISO rule could also be written, with minor changes, with the stricter
ARM rule. (One especially interesting idiom was a kind of const auto_ptr,
which stored a non-const pointer internally so it could delete it, but
exposed it as const so no-one else could call the object's non-const
methods.)

The debate did not end with consensus. People felt strongly on both
sides.

Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
bran...@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."

Carlos Moreno

unread,
Nov 17, 2000, 3:00:00 AM11/17/00
to
Francis Glassborow wrote:
>
> In article <3A12ED86...@alcyone.com>, Erik Max Francis
> <m...@alcyone.com> writes
> >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.
>
> You sure about that? Do you know what value is stored in p after:
>
> delete p;
>
> ??

In C, with free(p), the answer to your question used to be trivial :-)

> Nonetheless, you can delete a const pointer.

So, this tells me that surely, delete does not change the value of
the pointer (as we should all expect -- of course, since delete is an
operator, and not a function that receives the pointer by value, your
remark is reasonable).

Carlos
--

Carlos Moreno

unread,
Nov 17, 2000, 3:00:00 AM11/17/00
to
Francis Glassborow wrote:
>
> In article <3A12FD4A...@cyberx.com>, Carlos Moreno
> <mor...@cyberx.com> writes
> >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!
>
> However any function that deletes a pointer better be written by someone
> who fully understands the implications.

Well, and that's the case for anything. Any member function that
modifies the object better be written by someone who understands
the implications; any function that modifies the data pointed
to by a pointer better be written by someone who understands the
implications, etc.

But that doesn't mean that the const should not be used. Someone,
even understanding the implications of everything they do, could
still mistype something, or simply confuse the names of two variables
or parameters (by simple distraction), and introduce a serious bug
in the code. If such action violates a const, then the compiler
is there to tell you!!

> This has nothing to do with
> const.

Of course. Because the standard says that const means something
else. But the thing is that it seems reasonable that const could
(should?) have that meaning too, as Visual C++ mistakenly thinks
(that's the argument being debated; well, at least that's what I've
been trying to debate...)

The "mistakenly" means that Visual C++ is behaving in a way that
contradicts an explicit standard specification. But the point
being that if even a compiler manufacturer thought that const
should have that meaning, that tells you that at least it is
a reasonable point of view (notice how the standard phrases
that item -- it even bothers to put a note explicitly clarifying
that you can delete a pointer to const, that you do not need to
use const_cast to do that; if it was that obvious that const
has nothing to do with deletion of a pointer to const, they
probably wouldn't have bothered to clarify it so explicitly!)

Carlos Moreno

unread,
Nov 17, 2000, 3:00:00 AM11/17/00