Kai-Uwe Bux wrote:
Axter wrote:
An**********@gmail.com wrote: BTW, do not use the standard library auto_ptr. Due to it's copy
semantics, it is not appropriate for use in STL containers.
Any fully compliant C++ compiler will not allow you to do a push_back
to a container of std::vector<auto_ptr<T> > type.
Where in the standard did you find that? The closest I found is [20.4.5/3]:
[...] auto_ptr does not meet the CopyConstructible and Assignable
requirements for Standard Library container elements and thus
instantiating a Standard Library container with an auto_ptr results
in undefined behavior.
This quote says it's undefined behavior. You seem to claim that it is an
error and diagnostics is required.
IAW the standard it is considered undefined behavior to instantiate
this type, but that's not what I'm referring to, and that's why I
specified push_back call for auto_ptr type.
std::vector<auto_ptr<T> > ptr; //This is undefined IAW C++ standard
ptr.push_back(auto_ptr<T>(new T)); //This is not allowed IAW C++
standard
IAW the standard, you can NOT perform a push_back of an auto_ptr<T> to
a container of auto_ptr<T>.
The standard doesn't explicitly state this, and it would be hard for it
to do so on a type that is undefined.
But it does disallow it indirectly, since the standard clearly defines
an auto_ptr copy constructor taking a non-constant type, and a
vector::push_back taking a constant type.
20.4.5.1 auto_ptr constructors
auto_ptr(auto_ptr &a) throw();
//23.2.4.3 modifiers
void push_back(const T& x);
So IAW C++ standard you can not perform a push_back of type auto_ptr<T>
on a container of auto_ptr<T>.
IAW C++ standard, your compiler may or may not let you declare a
container of auto_ptr<T>, but it can not let you populate it via
push_back.
----------------------------------------------------------------------------------------
David Maisonave
http://axter.com
----------------------------------------------------------------------------------------