$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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.