This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Remove algo code duplication
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: François Dumont <frs dot dumont at gmail dot com>
- Cc: "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, Marc Glisse <marc dot glisse at inria dot fr>
- Date: Wed, 2 May 2012 20:51:05 +0100
- Subject: Re: Remove algo code duplication
- References: <4F9BA3CF.2000606@gmail.com> <alpine.DEB.2.02.1204281307410.2528@laptop-mg.saclay.inria.fr> <4FA18C34.7070004@gmail.com>
On 2 May 2012 20:34, François Dumont wrote:
>> Ah, yes, to remove the code, the new solution has to work in C++98, which
>> prevents the simpler solution of having a non-template functor __less that
>> perfectly forwards anything it is given to operator<.
>
> non-template, really ?
I assume Mark means something like:
struct less {
template<typename T, typename U>
bool operator()(T&& t, U&& u)
{ return std::forward<T>(t) < std::forward<U>(u); }
};
i.e. a class (not a class template) with a member function template.
>> It probably doesn't matter, but the difference with the current code can
>> be seen. With -fno-elide-constructors you perform copies, operator< is
>> always given an lvalue, etc.
>
> You mean functor copies, right ? I expect the compiler to optimize them away
> even if there are options to forbid him to do so. In fact I also expect the
> compiler to optimize away all the functor simple plumbery, if there is a way
> to make this assumption safer do not hesitate to tell me. I wonder if not
> qualifying the parenthesis operators as const might be a reason for the
> compiler to not inline it. If it is so important I will try to detect if the
> invoked operator is const qualified to make the parenthesis operator const
> also.
That's unlikely to change anything, the compiler can tell if the
functor is stateless and not modified by the function call operator.
> Maybe I should add a noexcept qualification ?
Does the standard forbid operator< from throwing? I don't see such a
restriction.