Subject: Re: [boost] [contract] non-public subcontracting (N1962)
From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2010-06-08 16:28:17
Lorenzo Caminiti skrev:
> Hello everyone,
> Allow me to reiterate my question:
> On Sun, May 30, 2010 at 8:42 PM, Lorenzo Caminiti <lorcaminiti_at_[hidden]> wrote:
>> How should subcontracting work for non-public base classes?
> (See details in my previous email below.)
> 1) I have looked at N1962 (and its previous revisions) but I could not
> see how the proposal addresses non-public inheritance. I might be
> missing something (given that the N1962 is rather detailed)...
Well, since it has no special case for this, the same rules apply
for all types of virtual functions.
> 2) What Eiffel does in this case does not help me much because there
> is not really something like protected inheritance in Eiffel...
You can override a private virtual function, so why should the rules
be special for them?
> 3) I looked at an old Contract Programming proposal for C++ called
> "A++". This proposal addresses this issue as quoted below but this is
> a very old proposal from 1990 so I cannot consider it the "state of
> the art".
I had not seen this before. Thanks.
> BTW, I am asking because I need to decide how to implement
> subcontracting for protected and private inheritance in
> Boost.Contract. One option could be (essentially following A++):
> a) Preconditions, postconditions, and invariants are all subcontracted
> for public inheritance.
> b) Only preconditions and postconditions (but no invariants) are
> subcontracted for protected inheritance.
> c) Nothing is subcontracted for private inheritance.
> This should still satisfy Liskov substitution principle.
I guess you can do whatever is the easiest. I'm not up to date with
the rules, but is it not so that I can override a priviate virtual
function of a private base class? If so, I see no reason to make special
rules forbidding subcontracting although it is somewhat unclear what
the point with a such a piece of code would be.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk