----- Original Message ----- From: "Lorenzo Caminiti" <lorcaminiti@gmail.com> To: <boost@lists.boost.org> 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@wanadoo.fr> 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"? __________________________________________________________________ Hi, 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? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/