The following code gives me a compiler error on Visual Studio 2010 with both Boost 1.48 and 1.49beta1:

 

#include <string>

#include <boost/interprocess/allocators/allocator.hpp>

#include <boost/interprocess/containers/map.hpp>

#include <boost/interprocess/managed_shared_memory.hpp>

 

class Incomplete;

typedef boost::interprocess::allocator<std::pair<std::string, Incomplete>,

    boost::interprocess::managed_shared_memory::segment_manager> Allocator;

typedef boost::interprocess::map<std::string, Incomplete,

    std::less<std::string>, Allocator1> IncompleteMap;

class Incomplete

{

    IncompleteMap blah;

};

 

This code compiles fine if I instead use std::allocator.

 

As best as I can tell from the compiler message, at some point in the instantiation of map, boost::container::container_detail::version<T> is instantiated with

T=boost::interprocess::allocator<

    boost::container::container_detail::rbtree_node<

        std::pair<std::string,Incomplete>,

        boost::interprocess::offset_ptr<void>

    >,

    boost::interprocess::segment_manager<

        char,

        boost::interprocess::rbtree_best_fit<

            boost::interprocess::mutex_family

        >,

        boost::interprocess::iset_index

    >

> 

 

Which results in boost::container::container_detail::is_convertable<T,U> being instantiated with

T=boost::container::container_detail::version_type<

    boost::interprocess::allocator<…>, // Same as above

    0

> 

U=boost::container::container_detail::version_type<

    boost::interprocess::allocator<…>,

    2

> 

 

Somehow (I’m quite fuzzy on this), this results in boost::container::container_detail::rbtree_node<T,VoidPointer> being instantiated with T=std::pair<std::string,Incomplete>. This then results in the pair being instantiated, which has a member of type Incomplete… BOOM!

 

If I replace container_detail::is_convertible in extract_version with boost::is_convertible from Boost.TypeTraits (or with std::is_convertible, for that matter), the code above successfully compiles. Is this a valid temporary workaround, or will it lead to other complications?

 

Thank you,

Erik Jensen