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: 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 
of BOOST_MPL_LIMIT_VECTOR_SIZE or BOOST_MPL_LIMIT_LIST_SIZE. My tests 
show that I can use insert_range with a resulting range whose size is 
greater than BOOST_MPL_LIMIT_VECTOR_SIZE or BOOST_MPL_LIMIT_LIST_SIZE.

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