From: Persson Jonas (Jonas.Persson_at_[hidden])
Date: 2002-02-12 11:51:10
A simpler solution to that problem would be:
struct interface {
return_type method(param_type param) {
pre(param);
return_type ret=method_impl();
post(ret);
return ret;
}
protected:
virtual return_type method(param_type param) = 0;
};
That would also allow subclasses to refine the conditions:
struct subclass : interface {
return_type method(param_type param) {
looser_pre(param);
return_type ret=interface::method_impl(param);
stricter_post(ret);
return ret;
}
};
/ Jonas
> -----Original Message-----
> From: vesa_karvonen [mailto:vesa_karvonen_at_[hidden]]
> Sent: Tuesday, February 12, 2002 8:15 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Boost Documentation Template questions
>
>
> --- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> [...]
> >No, DBC does require language support. DBC relies on inheritance of
> >the pre- and post-conditions as well as the invariants, and such
> >inheritance requires language support. I've seen a few attempts
> >at "grafting" this into C++ through the use of an intelligent
> >preprocessor, but that is fragile and frankly still a form of
> >language support.
>
> I would prefer to have stronger metaprogramming support that would
> allow the implementation of DBC and many other things.
>
> Meanwhile, I've used a number of techniques for DBC. Consider the
> following example:
>
> struct interface {
> // requires: pre(param)
> // ensures: post(method(param))
> virtual return_type method(param_type param) = 0;
> // ...
> };
>
> struct implementation_a : interface {
> return_type method(param_type param) {
> pre(param);
> // ...
> post(result);
> return result;
> }
> // ...
> };
>
> struct implementation_b : interface {
> return_type method(param_type param) {
> pre(param);
> // ...
> post(result);
> return result;
> }
> // ...
> };
>
> The above is how interface contracts are typically found in C++
> programs: they are described in the comments of the interface and
> repeated for each implementation of the interface.
>
> A much better alternative is to implement a contract decorator or
> layer for each interface:
>
> struct interface_contract_decorator : interface {
> interface_contract_decorator(interface* implementation)
> : m_implementation(implementation) {}
>
> return_type method(param_type param) {
> pre(param);
> return post(m_implementation->method(param));
> }
> // ...
> };
>
> // or
>
> template<class implementation>
> struct interface_contract_layer : implementation {
> // A suitable constructor template
>
> return_type method(param_type param) {
> pre(param);
> return post(implementation::method(param));
> }
> // ...
> };
>
> We can now easily add the contract to any implementation:
>
> return new interface_contract_layer<implementation_a>();
>
> // or
>
> return new interface_contract_decorator(new implementation_b());
>
> These techniques have been very useful on many occasions.
>
> When inheritance of the contracts is needed, which in my experience
> isn't nearly as often as one would think, these techniques can be
> adapted so that the desired effect is achieved.
>
>
>
> Info: http://www.boost.org Send unsubscribe requests to:
<mailto:boost-unsubscribe_at_[hidden]>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/