On Thu,  2 Nov 2000 06:20:44 GMT, "Victor Bazarov" <vAbazarov@dAnai.com>
wrote:

> "Scott Meyers" <smeyers@aristeia.com> wrote...
> > Is there any good reason for list::remove not being called list::erase for
> > consistency with the associative containers?  And as long as we're at it,
> > is there any good reason for list::remove not returning the number of
> > elements erased, just like like erase (with a value) does in the
> > associative containers?
>
> Could it be because std::list _has_ methods names 'erase'?  See
> 23.2.2.3 list modifiers, after paragraph 2.  std::list::erase
> exists in two forms and both return an iterator:
>
>     iterator erase(iterator position);
>     iterator erase(iterator first, iterator last);

Not a valid reason.  Set has:

   void      erase(iterator position);
   size_type erase(key_type const& x);
   void      erase(iterator first, iterator last);

The remove algorithm does not remove, it just moves to another location
and must be followed by erase.

The only excuse for list having remove and remove_if is that nobody
mentioned it at the appropriate time.

The two list members should be changed to erase with a size_type
return.  While we are at it, the associatives should also have the
erase_if template member.  As many times as that algorithm has been
written wrong, it is badly needed.

Does anyone think this is DR material?  It just looks like design
standardized too quick to me.  There does not seem to be much hope
for fixing these things which are not broken, just bent.

John

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Scott Meyers" <smeyers@aristeia.com> wrote...
> Is there any good reason for list::remove not being called list::erase for
> consistency with the associative containers?  And as long as we're at it,
> is there any good reason for list::remove not returning the number of
> elements erased, just like like erase (with a value) does in the
> associative containers?

Could it be because std::list _has_ methods names 'erase'?  See
23.2.2.3 list modifiers, after paragraph 2.  std::list::erase
exists in two forms and both return an iterator:

    iterator erase(iterator position);
    iterator erase(iterator first, iterator last);

Victor
--
Please remove capital A's from my address when replying by mail



---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Victor Bazarov wrote:
>
> "Scott Meyers" <smeyers@aristeia.com> wrote...
> > Is there any good reason for list::remove not being called list::erase for
> > consistency with the associative containers?  And as long as we're at it,
> > is there any good reason for list::remove not returning the number of
> > elements erased, just like like erase (with a value) does in the
> > associative containers?
>
> Could it be because std::list _has_ methods names 'erase'?  See
> 23.2.2.3 list modifiers, after paragraph 2.  std::list::erase
> exists in two forms and both return an iterator:
>
>     iterator erase(iterator position);
>     iterator erase(iterator first, iterator last);

That doesn't stop the associative containers. As specified in Table 69,
they also have the same two signatures you list, AND an erase(const
key_type&) that does the same kind of thing that list<T>::remove(const
T&) does, except that the associative erase() returns the count of
elements erased.

I can see one reason not to do this. One of the advantages of giving a
function in two different classes the same name is to allow generic
programming: a single template can handle both classes just by calling
that function. The problem is that one function takes the argument
list::value_type, and the other takes the argument
associative_container::key_type, which would make taking advantage of
this a little more difficult. You could use value_type for std::set and
std::multiset, but not for std::map and std::multimap.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Is there any good reason for list::remove not being called list::erase for
consistency with the associative containers?  And as long as we're at it,
is there any good reason for list::remove not returning the number of
elements erased, just like like erase (with a value) does in the
associative containers?

Thanks,

Scott

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]