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.