Re: [boost] [contract] Mixin Boost.Contract and Boost.STM

Subject: Re: [boost] [contract] Mixin Boost.Contract and Boost.STM
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2010-03-20 13:26:15

Hello:

On Sat, Mar 20, 2010 at 11:53 AM, vicente.botet
<vicente.botet_at_[hidden]> wrote:
> 2. (inherit) also needs to be specified at the function level because
> a specific function c::f() might override x::f() and y::f(), but
> c::g() overrides z::g(), and maybe c::h() does not override -- where
> x, y, and z are base classes of c. For a given function, the compiler
> knows if that same function appears in one of the base classes but the
> library does not. Therefore for a given function the programmers must
> indicate the specific subset of base classes from which that function
> is inherited from (and the library will subcontract from these
> specific base functions).
> Again, this could be avoided if I could metaprogram "for c::f(), if
> x::f() exists (true) do something; or z::f() exists (false) do
> something; ..." -- I was not able to metaprogram this.
>
> VBE> If I understand, you mean that if a class inherits from x,y,z, you dont need to specific the (inherit) for all the classes but only the class the function is been overriding, isn't it?

Sorry, I was not able to explain myself. I will try to clarify.

Boost.Contract is not capable to automatically subcontract. If inherit
is not specified, there is no subcontracting and the library does not
give any error (this is NOT ideal... it's a limitation of the
library).
The reason for this is that the library does not automatically know if
a given function c::f() is overriding one (or more) base functions or
not. The C++ compiler knowns because it can inspect all base classes
x, y, z, ... looking for x::f(), y::f(), ... but I was not able to
metaprogram this automatic "base class inspection" in the library.

For example, let:

    struct x {
        virtual void f() CONTRACT_FUNCTION( ... )
        ...
    };

    struct y {
        virtual void f() CONTRACT_FUNCTION( ... )
        ...
    };

    struct z {
        // No void f() here.
        ...
    };

Then:

    struct c: x, y, z { // (1)
        void f() CONTRACT_FUNCTION( (struct) (c) (inherit)(x)
(inherit)(y) ... ) // Compiles and subcontracts.
    };

    struct c: x, y, z { // (2)
        void f() CONTRACT_FUNCTION( (struct) (c) ... ) // Doesn't
subcontract but still compiles...
    };

    struct c: x, y, z { // (3)
        void f() CONTRACT_FUNCTION( (struct) (c) (inherit)(x) ... ) //
Only subcontract from x but still compiles...
    };

    struct c: x, y, z { // (4)
        void f() CONTRACT_FUNCTION( (struct) (c) (inherit)(z) ... ) //
Does not compile because z::f() does not exist.
    };

(2) and (3) are limitations of the library -- they should not compile
because the programmers of the derived class are avoiding to
subcontract.
(1) is also a "limitation" because ideally the library would
automatically know when to subcontract without the need for
programmers to specify (inherit) at all.
(4) is fine.

I was not able to overcome these limitations because I could not
metaprogram code that "inspects" the base classes looking for the
existence of a `virtual f()`... Is this possible? (E.g., I do not know
how boost::is_base_of works and, who knows, maybe that technique is
relevant to overcome these Boost.Contract limitations...)

> You have no comented my suggestion to don't duplicate the signature. Instead of letting the C++ signature, generate it from the macro, so

This is possible (I will have to extend the signature-sequence just a
bit to include default argument values, exception specifications,
member list initializations, and absolutely anything else you can
program in a C++ function declaration -- but most of the declaration
tokens are already there).

There is a question of what syntax is more readable vs. which syntax
requires more programmers' coding work. I have asked this question to
all Boosters -- see separate email thread.

> As Boost.STM will not solve completly the (-) issues, I'm less motivated to see how the integration works. I will add to my TO BE ANALIZED list.

I understand.

Regards,
Lorenzo