Hello,

I wonder why the above member function does return a pointer to non-const.
This allows a client to write:
 "std::auto_ptr< int > i(new int);
  delete i.get();"
which will crash your application because i does not know about the deletion,
so i will delete the integer instance a second time.

In my opinion the standard library should prevent users from writing such code
by refusing to compile it, which could have been done by returning a pointer
to const instead.

This question has to do with the fact that "const X *x" has two different meanings at
the same time: "*x can not be changed AND x can't be deleted."
There's a detailed description by Andrew Koenig of this topic within this newsgroup:
<http://groups.google.ch/groups?selm=FHysGz.66M%40research.att.com&oe=UTF-8&output=gplain>.

If "std::auto_ptr<>::get()" really has a bug concerning the non-const-ness of the object pointed
to by its return value, then this bug also applies to Bjarne Stroustrup's "Handle<>::get_rep()" as
published in C++PL, 3rd german ed. 1998, p. 844.

Cheers,
Philipp.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

<"reverse email address" <ed.soxi@nnamhcab.ppilihp ( "Philipp Bachmann")> wrote in message news:bjsh99$s02$1@rex.ip-plus.net...

> I wonder why the above member function does return a pointer to non-const.

Why should it return const?   The object it refers to isn't const (or else it
whould have behooved you to use a std::auto_ptr<const int>.

> In my opinion the standard library should prevent users from writing such code
> by refusing to compile it, which could have been done by returning a pointer
> to const instead.
'
Unless using a broken compiler (like VC++), making the return type const X* wouldn't
have any affect on being able to delete it.

>
> This question has to do with the fact that "const X *x" has two different meanings at
> the same time: "*x can not be changed AND x can't be deleted."

No, it does NOT have the latter meaning.

> There's a detailed description by Andrew Koenig of this topic within this newsgroup:
> <http://groups.google.ch/groups?selm=FHysGz.66M%40research.att.com&oe=UTF-8&output=gplain>.

You've not read that carefully enough.   Andy is arguing the opposite point and that is what was
adopted by the standard.  That is, that const has no bearing on delete.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bjsh99$s02$1@rex.ip-plus.net>, \ reverse email address" wrote:
> Hello,
>
> I wonder why the above member function does return a pointer to non-const.

It would not be very useful otherwise; it is meant to hold any object
pointer type.

> This allows a client to write:
>  "std::auto_ptr< int > i(new int);
>   delete i.get();"
> which will crash your application because i does not know about the
> deletion, so i will delete the integer instance a second time.
>
> In my opinion the standard library should prevent users from writing such
> code by refusing to compile it, which could have been done by returning a
> pointer to const instead.

That would not prevent deletion.

> This question has to do with the fact that "const X *x" has two different
> meanings at the same time: "*x can not be changed AND x can't be deleted."
> There's a detailed description by Andrew Koenig of this topic within this
> newsgroup:
><http://groups.google.ch/groups?selm=FHysGz.66M%40research.att.com&oe=UTF-8&output=gplain>.
<snip>

Evidently you don't understand the description.  The const modifier does
not prevent deletion - if it did, it should also prevent destruction, but
then how would a const object ever be destroyed?  VC++ 6 and maybe some
other old implementations treat it as doing that, but they are incorrect.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

\"reverse email address\"" <ed.soxi@nnamhcab.ppilihp ("\"Philipp Bachmann\") writes:

> Hello,
>
> I wonder why the above member function does return a pointer to non-const.
> This allows a client to write:
>  "std::auto_ptr< int > i(new int);
>   delete i.get();"
> which will crash your application because i does not know about the deletion,
> so i will delete the integer instance a second time.
>
> In my opinion the standard library should prevent users from writing such code
> by refusing to compile it, which could have been done by returning a pointer
> to const instead.

I'm afraid that's not so.  Deleting a pointer-to-const is perfectly
legal.

> This question has to do with the fact that "const X *x" has two different meanings at
> the same time: "*x can not be changed AND x can't be deleted."

But it actually doesn't have the latter meaning.

> There's a detailed description by Andrew Koenig of this topic within
> this newsgroup:
> <http://groups.google.ch/groups?selm=FHysGz.66M%40research.att.com&oe=UTF-8&output=gplain>.

And I believe you must've misinterpreted Andrew's post.  He seems to
be advocating the current semantics.  I agree with him, and here's
another argument:

        since a statically allocated const object is (and must be)
        destructible, a dynamically allocated const object must be
        deletable.

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

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]