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.
While it's fairly obvious with hindsight that lexical_cast is indirectly including boost/mpl/limits/vector.hpp which is defaulting the limit to 20, the fact that the behaviour is differing between compilers is a bit unexpected, particularly since I don't want to mess with the limit if already set in case the users of my library need a higher limit, but they might have used lexical_cast themselves.
Has anyone else run into this type of problem before? It's also made me realise that using variant with MPL lists might be problematic if the end user changes the limit and this changes the underlying type? Should I just use vector40.hpp and ignore the limit?
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).
Thanks all, Roger
----source-------------------------------------------------------------- #include <string> #include <vector> #include <cstdint>
# ifndef BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS /// Disable MPL header preprocessing (to allow the following macros to be modified). # define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS # endif #include <boost/lexical_cast.hpp> # ifndef BOOST_MPL_LIMIT_VECTOR_SIZE /// MPL vector size limit increase. # define BOOST_MPL_LIMIT_VECTOR_SIZE 40 # endif //#include <boost/lexical_cast.hpp> # ifndef BOOST_MPL_LIMIT_LIST_SIZE /// MPL list size limit increase. # define BOOST_MPL_LIMIT_LIST_SIZE 40 # endif
#include <boost/mpl/insert_range.hpp> #include <boost/mpl/joint_view.hpp> #include <boost/mpl/transform_view.hpp> #include <boost/mpl/vector.hpp> #include <boost/mpl/vector/vector0.hpp>
#include <boost/version.hpp> #if BOOST_VERSION >= 105800 # include <boost/type_traits/remove_cv.hpp> #endif
typedef boost::mpl::vector<std::string, bool> non_numeric_types;
typedef boost::mpl::vector<uint8_t, uint16_t, uint32_t, uint64_t, int8_t, int16_t, int32_t, int64_t> integer_types;
typedef boost::mpl::vector<float, double, long double> float_types;
typedef boost::mpl::joint_view<integer_types, float_types>::type numeric_types_view;
typedef boost::mpl::joint_view<non_numeric_types, numeric_types_view>::type basic_types_view;
template<typename T> struct make_vector { typedef std::vector<T> type; };
typedef boost::mpl::transform_view<basic_types_view, make_vector<boost::mpl::_1> >::type list_types_view;
typedef boost::mpl::joint_view<basic_types_view, list_types_view> all_types_view;
typedef boost::mpl::insert_range<boost::mpl::vector0<>, boost::mpl::end<boost::mpl::vector0<> >::type, all_types_view>::type discriminated_types;
snipped...