From: williamkempf_at_[hidden]
Date: 2001-04-18 09:26:17
--- In boost_at_y..., Jesse Jones <jesjones_at_h...> wrote:
> >I've uploaded an updated header and a test file.
>
> Even more comments:
>
> 1) The checks are enabled via an integral number. The current order
is:
> precondition
> postcondition
> invariant
> assert
> where precondition is the lowest and assert the highest (ie when
> asserts are on everything else is on as well).
>
> I think invariant's should be the highest. They often do more than
> you'd really like to do in release. Moreover classes that don't
want
> or need an invariant will likely use assert for preconditions.
The order is taken from the DbC concept as described in OOSC2 by
Bertrand Meyer, and it makes sense. General assertion checks are the
least likely checks to be needed in production code. You suggest
that "classes that don't want or need an invariant will likely use
assert for preconditions" but this is a violation of DbC. A
precondition should always be a precondition. Attempting to use a
check (the proper term in DbC speak for a general assertion made
during processing of a method) in place of a precondition muddies the
intent and fails to convey the contract. Checks are for insuring
proper implementation of a method, they are not formally a part of
the contract (meaning they don't specify what's expected of the
caller or what's insured by the callee).
As for the worry about unnecessarily checking the invariants... in
general you should always check the invariants making this an
erroneous concern. In practice there are cases where this will be
true since we're using a C++ library and not a language feature (for
example, you wnat to check the invariants only at the end of a c-tor
and only at the beginning of a d-tor). However, this is precisely
why invariants aren't automagically checked by the preconditions
(well, one of the reasons any way).
> 2) I don't see why do_assert() needs the assertion argument. And
what
> about the "E* dummy=0" argument? All I can figure is that it's
there
> to allow overloading on the different exception types, but I don't
> think the macros or do_assert() is setup properly for that.
The Assertion argument comes from borrowing code. Given the
definition of the macros you are correct, it's not needed. The E*
dummy=0 is needed as a hack work around for a VC++ bug. With out
this dummy argument the wrong template instantiation is used (the
first one found in the translation unit is used for all other
instances). This is a common and well known fix for one of the most
vexing VC++ bugs.
> 3) I don't think it's a good idea to use BOOST_REQUIRE and
> BOOST_ENSURE inside a ctor or dtor.
According to DbC it is. What makes you think otherwise?
> 4) I've uploaded another implementation to the vault. Look for a
> folder called "DbC". The differences are as follows:
>
> a) It's quite a bit simpler for clients. All they have to do is
> declare an invariant method and define it using the normal assert
> mechanism (allowing for different responses to the various checks
> seems like overkill to me). The PRECONDITION macro calls ASSERT and
> creates a stack based class to invoke the invariant. (I'm aware
that
> the macro names probably won't fly).
>
> b) It won't work with mixins and I don't see how it can be made to
work.
>
> c) It's slightly slower since it uses a critical section. I'm
> inclined to think this is an acceptable tradeoff for a cleaner
client
> API.
I'll look at it later today, hopefully.
Bill Kempf