Hello everyone, Allow me to reiterate my question: On Sun, May 30, 2010 at 8:42 PM, Lorenzo Caminiti <lorcaminiti@gmail.com> 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)... 2) What Eiffel does in this case does not help me much because there is not really something like protected inheritance in Eiffel... 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". 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. What do you think?

From Cline and Lea, "The Behavior of C++ Classes", 1990 -- A++: <<< 3.3 Inheritance C++ supports both public and private subclasses. Private subclasses are used either for partial code reuse or to express a has-a relationship. With private derivation, no mechanism is provided for automatic inheritance either by C++ (inheritance of the public interface) or by A++ (inheritance of behavioral constraints). Public derivation express the is-a or subtype relation: if VStack is publically derived from Stack, a VStack is-a Stack. The implication, lacking currently in C++, is that a VStack should behave like a Stack. This is accomplished in A++ by providing VStack with all the behavioral specications of Stack. Since the two types may use inherited protected members dierently, the legal and coherent class-wide specications are not automatically inherited.

...

...

On Sun, May 30, 2010 at 8:42 PM, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:

Hello all (and N1962 authors especially),

How should subcontracting work for non-public base classes?

I have listed a few examples below. Assume contracts were written for all these example classes (invariants) and their functions (pre/post conditions).

My questions are: A) `c::p()` should subcontract; but what about any of the other member functions of `c`, should any of them subcontract also? B) Am I missing any other combination of member/inheritance access level significant for deciding when to subcontract?

   class bp {    public:        virtual void p(void) { std::cout << "bp called" << std::endl; }    };

   class bf {    protected:        virtual void f(void) { std::cout << "bg called" << std::endl; }    };

   class bg {    public:        virtual void g(void) { std::cout << "bg called" << std::endl; }    };

   class bh {    public:        virtual void h(void) { std::cout << "bh called" << std::endl; }    };

   class c: public bp, public bf, protected bg, private bh {    public:        // This should subcontract.        virtual void p(void) { bp::p(); }        // Should any of the following subcontract also?        virtual void f(void) { bf::f(); }        virtual void g(void) { bg::g(); }        virtual void h(void) { bh::h(); }        // Am I missing any other relevant combination?    };

(I do not think multiple inheritance is relevant for my questions. I am using multiple inheritance in this example just so to have only one derived class `c` which exercises all the use cases.)

My notes and questions: 1) All member functions of `c` are public so they will check their pre/post conditions as in `c` and `c` class invariants. 2) But shall any `c` member functions also check their base class invariants and/or base function pre/post conditions? 3) `c::p()` should subcontract `bp::p` pre/post and `bp` inv because it is a public function publicly inheriting from a base public function. ** 4) Maybe `c::f()` should subcontract `bf::f()` pre/post but not `bf` invariant... (because `bf::f` is protected thus it does not have to check `bf` invariant). ** ** 5) Should `c::g()` and `c::h()` subcontract given that their inheritance is not public? **

Thank you very much.

-- Lorenzo

-- Lorenzo