Re: [Boost-users] Bad interaction between lexical_cast and MPL with VS2013

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?

Regards,
Roger