0

I'm trying to do something like that:

#define VERIFY_EXPECTATIONS       \
BOOST_MPL_ASSERT((expectation1)); \
BOOST_MPL_ASSERT((expectation2)); \
BOOST_MPL_ASSERT((expectation3))

and when writing VERIFY_EXPECTATIONS; in line, say 42, I get an error about a conflicting declaration of mpl_assertion_in_line_42.

I understand what is happening (BOOST_MPL_ASSERT uses an identifier that depends on the line where the macro is invoked) but my question is: is there a known workaround to do this kind of things?

Edit:

More precisely, the expectations look like that:

#define TEST_SOME_SET_OF_PREDICATES(Arg)          \
BOOST_MPL_ASSERT    ((some_predicate<Arg>));      \
BOOST_MPL_ASSERT_NOT((some_other_predicate<Arg>))

TEST_SOME_SET_OF_PREDICATES(some_type);
TEST_SOME_SET_OF_PREDICATES(some_other_type);

I have implemented the predicates and I want to test them with several types.

Note:

I'm not very interested in the following:

template <typename Arg>
struct compound_predicate : boost::mpl::and_<
    some_predicate<Arg>,
    boost::mpl::not_<some_other_predicate<Arg> >
> {};

BOOST_MPL_ASSERT((compound_predicate<some_type>));
BOOST_MPL_ASSERT((compound_predicate<some_other_type>));

because when an assertion fails, we don't know which of the expectations was wrong.

The solution suggested by Praetorian would be the following:

template <typename Arg>
struct expectations {
    BOOST_MPL_ASSERT    ((some_predicate<Arg>));
    BOOST_MPL_ASSERT_NOT((some_other_predicate<Arg>));
};

and then instantiate expectations with some_type and some_other_type. I would have to implement a macro that declares an object of type expectations<Arg> with a different identifier at each call. It looks a little bit like reimplementing (some part of) static assertions.

Any other ideas?

Christophe Fuzier
  • 689
  • 5
  • 11
  • wrap each of the mpl macros in `{}`? – user3159253 Jan 08 '16 at 16:19
  • Do not use mpl assert, and instead switch to std::assert? It's 2016, we surely can assume C++11 by default. – SergeyA Jan 08 '16 at 16:29
  • @SergeyA I would be glad to switch to C++11 or C++14 but - believe it or not - we are still using C++03 in my firm (despite my insistence!). – Christophe Fuzier Jan 08 '16 at 16:33
  • @user3159253 Nice try, thanks, but it does not work: it results in an `expected unqualified-id before '{' token` error. – Christophe Fuzier Jan 08 '16 at 16:35
  • 1
    What do these `expectationN` look like? Can you make `VERIFY_EXPECTATIONS` a class template instead, and instantiate it where it's needed? – Praetorian Jan 08 '16 at 19:19
  • @Praetorian See my edit. I can do that: it works, but there is some additional macro to implement in order to instantiate the template with the various types. But maybe this is the simplest solution anyway. – Christophe Fuzier Jan 11 '16 at 09:23

0 Answers0