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