Remove algo duplication

[Paolo Carlini]

Hi,

On 09/17/2013 09:07 AM, Marc Glisse wrote:
> On Tue, 17 Sep 2013, Paolo Carlini wrote:
>> I'm not sure however to understand in detail how much of this is just 
>> helper code for the algo duplication work, and how much is 
>> implementation of standard facilities. I suppose however, that we 
>> should cleanly separate the C++11 code from the C++98 emulation and 
>> have the latter only in predefined_ops.h or something.
> In the same conversation I apparently invented, I think it was agreed 
> that less<void> should be provided as an extension in C++11 (not just 
> as a standard feature in C++14).
Definitely I didn't follow the details of such conversation. But maybe 
you had it with Jon and I was distracted by the C++ front-end, for 
example. It's possible.
> This way would also provide a close enough emulation in C++03, but I 
> can totally understand if you don't want one. It isn't specifically 
> meant for the algo deduplication, which might use a completely 
> different scheme (François has already tried several). If we don't do 
> the C++03 emulation, using macros isn't worth it.
In my personal opinion, we should first provide what the standards 
mandate, that's the priority. Then, if people really want such an 
emulation and we are sure that there are no backward compatibility 
issues vs old code, certainly I'm not going to object.
>
>> In terms of details, we are trying not to use the deprecated 
>> unary_function / binary_function, not even as implementation details. 
>> In fact if we find ourselves often doing that, I don't see why we 
>> deprecated the facilities ;)
>
> The current code for std::less uses binary_function, I didn't change 
> it. It would be easy to change (a single place thanks to the macros). 
> But in some sense, std::less<T> with T!=void is almost deprecated, so 
> it isn't that strange that it uses a deprecated feature.
Now I remember, it's this issue: 
http://gcc.gnu.org/ml/libstdc++/2013-02/msg00073.html

In short, if we like the feature and we start using it as implementation 
detail for C++11 features, we end up depending on a deprecated feature. 
The above use of -D_GLIBCXX_USE_DEPRECATED=0 is just an example, more 
generally I think we shouldn't add such dependencies and slowly, no 
rush, move away from the existing ones (eh, it may boil down to a few 
renames to uglified names and little more)

Paolo.