Boost logo

Boost :

From: scleary_at_[hidden]
Date: 2000-02-28 16:41:41


john maddock wrote:
> So I think that both C and C++ behave the same and the macro
expansion as
> we have it is correct.

Agreed.

> 3) typedef method:
> This is a variation on (2), the code is:
>
> namespace boost{
>
> template <bool> struct ct_assert;
>
> template <> struct ct_assert<true>{};
>
> template<int> struct ct_assert_test{};
>
> }
>
> #define BOOST_CT_ASSERT( B )\
> typedef ::boost::ct_assert_test<sizeof(::boost::ct_assert< ( B ) >)>
> BOOST_JOIN(_boost_postulate_details_, __LINE__)
>
> #define BOOST_DO_JOIN( X, Y ) X ## Y
> #define BOOST_JOIN( X, Y ) BOOST_DO_JOIN( X, Y )
>

This is the best implementation I've seen! It satisfies all the
requirements, and works flawlessly on BCB4 (& command-line 5). I would
just change 'ct_assert' to 'BOOST_CT_ASSERT_FAILED', so that the error
would be something like "Undefined type BOOST_CT_ASSERT_FAILED" (I
justify the all-caps because I consider this structure to be part of
the implementation of a macro, and not a normal type, per se). I think
that this solution is good enough to be accepted as the Boost
"official" solution -- it works on (some) current compilers for every
case I know of.

> Finally, in the face of all these compiler problems - given that the
> definitions are quite compact, we could have compiler specific
versions
> where required.

Yes, but for some compilers I don't know if a solution is possible.
IMO, we have two choices:
  1) Split BOOST_CT_ASSERT up into different macros for use in
namespace/function/class scope; but then users have to make the
unpleasant choice of whether to use the "unportable but correct"
BOOST_CT_ASSERT or the "portable but deprecated" specific-scope macros.
 Scope-specific solutions are possible for any compiler (I think).
  2) Leave BOOST_CT_ASSERT a single macro and say that VC just isn't
compiler enough to use it.

I would choose (2) -- VC is nowhere near the compliance of other
compilers, and as we move into more complicated template libraries,
support for brain-damaged compilers is going to be harder and harder
(IMO), so we'll have to drop them sooner or later. But then again, I'm
also lazy and I already have BCB :)

       -Steve


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk