[boost] Re: Compile time assertions

From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-02-10 14:21:07

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here's my attempt at a compile time assert class.  I think it pretty
much fulfills all the requirements you listed below.

Approach:

Declare a template<bool> ctassert struct.  Explicitly specialize the
false version to have a private constructor.
Anytime someone tries to create a ctassert<false>, they get a compile
time error at the point of instantiation.

Code:

template <bool okay> struct ctassert;
template <> struct ctassert<true> { }; // produces no code
template <> struct ctassert<false> { private: ctassert(); }; // fails
loudly

const bool compileTimeValue = true;

class foo 
   : ctassert<compileTimeValue> // can be a base class
{
public:
   ctassert<compileTimeValue> check; // or can be a member

   foo(){} // <-- compile error would happen here if ctassert<false>
is constructed
};

void bar()
{
   ctassert<compileTimeValue>(); // explicitly test by creating a
temporary
   ctassert<compileTimeValue>; // misuse. This doesn't try to
instantiate the class, so no error.   
}

Those who do not find macros distasteful can get more assert()-like
verbage by defining
   #define CTASSERT(x) ctassert<(x)>()
to create a temporary object of type ctassert for the test.  
This macro could be used in implementations but not declarations,
just like assert().
It yields more readable syntax, e.g.
   CTASSERT(myConstValue > 4);
// notice the '>' is not a problem, this is due to the parentheses in
the macro.

The only feature this uses that may not have wide acceptance is
explicit specialization, but I think most popular compilers probably
have this by now.

Comments?  Suggestions?
Any shortcomings besides the misuse example in bar() above?

- -- Mark

> -----Original Message-----
> From: Darin Adler [mailto:darin_at_[hidden]]
> Sent: Thursday, February 10, 2000 12:08 PM
> To: Boost
> Subject: [boost] Re: Compile time assertions
> 
> 
> > I've heard various mentions in the past (here?) about 
> implementing compile
> > time assertions and wondered if anyone had considered 
> implementing them for
> > boost as part of a general debugging section to the library.
> 
> There were a number of messages about this last December, 
> including a sample
> implementation. Check out
> <http://www.egroups.com/MessagesPage?method=performAction&list
> Name=boost&sea
> rch=ctassert> to see them.
> 
> In my past attempts to create a compile-time assertion 
> implementation (I
> used the name postulate for mine), I've never been able to create
> an implementation that fulfills all the 5 requirements suggested by
> Csaba Szepesvari in December 1999:
> 
>     (R1) Give an error message *at the line* where the 
> assertion fails.
>     (R2) Usable in both declarations and implementations in 
> the same way.
>     (R3) No real code should be generated and no storage 
> should be used.
>     (R4) No macros.
>     (R5) Namespaces should be polluted in a minimal way.
> 
> Here's a cut at the requirements I came up with back in February
> 1999.  
> 
>      1) no runtime cost: Using it has no cost or effect on 
> the program other
> than preventing it from compiling -- it doesn't change 
> optimizations, sizes
> of structures, or anything like that.
>      2) use anywhere: It can be used inside a function 
> definition or outside
> a function definition, inside a structure (or class) 
> declaration or outside
> a structure declaration.
>      3) simple syntax: It can be called in the same simple 
> way that assert
> can be.
>      4) can use compile-time constants: It can use anything that
> the compiler can figure out at compile time, using the same rules 
> as those for
> array sizes, for example, not the more-restrictive rules of the
> preprocessor.
>      5) stop with error: With a false expression it will 
> prevent the program
> from compiling, causing an an error.
>      6) portable: It will work as described above on any conforming
> implementation (uses only things in the standard).
>      7) good error message: The error message will be easy to 
> understand on
> any implementation.
>      8) points to correct line: The line that the compiler 
> reports an error
> on will be the line of the statement on any implementation.
>      9) practical: It will work as described above on 
> currently available
> implementations.
> 
> Jay Zipnick has a page about this subject at
> <http://www.best.com/pub/~jayz/C++/Postulate.html>. I'm not 
> sure Jay has
> ever publicized it.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>

iQA/AwUBOKMPqP9Ej8AEXMygEQJtFgCgk26QW9GJrmaIEpYQWz85f6cdjQMAnRao
qc64w//GTpdfiJHKaNVO3dH7
=tTtZ
-----END PGP SIGNATURE-----