Boost logo

Boost :

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


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