Boost logo

Boost Users :

Subject: Re: [Boost-users] Bad interaction between lexical_cast and MPL with VS2013
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-08-06 11:40:27

On 8/6/2015 5:59 AM, Roger Leigh wrote:
> 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?

It should be filed under 'mpl'. It's a problem in changing the MPL limits.

>> 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<>,

Sorry to give you wrong information last time. A numbered form always
holds the exact number of types specified by the number when created. So
you could use vector26<26 types... etc.> as a starting sequence.

> 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.)

I do not believe the type of the insert_range result has the limitations
show that I can use insert_range with a resulting range whose size is

> 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?

I think you need to specify example code which gives problems when using
numbered forms.

Also if you create a bug report under MPL in trac for any of the
problems you encounter I will look at it.

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