Re: [boost] [contract] diff n1962

Subject: Re: [boost] [contract] diff n1962
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2010-04-12 21:07:32

On Mon, Apr 12, 2010 at 7:05 AM, Thorsten Ottosen <nesotto_at_[hidden]> wrote:
> Lorenzo Caminiti skrev:
>>
>> CONSTRUCTORS
>> Does n1962 require constructor preconditions to be checked before or
>> after the execution of the member initialization list?
>
> Maybe the paper is not as clear as it could be, but the intend is *before*
> the member initializer list.
>
> -Thorsten

OK. I will probably end up documenting member-init > pre > ... as a
limitation of Boost.Contract because I do not think I will be able to
implement pre > member-init > ...

On Sun, Apr 11, 2010 at 10:58 AM, vicente.botet
<vicente.botet_at_[hidden]> wrote:
> From: "Lorenzo Caminiti" <lorcaminiti_at_[hidden]>
> CONSTRUCTORS
> Does n1962 require constructor preconditions to be checked before or
> after the execution of the member initialization list?
>
> Hi Lorenzo,
> I supose that the constructor preconditions are evaluated before the  member initialization as this initialization can rely on the preconditions been satisfied. Note also that preconditions/postconditions must to be in the declaration part, and the member initialization is on the definition part.

Indeed this is exactly why Boost.Contract has the limitation that when
member initialization list is used, the constructor definition needs
to appear together with the contract specification in the class
declaration.

> I understand that it is not easy for Boost.Contract to check the precondition before member initialization . To be able to do that you will need to have a first member or inherit from a 'precondition' class that do this precondition check,
>
> class C : C_constructor_precondition ... {
>
>  C(T1 p1) : C_constructor_precondition(p1), ... {
>    // ...
>  }
> };
>
> but this seems to me a severe constraint and adds more complexity. I think that I can live with preconditions check after member initialization.

Yes, this is also the _only_ option I could see to implement pre>
member-init. I have experimented with it in the past and, as you
indicate, it has significant problems:
1) I messes up with the inheritance tree (minor issue).
2) The precondition assertions are known where the constructor is
specified but now they also need to be known by
C_constructor_precondition -- how can this be done??
3) Things get even more complex when considering multiple constructors
with different arguments and different precondition assertions -- this
will probably require to use different
C_constructor_precondition_arg1, C_constructor_precondition_arg2, etc
base classes -- but what would constructor(arg1) do with
C_constructor_precondition_arg2??
4) How do you wrap all of these within a single CONTRACT_CONSTRUCTOR() macro??

I have also experimented with using special member variables instead
of base classes:

    class C: B {
        C(T1 p1): B(p1),  c_p1_pre_(p1), ... { ... };
        struct C_p1_pre_ { C_p1_pre_(T1 p1) { ASSERT(...); } } c_p1_pre_;
        ...
    };

But this way the preconditions are not checked before the base classes
B(p1) are constructed which is not acceptable (plus how to I know if
B(p1) is a same init or a member init so to inject c_p1_pre_(p1) in
the right place?). (*)

The advantage of this would be that struct can be defined by
CONTRACT_CONSTRUCT() expansion. For multiple constructors, perhaps
providing a default constructor to C_p1_pre_ that asserts nothing
would allow other constructors not to worry about each others
preconditions... However, I do not think (*) is acceptable so I
stopped looking into this.

I essentially gave up on trying to implement pre > member-init. While
I now understand that member-init > pre is not ideal, I did not find
this limitation relevant in practice when using Boost.Contract to
program the examples and my ~60k lines of C++ project.

(I wondered if delegating constructors could help, but I have not
really looked into it.)

Thanks,
Lorenzo