This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] list::remove vs const& arguments...


It would seem to be easy to fix std::list<T>::remove() by using a 
local copy of the value, since T is required to be CopyConstructible.

The same isn't true for std::remove() AFAICT.

But anyway ...

As an aside, why does std::remove() have this requirement?

      __glibcxx_function_requires(_ConvertibleConcept<_Tp,
            typename iterator_traits<_ForwardIterator>::value_type>)

This seems too restrictive to me - there's no assignment from _Tp
to the iterator's value_type, so why require the conversion?

The correct requirement is checked for

      __glibcxx_function_requires(_EqualOpConcept<
            typename iterator_traits<_ForwardIterator>::value_type, _Tp>)

so the right thing to do would seem to be to remove the check for
Convertible.

2004-09-14  Jonathan Wakely

	* include/bits/stl_algo.h: Remove too restrictive concept-check.

OK for mainline?
I don't think this is a regression, as it's been this way for ages,
but only matters when _GLIBCXX_CONCEPT_CHECKS is defined... 3.4 too?

jon

-- 
"There are books in which the footnotes, or the comments scrawled by some 
 reader's hand in the margin, are more interesting than the text. The world 
 is one of those books."
	- George Santayana

Attachment: libstdc++-remove_concept_checks.patch
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]