Boost logo

Boost :

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
>Szepesvari in December 1999:
> (R1) Give an error message *at the line* where the assertion
> (R2) Usable in both declarations and implementations in the same
> (R3) No real code should be generated and no storage should be
> (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
> 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
>a function definition, inside a structure (or class) declaration or
>a structure declaration.
> 3) simple syntax: It can be called in the same simple way that
>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
> 5) stop with error: With a false expression it will prevent the
>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

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at