| Re: [eigen] Clang issue on MacOS when the set variable is used in the given data |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen <eigen@xxxxxxxxxxxxxxxxxxx>
- Subject: Re: [eigen] Clang issue on MacOS when the set variable is used in the given data
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Fri, 19 Apr 2013 13:46:50 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=sPrMEKI+0t95qSAOUYt9cPGghFSIZq7PclFwIT7esIs=; b=r2BTGE5P2P2qpPGDFM/i9SVbgG4aKr1ncz52D5uvLOYAOAPdmtr/+uGIAfR3HWZUKr DOXOEGqBxy7XENNzIQ+Rvhl7UEfir0YG6dAePw2/TzlYA3HwHyjbKEeQbauG7DF8oKzM RnieB4pQ5pKApyv6/0q3oYO7nXFyS1GM/4PaGgkJUpv9c+nxRRlSxQybqsb+B8fiVxBi WXmMzKf6bLTUsnmh9MqTy2ThY77zOK7AkcajO65AGw/0aIxaZSmqhgIDOf/dzyQhnlAu FXBtkbBIGRIddp1PhlsT7IbaR4MuVvqp1jNZDtWSeIobsgTQuBkOoXvmmdYPVp+g4GMa 9gJA==
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
> ----------------------------------------------
>
>