Boost logo

Boost :

Subject: Re: [boost] [contract] member initializers (was "diff n1962")
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-04-19 12:48:33

----- Original Message -----
From: "Lorenzo Caminiti" <lorcaminiti_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, April 14, 2010 10:43 PM
Subject: Re: [boost] [contract] member initializers (was "diff n1962")

On Sun, Apr 11, 2010 at 10:58 AM, vicente.botet
<vicente.botet_at_[hidden]> wrote:
> 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.
> 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, "pre > base-init > member-init" will require to mess with the
inheritance tree and I do not see how that can be done by the
CONTRACT_CONSTRUCTOR() macro which is used at the constructor
declaration level (so inside the class and after its inheritance
declarations). However, special member variables could be used to
implement "base-init > pre > member-init" (as indicated below).

Do you think it is worth implementing "base-init > pre > member-init"
instead of "base-init > member-init > pre"?



I think all the stuff needed to implement it is more confusing than useful. At the end what is the real problem with base-init > member-init > pre?
Vicente Juan Botet Escribá

Boost list run by bdawes at, gregod at, cpdaniel at, john at