auto_ptr question

[flopbucket]

I saw the following post a few messages back and am trying to
understand exactly why this is so. Thanks for the information. My
comments begin with **[flopbucket]. The original post was arguing that
STL code that tried to have a container of auto_ptr (which I know is
wrong, but thats not the point here) should *NOT* compile according to
the standard.

--- start original post ---

There is a defined requirement, and if you're still in doubt, let me
spell it out. Section 23.2.4.3 of the C++ standard shows the following
function type for vector::push_back:

void push_back(const & x);

**[flopbucket] ok, I see this. But certainly you can pass a non const
object to a function that takes a const reference to that type. So I
can pass auto_ptr<void *> to something that expects const auto_ptr<void
*>&... So I don't see at this point why it should not compile.
Section 20.4.5 of the C++ standard shows the following for the auto_ptr
copy constructor:

auto_ptr(auto_ptr&) throw();
template<class Y> auto_ptr(auto_ptr<Y>&) throw();

Both copy constructors take non constant types.

**[flopbucket] Fine, makes sense. But just by calling push_back, which
takes a reference, I am not having any copy constructor being called.

So if you have a vector and an auto_ptr class that is compliant with
the C++ standard, it will not compile when you call member function
push_back.

--- end original post ---

So, my question is, why exactly does this fail to compile? I
understand that of course push_back will call the copy constructor to
copy the item for the container and at that point that template
instantiation will fail. But that is inside push_back, not the call to
push_back itself.

I guess I am just asking if my thinking is correct. I have been away
from C++ for a few years (assigned to some Java work and want to get
back into C++) and trying to catch back up with parts of the language.

So the point is that by only showing the definitions of the copy
constructors and the method signature for push_back - there is really
*NO* reason why it should not compile - it only fails because the
original poster knew details about what push_back did, correct? The
actual failure comes from the template instantiation and when push_back
tries to copy the element.

Thanks for the help

[werasm]

flopbucket wrote:

Section 20.4.5 of the C++ standard shows the following for the auto_ptr
copy constructor:

auto_ptr(auto_ptr&) throw();
template<class Y> auto_ptr(auto_ptr<Y>&) throw();

Both copy constructors take non constant types.

Member function push_back takes type <const T&> as argument. A copy of
the original is made in push_back. The copy constructor of T is
therefore called inside push_back. The fact that T is const (from
<const T&>) means that T's copy constructor's argument has the
constraint that it must either be by value, or by const reference.
std::auto_ptr<X>'s copy constructor does not comply to this constraint.

Hope it helps.

W

[flopbucket]

Yes, thanks. That was what I was trying toconfirm in my confusing
original post - that the error is really because inside push_back, a
copy is made.

Thanks