[Bug libstdc++/51626] New: [4.6 Regression] [C++0x] can't use C++98 allocators with -std=c++0x

["redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51626

             Bug #: 51626
           Summary: [4.6 Regression] [C++0x] can't use C++98 allocators
                    with -std=c++0x
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: redi@gcc.gnu.org


#include <memory>
#include <vector>

template <class T>
struct allocator98 : std::allocator<T>
{
    template <class U> struct rebind { typedef allocator98<U> other; };

    allocator98() { }

    template <class U> allocator98(const allocator98<U>&) { };

    void construct(T* p, const T& val) { std::allocator<T>::construct(p, val);
}
};

int main()
{
    std::vector< int, allocator98<int> > v(1);
}

This fails in c++0x mode because std::__uninitialized_default_n_a() incorrectly
assumes it's OK to call Alloc::construct with a single argument.  That is true
for std::allocator in C++0x mode, but not true for most user-defined allocators
written to the C++98 requirements.

This is the cause of https://svn.boost.org/trac/boost/ticket/5538

The bug is fixed in 4.7 because std::allocator_traits provides a default
implementation of construct, ensuring backwards-compatibility with C++98-style
allocators.

A workaround for user-defined allocators is to add:
  void construct(pointer p) { return construct(p, value_type()); }

The fix for libstdc++ would be to avoid calling construct with a single
argument, or to backport a minimal version of allocator_traits from 4.7