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.
_______________________________________________
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
