Re: [Patch] Remove workaround for copy_backward

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Paolo Carlini <pcarlini@unitus.it> writes:

| Hi all, hi Gaby,
| 
| in the current code there is this disclaimer:
| 
| // This dispatch class is a workaround for compilers that do not
| // have partial ordering of function templates.  All we're doing is
| // creating a specialization so that we can turn a call to copy_backward
| // into a memmove whenever possible.
| template<typename _BidirectionalIterator1, typename _BidirectionalIterator2,
|          typename _BoolType>
|   struct __copy_backward_dispatch(...
| 
| However, interestingly, before it, in the implementation of copy, partial
| ordering of function templates *is used*, and this is safe since current
| g++ is actually ok (the disclaimer dates back to SGI/HP, I think!).
| 
| Therefore, I simply removed the workaround and used for copy_backward the
| very same dispatching strategy already present for copy.

Paolo,

  First, thanks for raising this issue.

In the abstract, I think your patch is correct.

However, in practice, I'll do differently.
For compile-time efficiency reasons, I would not go through
overloading resolution based on the last argument and function
template partial ordering.  
I would prefer the class dispatcher, not because I believe our lovely
compiler is broken, but because it saves unncessary overloading
resolution and partial ordering tourneys.  I've choosen to do that for
valarray. 

I'd use the class dispatcher in the following way

  // general implementation with minimal assumptions on the value_type
  template<typename>
    struct __copy_backward_dispatch {
      template<typename _BI1, typename _BI2>
        static _BI2 copy(...);
    };

  // special case for value_type with trivial copy constructor
  template<>
    struct __copy_backward_dispatch<__true_type> {
     // ...
    };

Note use of member templates.  That should eliminate some
specializations from the existing implementation.

-- Gaby