Re: [boost] unordered_map failing to compile on MSVC7.1 using STLport

Subject: Re: [boost] unordered_map failing to compile on MSVC7.1 using STLport
From: Robert Dailey (rcdailey_at_[hidden])
Date: 2012-02-13 17:41:18

On Mon, Feb 13, 2012 at 3:28 PM, Daniel James <dnljms_at_[hidden]> wrote:

> On 13 February 2012 17:11, Robert Dailey <rcdailey_at_[hidden]> wrote:
> > I would really appreciate some insight here, I have no idea what is going
> > on. This is actually preventing company code from compiling, so it's
> > extremely important. If I can't get help here the only thing I can do is
> > just not use boost.
> >
> > The "call stack" chain for template instantiation provided in my pasted
> > error is confusing. It shows the source of where I create the
> > unordered_map, which is in  gdgalquery.h(40), but after that it says that
> > _locale.h is next? How is _locale.h next? That tells me that STL is
> > instantiating my class? Anyone know what is going on?
>
> Sorry, I missed this before. The main problem is that we no longer
> have Visual C++ 7.1 testers, so regressions for that compiler are
> quite likely. In this case the problem is with support for C++11
> allocators. There's an emulated version of C++11's allocator traits
> which doesn't seem to work for Visual C++ 7.1. The simplest way to fix
> that is probably to disable most of the new features for older
> versions of Visual C++, and hope that everything else works okay.
>
> Although it might be possible to get the new features to work on
> Visual C++ 7.1. There are two possible places where it's failing.
> First is the has_select_on_container_copy_construction trait, second
> is the use of SFINAE the disable the function where you saw this
> error. This detects in an allocator has a
> has_select_on_container_copy_construction member. Try running this:
>
>    #include <iostream>
>    #include <boost/unordered_map.hpp>
>
>    int main()
>    {
>        std::cout << boost::unordered::detail::
>            has_select_on_container_copy_construction<
>                std::allocator<int>
>            >::value << std::endl;
>    }
>
> It it prints '0' the trait has successfully found that std::allocator
> doesn't have the member, so we know the problem must be in the use of
> SFINAE, which might be fixable (I don't know how myself, but I think
> other libraries do it). If it prints '1' the trait failed, and I'm not
> sure how to fix it.

Unfortunately it does print 1 for me :(