🚀 go-pugleaf

In article <313BD2CA.7DBD@tiac.net> Hayden Schultz <haydens@tiac.net>
writes:

|> According to _STL Tutorial and Reference Guide_ by Musser and Saini
|> (a very good book, btw), the following functions are defined:

|> template <class T> void vector<t>::pop_back();
|> template <class T> void deque<t>::pop_back();
|> template <class T> void deque<t>::pop_front();
|> template <class T> void list<t>::pop_back();
|> template <class T> void list<t>::pop_front();

|> Other classes may have pop functions, I dunno.

|> Why don't the pop functions return a copy of the object before they
|> blow it away? Another possibility, I suppose, would be an auto_ptr<T>
|> so that the object is deleted if it's not used. An auto_ptr<T> is
|> about as efficient as deleting it in the pop function, it just changes
|> the time it's deleted (which isn't guaranteed anywhere I've read
|> anyway).

I suspect that no copy is returned because of performance reasons: to
return one would require making the copy in every case (whether it was
used or not), then destructing it.

I don't understand the remark concerning auto_ptr.  In order to return
an auto_ptr to the object, it would be necessary to allocate a new
copy of the object on the stack, then delete it.

I suppose some sort of intelligent reference could be returned, which
would destruct the object whenever it was destructed.  This might
still cause problems freeing the memory; I suppose that they would be
solvable.

But is it worth it?

|> Why call the methods push and pop if it doesn't act like a stack?

That is the real question.  A list is not a stack.  A deque is not a
stack.  A vector is not a stack.  The functions pop_front and pop_back
have nothing to do with the operation pop on a stack.  This is why it
is not worth the bother of having them return a value.  This is also
why it probably would have been better if they'd have had another
name. 
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]