This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Remove algo duplication
- From: Paolo Carlini <paolo dot carlini at oracle dot com>
- To: libstdc++ at gcc dot gnu dot org
- Cc: Marc Glisse <marc dot glisse at inria dot fr>, Christopher Jefferson <chris at bubblescope dot net>, François Dumont <frs dot dumont at gmail dot com>, Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Date: Tue, 17 Sep 2013 10:28:09 +0200
- Subject: Re: Remove algo duplication
- Authentication-results: sourceware.org; auth=none
- References: <52264074 dot 2050502 at gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1309081625460 dot 3536 at laptop-mg dot saclay dot inria dot fr> <522E246F dot 5040608 at gmail dot com> <E2836BBC-F90D-4AE5-AAAB-EB3242BF030D at oracle dot com> <CA+jCFLtpCASpP1NTru=__hOQo5O-uj0m82YDqmB2wBYxspcQxA at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1309151125180 dot 3593 at laptop-mg dot saclay dot inria dot fr> <CA+jCFLsgUS3x0AVQDvn1OUgkYt6EJJojUrL4xrtVo9XQwq8J6A at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1309161348100 dot 3698 at laptop-mg dot saclay dot inria dot fr> <523706CD dot 5060707 at oracle dot com> <alpine dot DEB dot 2 dot 10 dot 1309161636200 dot 3698 at laptop-mg dot saclay dot inria dot fr> <52371F6F dot 80409 at oracle dot com> <alpine dot DEB dot 2 dot 10 dot 1309162232110 dot 3698 at laptop-mg dot saclay dot inria dot fr> <52379F90 dot 5000108 at oracle dot com> <alpine dot DEB dot 2 dot 10 dot 1309170847350 dot 3594 at laptop-mg dot saclay dot inria dot fr>
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.