Re: compile time asserts [preconditions]

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-07-31 09:08:32

I strongly suggest you pick a different name.  Preconditions already 
have a very well known meaning, for which a compile time assert does 
not work.  Specifically, a precondition is one of the three 
components that build up the foundation of DBC (design by contract): 
precondition, postcondition and invariant.  All of these are runtime 
assertions.  A precondition is that that must be upheld before a 
function can be called (aka it's what you must insure when you call a 
function).

DBC may not be native in C++, but many people (most?) are aware of 
the concept and use it to some degree even in C++.  It's a powerful 
enough concept that it may even be given consideration in later 
revisions of the C++ language.  So, again, I'd strongly suggest not 
using this name to indicate a compile time assertion.

William E. Kempf

--- In boost_at_[hidden], John Maddock <John_Maddock_at_c...> wrote:
> Hey guys,
> 
> Thanks for all the comments on this - unfortunately I posted this 
mail to
> the wrong address yesterday (sorry Steve), so this now may be a 
little out
> of date.  If you want I'm happy to change the name to static_assert 
or
> whatever; anyway here goes again:
> 
> Thanks, I obviously should have logged on yesterday, to pick up the 
debate,
> instead I was also working on the compile time assert package - hey 
ho.
> 
> With regard to naming, I chose BOOST_PRECONDITION(x) - the intent 
is to say
> "look guys if this isn't true then don't even bother compiling this 
code",
> for the class which generates the error message I used:
> COMPILE_TIME_PRECONDITION_FAILED, which should catch the eye: note 
that
> these names are not set in stone, it's almost trivial to change 
them if
> there is something clearer around (I don't like postulate though - 
sorry!).
> 
> The docs are preliminary, but should give the general idea, along 
with some
> reasonably useful examples.
> 
> Someone asked about usage at namespace scope in a header - this can 
produce
> conflicts and this is covered in the docs along with a 
recomendation to
> insert the preconditions into their own namespace so that the scope 
of the
> declarations are unique to that header.
> 
> Finally with regard to template instantiation - regardless of 
whether an
> enum or typedef based approach is used, the declarations should be
> instantiated at the same time as the template regardless of whether 
they
> are used - both typedefs and enum's are descibed as declarations in 
the
> standard (not definitions), and it's only definitions which are
> instantiated on demand, all declarations should be instantiated 
with the
> template (anyhow that's my reading of it).  However since Beman has
> encountered problems with unused declarations not being 
instantiated, I've
> put both versions in the header; the default is to use an enum, but
> defining BOOST_USE_TYPEDEF_PRECONDITION will switch over to the 
typedef
> version - it's there in case a particular compiler has a problem 
with the
> enum version.
> 
> Anyway its all in the vault under "precondition".
> 
> 
> - John.