Boost logo

Boost :

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

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
> whatever; anyway here goes again:
> Thanks, I obviously should have logged on yesterday, to pick up the
> instead I was also working on the compile time assert package - hey
> 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
> for the class which generates the error message I used:
> COMPILE_TIME_PRECONDITION_FAILED, which should catch the eye: note
> 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 -
> 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
> 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
> are used - both typedefs and enum's are descibed as declarations in
> 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
> 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.

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