Re: Remove algo duplication

[Marc Glisse <marc dot glisse at inria dot fr>]

On Tue, 17 Sep 2013, Paolo Carlini wrote:
> 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.

Nah, I probably just invented it.

> > 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.

I am quite convinced there is no significant backward compatibility issue, 
less<void> was simply meaningless beforehand, that's why it was so easy to 
have the new less<void> accepted in the standard. Adding it in C++11 (not 
just C++14) is basically free. Whether we want a C++03 emulation is a 
harder question.

> > > 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)

I didn't add any dependency and didn't use it for the new features, I only 
left it where it was to minimize changes. It is really easy to remove (or 
rename to __binary_function).

--
Marc Glisse