Question

Is this a Boost bug or am I doing something wrong?

#include <map>
#include <boost/pool/pool_alloc.hpp>

int main()
{
    typedef const std::string key;
    typedef double* (*value)(const int&);
    std::map<key, value, std::less<key>> map_with_standard_allocator; // works
    std::map<key, value, std::less<key>, boost::fast_pool_allocator<std::pair<const key, value> > > map_with_boost_allocator; // fails
}

the last line fails to compile under MS Visual Studio 2008 with Boost 1.40 and 1.48. It compiles fine under g++ 4.5.3 (Cygwin), though.

The error is:

1>Compiling...
1>main.cpp
1>C:\UniLib1\trunk\External\boost/pool/pool_alloc.hpp(205) : error C2535: 'const std::basic_string<_Elem,_Traits,_Ax> *boost::fast_pool_allocator<T,UserAllocator,Mutex,NextSize>::address(const std::basic_string<_Elem,_Traits,_Ax> &)' : member function already defined or declared
1>        with
1>        [
1>            _Elem=char,
1>            _Traits=std::char_traits<char>,
1>            _Ax=std::allocator<char>,
1>            T=const std::basic_string<char,std::char_traits<char>,std::allocator<char>>,
1>            UserAllocator=boost::default_user_allocator_new_delete,
1>            Mutex=boost::details::pool::default_mutex,
1>            NextSize=32
1>        ]
1>        C:\UniLib1\trunk\External\boost/pool/pool_alloc.hpp(202) : see declaration of 'boost::fast_pool_allocator<T,UserAllocator,Mutex,NextSize>::address'
1>        with
1>        [
1>            T=const std::basic_string<char,std::char_traits<char>,std::allocator<char>>,
1>            UserAllocator=boost::default_user_allocator_new_delete,
1>            Mutex=boost::details::pool::default_mutex,
1>            NextSize=32
1>        ]
1>        c:\Program Files\Microsoft Visual Studio 9.0\VC\include\xtree(137) : see reference to class template instantiation 'boost::fast_pool_allocator<T,UserAllocator,Mutex,NextSize>' being compiled
1>        with
1>        [
1>            T=const std::basic_string<char,std::char_traits<char>,std::allocator<char>>,
1>            UserAllocator=boost::default_user_allocator_new_delete,
1>            Mutex=boost::details::pool::default_mutex,
1>            NextSize=32
1>        ]
1>        c:\Program Files\Microsoft Visual Studio 9.0\VC\include\map(78) : see reference to class template instantiation 'std::_Tree<_Traits>' being compiled
1>        with
1>        [
1>            _Traits=std::_Tmap_traits<key,value ,std::less<key>,boost::fast_pool_allocator<std::pair<key,value >>,false>
1>        ]
1>        .\main.cpp(9) : see reference to class template instantiation 'std::map<_Kty,_Ty,_Pr,_Alloc>' being compiled
1>        with
1>        [
1>            _Kty=key,
1>            _Ty=value,
1>            _Pr=std::less<key>,
1>            _Alloc=boost::fast_pool_allocator<std::pair<key,value >>
1>        ]

Answer 1

This is not a bug in VS2008 (as I mistakenly claimed in an earlier edit to this answer). The C++03 standard requires that the key type for an associative container, like std::map, must be ‘assignable’ (per Table 69 in 23.1.2 “Associative containers”). And a const std::string is not assignable. Note that the C++11 standard seems to relax this requirement, but the new standard doesn’t apply to since VC++ 2008.

It’s not clear to me that a compiler is required to diagnose code that tries to use std::map with a non-assignable key, so I don’t think one can claim that GCC or VC++ 2010 are accepting this code improperly (I think it falls into the area of undefined code that works as you might expect, even though there’s no guarantee it’ll work). However it is clear that it’s OK for VC++ 2008 to refuse to compile it.

All that said, I think that VC++ 2008’s library parameterizing the allocator’s address() function on the map’s key rather than map’s element is still suspect (see the first edit of this answer for details if you’re interested), but I don’t think there’s any real bug there since the std::pair<> used to hold the map element will always be set up such that key part will be at the same address as the whole element.