> ""Matthias Hofmann"" <hofmann@anvil-soft.com> wrote
> > auto_ptr ... copy constructor and the assignment operator
> > each take a reference to a const auto_ptr now?

pasa@lib.hu ("Balog Pal") wrote
> The rumor WAS true.  Somewhere in 1996.
...
> Then the actual standard fixed that, so auto_ptr had the nonconst
> interface. You can be pretty sure no one will ever change that.
> Breaking existing code or changing behavior silently is a thing
> committee does not vote for.

Doesn't usually, anyway. But changing the constructor and assignment
to accept const auto_ptr doesn't neccesarily break anything, depending
on the semantics. Certainly the committee can add a new constructor
in addition to the existing one!

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

"Allan W" <allan_w@my-dejanews.com> wrote in message news:7f2735a5.0305061328.455f1d24@posting.google.com...

> > Then the actual standard fixed that, so auto_ptr had the nonconst
> > interface. You can be pretty sure no one will ever change that.
> > Breaking existing code or changing behavior silently is a thing
> > committee does not vote for.
>
> Doesn't usually, anyway. But changing the constructor and assignment
> to accept const auto_ptr doesn't neccesarily break anything, depending
> on the semantics. Certainly the committee can add a new constructor
> in addition to the existing one!
>
Nothing, theoretically, should be broken by the STANDARD auto_ptr
behavior.   The copy constructor / copy-assignment operator does not
take a const reference.   This doesn't break semantics because auto_ptr_ref
handles the case of the rvalue-to-lvalue issue with regard to returning auto_ptrs.

A const reference arg is bad, because it means that the auto_ptr doesn't
work.   It can't get the original auto_ptr to release ownership, which defeats
the whole purpose.

-Ron


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

"Allan W" <allan_w@my-dejanews.com> wrote in message news:7f2735a5.0305061324.6065d6cc@posting.google.com...

> ...
> > If [this is true], how can ownership of the pointer still be
> > transferred by the assignment/copy?
>
> My answer:
> > ...for this particular case that wouldn't even be neccesary.
> > Look up the keyword 'mutable' in any good C++ textbook, and you
> > can easily see exactly how it would work.
>
And while your answer will allow the const referred-to object to
be change, it is NOT THE RIGHT ANSWER for the auto_ptr or
any other issue with respect to copy constructors.

The problem is that if the original object wasn't const, then yes, you
can use this trick to modify it.   However, you don't know that it
really wasn't const.  If it was, you've now introduced silently induced
undefined behavior.

mutable has it's purposes, but this ain't one of them.


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

"Allan W" <allan_w@my-dejanews.com> wrote:
> > Second, for this particular case that wouldn't even be neccesary.
> > Look up the keyword 'mutable' in any good C++ textbook, and you
> > can easily see exactly how it would work.

ron@sensor.com ("Ron Natalie") wrote
> No compiler trickery is needed, but mutable (and const_cast<>) are
> the wrong answer to the problem.

I wasn't trying to solve the auto_ptr (or any other) problem.
I was responding to a direct question, which you snipped:

hofmann@anvil-soft.com ("Matthias Hofmann") wrote
> rumor has it that the standards commitee has changed the interface
> for auto_ptr in such a way that the copy constructor and the
> assignment operator each take a reference to a const auto_ptr now.
...
> If [this is true], how can ownership of the pointer still be
> transferred by the assignment/copy?

My answer:
> ...for this particular case that wouldn't even be neccesary.
> Look up the keyword 'mutable' in any good C++ textbook, and you
> can easily see exactly how it would work.

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

""Matthias Hofmann"" <hofmann@anvil-soft.com> p   e v diskusn   m p      sp   vku
news:3eafe699@news.nefonline.de...
> Hello,
>
> rumor has it that the standards commitee has changed the interface for
> auto_ptr in such a way that the copy constructor and the assignment
operator
> each take a reference to a const auto_ptr now. As far as I understand
this,
> it now looks like
>
> auto_prt<T>::auto_ptr( const autoptr<T>& rhs );
> auto_prt<T>& auto_ptr<T>::operator=( const autoptr<T>& rhs );
>
> Is this true? If yes, how can ownership of the pointer still be
transferred
> by the assignment/copy?

    How about "mutable" or "const_cast" ? :)

    In fact, this is why we have

    #define pick_ const

    in our code:

    auto_prt<T>::auto_ptr( pick_ autoptr<T>& rhs );

    is not so confusing.

    Anyway, right solution would be to allow binding of temporaries to
non-const references. That would solve all this mess.

Mirek


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

hofmann@anvil-soft.com ("Matthias Hofmann") wrote
> rumor has it that the standards commitee has changed the interface for
> auto_ptr in such a way that the copy constructor and the assignment operator
> each take a reference to a const auto_ptr now. As far as I understand this,
> it now looks like
>
> auto_prt<T>::auto_ptr( const autoptr<T>& rhs );
> auto_prt<T>& auto_ptr<T>::operator=( const autoptr<T>& rhs );
>
> Is this true?

I don't know.

> If yes, how can ownership of the pointer still be transferred
> by the assignment/copy?

That one's easy.

First, standard libraries are allowed to use nonstandard 'compiler
magic' that portable programs would never use.

Second, for this particular case that wouldn't even be neccesary.
Look up the keyword 'mutable' in any good C++ textbook, and you can
easily see exactly how it would work.

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

""Mirek Fidler"" <cxl@volny.cz> wrote in message news:b8tnv3$mv0$1@news.vol.cz...

>     How about "mutable" or "const_cast" ? :)

Not safe.   If you rely on making the auto_ptr copy operations
break const (either by an internal const_cast or use of mutable),
then introduce situations where you end up changing the auto_ptr
when it really should be const.

The auto_ptr_ref hack is the right (and standard) solution.



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

""Matthias Hofmann"" <hofmann@anvil-soft.com> wrote in message news:3eafe699@news.nefonline.de...

> rumor has it that the standards commitee has changed the interface for
> auto_ptr in such a way that the copy constructor and the assignment operator
> each take a reference to a const auto_ptr now.

The rumor WAS true.  Somewhere in 1996.

> Is this true? If yes, how can ownership of the pointer still be transferred
> by the assignment/copy?

CD2 introduced this completely broken auto_ptr.  It still had ownershop transfer, coupled with that interface. The implementation did cast away const in order to do the job.
[Yes, however unbelievable, this made it to the final public draft.]

Then the actual standard fixed that, so auto_ptr had the nonconst interface.
You can be pretty sure no one will ever change that. Breaking existing code or changing behavior silently is a thing committee does not vote for.

But it's possible a group of other smart ptrs get standardised.  There was a good CUJ article on that topic, look around in the experts section.

Paul

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

"Allan W" <allan_w@my-dejanews.com> wrote in message news:7f2735a5.0305020923.3713fac3@posting.google.com...

> Second, for this particular case that wouldn't even be neccesary.
> Look up the keyword 'mutable' in any good C++ textbook, and you can
> easily see exactly how it would work.

No compiler trickery is needed, but mutable (and const_cast<>) are the
wrong answer to the problem.


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

Hello,

rumor has it that the standards commitee has changed the interface for
auto_ptr in such a way that the copy constructor and the assignment operator
each take a reference to a const auto_ptr now. As far as I understand this,
it now looks like

auto_prt<T>::auto_ptr( const autoptr<T>& rhs );
auto_prt<T>& auto_ptr<T>::operator=( const autoptr<T>& rhs );

Is this true? If yes, how can ownership of the pointer still be transferred
by the assignment/copy?

Regards,

Matthias



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