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: Daniel James (dnljms_at_[hidden])
Date: 2012-02-13 16:28:15

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.