Boost logo

Boost Users :

Subject: Re: [Boost-users] Bad interaction between lexical_cast and MPL with VS2013
From: Roger Leigh (rleigh_at_[hidden])
Date: 2015-08-06 05:59:13

On 03/08/2015 18:05, Edward Diener wrote:
> On 8/1/2015 1:47 PM, Roger Leigh wrote:
>> Hi folks,
>> I have some code making use of both Boost MPL (and Variant) with
>> occasional use of lexical_cast in some translation units. This is
>> working fine on Linux/Unix/MacOS X with a wide range of GCC and clang
>> versions. However, when porting to Windows with MS Visual Studio 2013
>> and Boost 1.58, I've encountered an unexpected and subtle interaction
>> with the MPL and Boost headers. If I include them in the "wrong" order
>> it leads to bizarre compile errors.
>> After many hours of testing, I've reduced the failure down to the
>> minimal testcase below. In the code sample below, there are two
>> #includes for boost/lexical_cast.hpp. If the first is uncommented,
>> compiling fails. If this is commented and the second is uncommented,
>> compiling succeeds! The odd thing: the critical place is before and
>> after defining BOOST_MPL_LIMIT_VECTOR_SIZE. In the failure case the
>> limit size is 20, when succeeding it's 40. The code below requires more
>> than 20 to successfully compile.
> Changing the MPL limits should ideally be done before including any MPL
> header files. Since many Boost libraries use MPL this usually means that
> changing the MPL limits should ideally be done before including any
> Boost header files.
> I realize that this is not necessarily possible if you wish to change
> MPL limits in your own library since you can't control the order that an
> end-user will include your library's header file in a TU.
> I will look into this problem of why changing the MPL limits causes
> compiler errors in VS2013, but can you please create a Boost trac item
> concerning this problem. Recently there has been some activity in MPL
> concerning the issue of changing MPL limits so it is barely possible
> this is fixed in the recent source.

Certainly. I've just been doing some further investigation. Which
component should this be filed against? MPL or lexical_cast?

> You can do this since MPL normally ships with up to 50.
>> If I did this, do I need
>> to worry about the intermediate types in the code below, or do I just
>> need to use vector40 in place of vector<> (or in place of
>> vector0<>)
> From the MPL docs:
> "each numbered sequence form accepts the exact number of elements that
> is encoded in the name of the corresponding class template".
> So using vector40 means you can have up to 40 types in the vector.
>> --I'm unsure how insert_range knows which type to use or is it
>> vector0 in this case and I should be "allocating" space by using a
>> different type? [I am using vector<> in reality but tried vector0 here
>> to see if it made a difference]
> You shouldn't have to worry about intermediate types or insert_range.
> Any MPL algorithm knows how many types are in a sequence, just like you
> know (size<v>::type).

The numbered vector types are certainly working fine, e.g.

   typedef boost::mpl::vector3<float, double, long double> float_types;

I tried insert_range with vector26, like this:

   typedef boost::mpl::insert_range<boost::mpl::vector26<>,
boost::mpl::end<boost::mpl::vector26<> >::type,
                                    some_view>::type some_type;

but this results in:

  error: too few
       template arguments for class template 'vector26'
       typedef boost::mpl::insert_range<boost::mpl::vector26<>,

Is it safe to use insert_range with vector<> or vector0<> without
defining BOOST_MPL_LIMIT_VECTOR_SIZE? (The point behind it being to
remove the dependence upon that size limit.)

Without the limits being set I get errors like:

boost/variant/detail/make_variant_list.hpp:55:27: error: too many
template arguments for class template 'list'
     typedef typename mpl::list<

Since I don't use lists directly I assume they are used in the
intermediate joint_view/transform_view types I create. Is there any way
around avoiding the need to specify a LIST_SIZE limit here?


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at