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

[Arnaud BARRE <arnaud.barre@xxxxxxxxx>]

>With Eigen's _expression_ template this makes it a little bit more subtle. For instance:
>A << ...., A.block(...) + B, ....;
> ...

So, as a best practice rule, is it better to use comma initialization only with constant values?

And in other case, like mine, It is better to use the segment() or block() method? I never knew wich one is the best (in term of code instruction).

Arnaud

On Fri, Apr 19, 2013 at 1:46 PM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

OK thank you for the finding. I'll add this note in the doc.

With Eigen's _expression_ template this makes it a little bit more
subtle. For instance:

A << ...., A.block(...) + B, ....;

as a well defined behavior, this is the first "...." will be entirely
executed before A.block(...) + B gets evaluated, but:

A << ...., (A.block(...) + B).eval(), ....;

does not!


gael

On Fri, Apr 19, 2013 at 1:33 PM, Christoph Hertzberg

<chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> 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
> ----------------------------------------------
>
>