[Patch] libstdc++/20787 (DR 130)

[Peter Doerfler]

Hi Paolo.

I have a question regarding the documentation. I might be getting this 
completely wrong and if so please regard this comment as an effort to 
understand more.

In your patch, e.g.
+      // _GLIBCXX_RESOLVE_LIB_DEFECTS
+      // DR 130. Return type of container::erase(iterator) differs for
+      //         associative containers.
       /**
        *  @brief Erases a [first,last) range of elements from a %set.
        *  @param  first  Iterator pointing to the start of the range to be
        *                 erased.
        *  @param  last  Iterator pointing to the end of the range to be 
erased.
+       *  @return  An iterator pointing to the element pointed to by @a last
+       *           prior to erasing (or end()).
        *
        *  This function erases a sequence of elements from a %set.
        *  Note that this function only erases the element, and that if
        *  the element is itself a pointer, the pointed-to memory is not 
touched
        *  in any way.  Managing the pointer is the user's responsibilty.
        */
-      void
+      iterator
       erase(iterator __first, iterator __last)
       {
 	typedef typename _Rep_type::iterator _Rep_iterator;
-	_M_t.erase((_Rep_iterator&)__first, (_Rep_iterator&)__last);
+	return _M_t.erase((_Rep_iterator&)__first, (_Rep_iterator&)__last);
       }

the documentation reads 'An iterator pointing to the element pointed to by @a 
last prior to erasing (or end())'

Doesn't the function return an exact copy of 'last' independent of erasing the 
other elements? At least the tree erase seems to do just that.
If that is the case maybe it would be better to remove the 'prior to..' part, 
possibly replacing the whole comment with
'A copy of last' or the like.

I was just confused by the documentation because it left the impression (at 
first glance) that 'last' and the return value might not point to the same 
element after erasing. I think they always do point to the same element - 
correct?

Thanks for your comments
-- Peter


On Friday 02 September 2005 14:29, Paolo Carlini wrote:
> Hi,
>
> a few days ago I noticed that the relevant DR in the meanwhile has been
> moved to [DR] status and decided to reconsider implementing its
> resolution. Indeed, apparently there is a very large consensus (see also
> Effective STL, outside the LWG references proper, f.i.) that changing
> the associative containers consistently with all the other containers is
> a good thing. The only minor disadvantage seems that a single
> erase(iterator) becomes computationally a little more expensive, due to
> the additional iterator increment (however, this is not the case for
> erase(iterator, iterator), because its internal loop can now make use of
> the erase(iterator) return value, i.e., the very same idiom used in
> list::erase).
>
> Anyone disagreeing with adding the below to mainline?!?
>
> Tested x86-linux.
>
> Paolo.
>
> //////////////////