Sorry for the late reply but I just realized that my original reply of Jun 9 bounced back... On Tue, Jun 8, 2010 at 4:28 PM, Thorsten Ottosen <nesotto@cs.aau.dk> wrote:
Lorenzo Caminiti skrev:
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)...
Well, since it has no special case for this, the same rules apply for all types of virtual functions.
Does "the same rules" mean that, regardless of the inheritance access levels of the base classes: 1) Preconditions are checked in OR with the ones of all base functions. 2) Postconditions are checked in AND with the ones of all base functions. 3) Class invariants are checked in AND but only with base class invariants for of public base functions. I want to make sure I understand especially 3) clearly in the context of deep inheritance level (not multiple inheritance). Assume contracts were written for all these classes and member functions: class a { // Don't check a:: invariants. protected: virtual void f(void) {} }; class b: public a { // Check b:: invariants (but not a:: invariants). public: virtual void f(void) {} }; class c: protected b { // Check b:: invariants (but not c:: or a:: invariants). protected: virtual void f(void) {} }; class d: protected c { // Check d:: and b:: invariants (but not c:: or a:: invariants). public: virtual void f(void) {} }; A call to d::f() will end up checking d:: and b:: class invariants but not c:: or a:: class invariants -- correct?
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?
Yes, you can override a private virtual function and do so even if the base class is private (I have written a simple example to double check that). Therefore, "no special rule" is a reasonable option.
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.
This was cited in "Design and Evolution of C++". If you are interested, you can find A++ papers at: http://gee.cs.oswego.edu/dl/papers/A++-sooppa.ps (the page order is reversed...) http://gee.cs.oswego.edu/dl/papers/A++-C++AtWork.ps
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.
I think, the subcontracting rules of A++ make sense but they are a bit more complex for users to understand than N1962 simpler rule "there is no special rule". Furthermore, I have never experienced any real benefit/need for implementing something like A++ subcontracting rules. Therefore, I am happy to implement Boost.Contract as specified by N1962 with "no special subcontracting rule based on the base class inheritance access level". (However, I might have more observations on the topic once I start implementing this.) -- Lorenzo