Proto for Boost mailing list page: Re: [proto] Default constructor of proto::extends

Subject: Re: [proto] Default constructor of proto::extends
From: Antoine de Maricourt (antoine.de-maricourt_at_[hidden])
Date: 2011-02-07 14:33:35

>> Hi Eric,
>>
>> is there any reason why the default ctor of proto::extends uses the
>> following form:
>>
>>    extends()
>>       : proto_expr_()
>>    {}
>>
>> instead of simply
>>
>>    extends() {}
>>
>> I use proto::extends over expressions that hold x86 SIMD registers (like
>> proto::terminal<__m128i>),  and the current version of proto::extends
>> default ctor yields to a __m128i() call,  which fills the register with
>> zeros, while I wanted to keep it uninitialized.
>>
>> Apparently the compiler (g++, 4.6 and previous versions as well) is
>> enable to detect this is unneeded, as the register is in fact
>> initialized a few instructions later, and the only way I was able to get
>> rid of this was to remove the explicit call to proto_expr_ ctor in the
>> extends ctor.
> You could use BOOST_PROTO_EXTENDS instead of proto::extends. I'm a
> little uncomfortable with a base class that leaves members in an
> undefined state, but I'm willing to consider it. Feel free to file a
> bug. Thanks.

I would say that, since this member is in fact the expr to be extended, 
provided by the derived class, it is up to the derived class to decide 
if it is acceptable to leave it undefined, and to make sure the base 
class default ctor is not called if leaving this member undefined is not 
acceptable, or to make sure the expr has an adequate default ctor. From 
what I understood so far, extends is here to extend expr's behaviour, 
not to modify it by forcing expr initialization if expr has a ctor that 
can leave it uninitialized.

Regards,

     Antoine.