On 13 February 2012 17:11, Robert Dailey <rcdailey@gmail.com> 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.