I just noticed that between the Apr 95 and Dec 96 drafts
auto_ptr::release became a const member function, and the auto_ptr
copy constructor now takes a const auto_ptr & (previously no const).
Am I correct in assuming that this was done so that auto_ptr
would meet the "CopyConstructible" requirements (section 20.1.3)
so that it could be stored in a container, or was there
another reason?

If this was the reason, I am wondering why the committee decided
to modify (pervert?) auto_ptr in this way instead of loosening
the CopyConstructible requirements to make it fit in its old form.
The current form seems to allow code like this to compile:
  void gotcha(const vector<auto_ptr<T> > &v)
 {
 vector<auto_ptr<T> > vcopy(v);  // sets all pointers in v to 0
 }
To allow containers to work with classes that have copy constructors
taking references to non-const objects, you would need to provide
overloaded versions of all member functions in the container
that take a reference to a const object as an argument - perhaps
this is just too messy...
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Bill Dimm wrote:
>
> I just noticed that between the Apr 95 and Dec 96 drafts
> auto_ptr::release became a const member function, and the auto_ptr
> copy constructor now takes a const auto_ptr & (previously no const).
> Am I correct in assuming that this was done so that auto_ptr
> would meet the "CopyConstructible" requirements (section 20.1.3)
> so that it could be stored in a container, or was there
> another reason?
>
> If this was the reason, I am wondering why the committee decided
> to modify (pervert?) auto_ptr in this way instead of loosening
> the CopyConstructible requirements to make it fit in its old form.
> The current form seems to allow code like this to compile:
>   void gotcha(const vector<auto_ptr<T> > &v)
>         {
>         vector<auto_ptr<T> > vcopy(v);  // sets all pointers in v to 0
>         }
> To allow containers to work with classes that have copy constructors
> taking references to non-const objects, you would need to provide
> overloaded versions of all member functions in the container
> that take a reference to a const object as an argument - perhaps
> this is just too messy...

OK. I can see the point of confusion. Does the 'const' apply to the
auto-pointer itself, or to the object pointed to? In this case, it
refers to the pointer and the initialization of vcopy should produce
a diagnostic since it modifies v. On the other hand, it is perfectly
reasonable to zero v since ownership of the referenced object has
been transfered to vcopy and the object will be destroyed when vcopy
goes out of scope. If you didn't intend to transfer ownership, then
vcopy should not have been an auto-pointer.

I suspect that you understand this very well, so please don't take
offense at my restating the obvious. It took me a minute to see
what you were concerned about. I just want to make sure that I
have the problem properly in focus.

mtew@duke.edu
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]