[boost] Re: compile time asserts

From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-02-28 18:13:08

> -----Original Message-----
> From: scleary_at_[hidden] [mailto:scleary_at_[hidden]]
> Sent: Monday, February 28, 2000 4:42 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: compile time asserts

> 
> > 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.

or 

  3) Define a version that would work on either
#define BOOST_CT_ASSERT_N(unique_number,cond)  ... (use number to make the
declaration unique)
#define BOOST_CT_ASSERT(cond) BOOST_CT_ASSERT_N(__LINE__,cond)

BOOST_CT_ASSERT won't work on MSVC because of its preprocessor problems, but
BOOST_CT_ASSERT_N would work as long as you give it a hint to make it
unique.

So if I use MSVC, I can use

BOOST_CT_ASSERT_N(1,sizeof(char)==1);
BOOST_CT_ASSERT_N(2,sizeof(short)==2);
BOOST_CT_ASSERT_N(3,sizeof(int)==4);
        (note: the numbers are unimportant, they just need to be unique)

and if I don't care about MSVC, I can use the more concise

BOOST_CT_ASSERT(sizeof(char)==1);
BOOST_CT_ASSERT(sizeof(short)==2);
BOOST_CT_ASSERT(sizeof(int)==4);

The above approach does not take anything away or make it more complex for
the gcc/BCB/MW/? users.
The only downside: MSVC users need to use a somewhat awkward macro. But
since they couldn't use CT asserts otherwise, I think this is a small price.

>
> 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 :)

Let's not get into a religious war about compilers.

Like a gold fish that eats until it fills the fish tank, a developer will
grow to use all the features in the compiler he/she uses most.  When
switched to a different compiler with different capabilities, it is natural
to think of the compiler as broken.  For example, when I switched from VC to
gcc at my last job, I hated it because I couldn't use namespaces.  I'm sure
the reverse transition would be just as awkward, if not more.  

I have little experience with Borland/KAI/MetroWerks. I've heard good things
about all, but I suspect that when you start poking around, you'll find
different sets of features implemented.  The fact is, very few compilers
have total standard compliance (I only know of EDG -- tho' I may be wrong).
I'd guess even fewer have implemented all allowable optimizations.  

It is easy to say ignore MSVC 'cuz its preprocessor is broke, but many of us
have to use MSVC for one reason or another.  Ignoring the compiler does not
hurt the compiler maker, it hurts the programmers.  I am not advocating that
we cater to the lowest common denominator (as far as portability), if that
were the goal we would be writing C libraries.  But when there is a
not-too-heinous workaround for a limitation in a popular compiler, I say use
it.

Mark