Re: [eigen] Clang issue on MacOS when the set variable is used in the given data

[Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>]

On 19.04.2013 13:23, Christoph Hertzberg wrote:
> On 19.04.2013 13:14, Gael Guennebaud wrote:
> > On Fri, Apr 19, 2013 at 12:53 PM, Christoph Hertzberg
> > <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> > > I always assumed that
> > >    foo << A, B, C;
> > > is basically the same as
> > >    foo.segment<dim_A>(0          ) = A;
> > >    foo.segment<dim_B>(dim_A      ) = B;
> > >    foo.segment<dim_C>(dim_A+dim_B) = C;
> >
> > yes, in theory it's what happen in that order. but in that case
> > Arnaud's 1st example should fail regardless on the compiler. So there
> > might a c++ subtlety I'm missing.
>
> I assume the compiler does some over-optimization here, i.e., loads
> values of foo and starts evaluating the product before beginning to
> write to foo. I don't know if that kind of optimization is allowed by
> the C++ standard (it would not surprise me if it was).

I just found this:
> However, an invocation of an overloaded comma operator is an ordinary function call; hence, *the evaluations of its argument expressions are unsequenced* relative to one another (see 1.9).
as an answer here:
http://stackoverflow.com/questions/7784774/is-comma-operator-free-from-side-effect
So it seems there is no guarantee on the evaluation order for overloaded 
comma operators.

Christoph



--
----------------------------------------------
Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
Cartesium 0.049
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen

Tel: +49 (421) 218-64252
----------------------------------------------