[boost] Re: Compile time assertions

From: Beman Dawes (beman_at_[hidden])
Date: 2000-02-10 19:52:29

At 09:07 AM 2/10/00 -0800, Darin Adler wrote:

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

10) Won't silently fail on slight coding errors.

Last fall I tried a bunch of variations on compile time assert ideas
(we used the name "require") suggested by Kevlin Henney and Steve
Cleary.  One of the problems was that forgetting something simple
like a variable name resulting in silent failure:
require<something_is_true>();  // looks OK but silently does nothing!
 The last thing in the world we want is something that looks like it
is checking for an error but in fact is doing absolutely nothing.

--Beman