|
Boost : |
Subject: Re: [boost] unordered_map failing to compile on MSVC7.1 using STLport
From: Robert Dailey (rcdailey_at_[hidden])
Date: 2012-02-14 13:00:23
On Mon, Feb 13, 2012 at 4:41 PM, Robert Dailey <rcdailey_at_[hidden]> wrote:
> 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 :(
>
Anyone know of a way to fix this for MSVC 7.1?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk