Fwd: Re: [Patch] Remove workaround for copy_backward
Douglas Gregor
gregod@cs.rpi.edu
Sun Sep 28 14:57:00 GMT 2003
On Saturday 27 September 2003 02:30 pm, Gabriel Dos Reis wrote:
> Douglas Gregor <gregod@cs.rpi.edu> writes:
> | Has anyone considered replacing the dispatching mechanism with one based
> | on enable_if? That would eliminate the need for multiple levels of
> | indirection (__copy, __copy_aux, __copy_aux2, etc.).
>
> I never had the time to do a thourough auditing of the library;
We don't need the library per se, because our favorite compiler can handles
the idiom fine. We need only:
template<bool Cond, typename _Tp = void> struct __enable_if {};
template<bool Cond, typename _Tp>
struct __enable_if<true, _Tp>
{ typedef _Tp type; };
> another
> reason was that, I have no idea of exactly how far we can do in ABI
> breaking...
>
> -- Gaby
There are two places this can change the ABI:
* constructors that use the technique will get an extra argument
* if a program ends up relying on one of the dispatching functions (e.g.,
because of inlining), those dispatching functions will disappear.
For reference, here are the declarations to do the appropriate dispatching
when we pass two integral types to the list constructor:
explicit list(size_type __n, const _Tp& __value = _Tp(),
const _Allocator& = _Allocator());
template <class _InputIterator>
list(_InputIterator __first, _InputIterator __last,
const _Allocator& = _Allocator(),
typename __enable_if<
(!__is_integral<_InputIterator>::value)>::type* = 0);
Compare it to what libstdc++ currently does. I can tell you that it doesn't
fit in two extra lines of code.
Doug
More information about the Libstdc++
mailing list