Request: allow general typelist types in BOOST_AUTO_TEST_CASE_TEMPLATE()

[Tony E Lewis <tonyelewis@…>]

In ticket:12092 I requested that BOOST_AUTO_TEST_CASE_TEMPLATE() be generalised to allow users to specify the typelist as a std::tuple of types, as well as a boost::mpl::vector. You added this feature - thanks very much.

As discussed in ticket:12092#comment:7, since I made the original request, I've come to realise that TMP gurus avoid using std::tuple as a typelist because it has complex guts that needlessly eat up compiler-time for each instantiation. Instead, I think they typically just use an arbitrary empty template struct, eg:

template <typename...> struct my_typelist_wrapper {};

using a_typelist = my_typelist_wrapper<int, char>;

With this in mind, it might be nice to consider finessing the conversion to boost::mpl::vector so that it works from any arbitrary such typelist (including std::tuple). Here's an illustrative implementation of the idea (which I've slightly tweaked since ticket:12092#comment:7 so that if the metafunction is called with anything other than a single, valid typelist, it will return a dummy type with a descriptive name which will hopefully make the compiler errors more helpful):

struct arg_type_is_not_single_valid_typelist final {
   arg_type_is_not_single_valid_typelist() = delete;
   ~arg_type_is_not_single_valid_typelist() = delete;
   arg_type_is_not_single_valid_typelist(const arg_type_is_not_single_valid_typelist &) = delete;
   arg_type_is_not_single_valid_typelist & operator=(const arg_type_is_not_single_valid_typelist &) = delete;
};

template <typename...>
struct mpl_vector_of_typelist_impl {
   using type = arg_type_is_not_single_valid_typelist;
};

template <template <typename...> class T,
          typename... Us>
struct mpl_vector_of_typelist_impl< T< Us... > > {
   using type = boost::mpl::vector<Us...>;
};

template <typename T>
using mpl_vector_of_typelist_t = typename mpl_vector_of_typelist_impl<T>::type;

Here are some simple usage examples:

template <typename...> struct my_typelist_wrapper {};

static_assert(  std::is_same<  mpl_vector_of_typelist_t< my_typelist_wrapper< int, char > >,  boost::mpl::vector<int, char >         >::value, "" );
static_assert(  std::is_same<  mpl_vector_of_typelist_t< std::tuple         < int, char > >,  boost::mpl::vector<int, char >         >::value, "" );
static_assert(  std::is_same<  mpl_vector_of_typelist_t< int                              >,  arg_type_is_not_single_valid_typelist  >::value, "" );

[Raffi Enficiaud]

Well, I am not sure that mpl::vector can handle, especially because a ​preprocessor value that is limiting the variadicity is involved.

I suggest this instead: I will keep the std::tuple internally, and slightly improve the API such that constructing a std::tuple is not needed (and instead any variadic template would do).

What do you think?

The argument checking is definitely a good thing to have, and you will have a more general API. It will not be faster in terms of compilation machinery since it will still involve std::tuple, at least internally.

[Tony Lewis <TonyELewis@…>]

Thanks for the reply.

Ah sorry - I think I was assuming that you're currently still using boost::mpl::vector internally but AFAIU, you're saying you use std::tuple.

_{(I'm a bit surprised because I thought the library supported pre-C++11 so would need to convert everything to a pre-C++11 typelist. Is that incorrect?)}

Anyway, the thing I'm specifically requesting in this ticket is that BOOST_AUTO_TEST_CASE_TEMPLATE() accept arbitrary type lists (boost::mpl::vector, std::tuple or the user's own typelist type).

I'm not making any requests about how you store the typelist internally (though if you don't have to support pre-C++11 and are already using std::tuple, it's possible you'd enjoy reduced compilation times by moving to template <typename...> your_own_typelist;).

So yes: the thing you're proposing is exactly what I'm requesting. Thanks very much.

[Raffi Enficiaud]

In branch topic/GH-141-mp11-hana-typelist

[Raffi Enficiaud]

In master, rev 622a035e34af52ab68c3817645aefd4c6a1da0e5. Should be in 1.70 release.