[Dune] 'auto&&' or 'const auto&' ?

Steffen Müthing steffen.muething at iwr.uni-heidelberg.de
Tue Oct 13 11:28:27 CEST 2015 

Hi Bernd,

> Am 13.10.2015 um 10:50 schrieb Bernd Flemisch <bernd at iws.uni-stuttgart.de>:
> 
> Hi Steffen,
> 
> I just tried at one occasion with 'auto&&' and gcc-5. It worked and didn't trigger the error, although it was inside a function template. Does that mean that it will also work for other users/compiler versions or when I make changes in the future?

It’s tricky: It works correctly for some grids, but fails for others (depending on what the grid returns). The MWE posted in the
GCC bug fails on GCC 4.9, GCC 5 and the current prerelease builds of GCC 6.

For now, there is really no other choice than const auto& if you want your code to be robust.

Steffen


> 
> Kind regards
> Bernd
> 
> On 10/12/2015 06:03 PM, Steffen Müthing wrote:
>> Hi Atgeirr,
>> 
>> 
>>> Am 12.10.2015 um 17:16 schrieb Atgeirr Rasmussen <Atgeirr.Rasmussen at sintef.no>
>>> :
>>> 
>>> Hi Dune,
>>> 
>>> I am curious about why you require auto&& (starting with Dune 2.4 according to the web site)?
>>> Are the iterators using proxy objects?
>>> 
>> It’s not actually proxy objects, but some grids (typically structured ones like YaspGrid) might just create
>> a temporary entity every time they are dereferenced. There were some discussions about this topic
>> (whether to have grid iterators always return a temporary or always return a const ref to an internally
>> cached entity). In the end we decided to allow for both (one is good for unstructured grids, one is good for
>> structured grids).
>> 
>> 
>>> For general range-for loops I am not sure how I could get const-ness of these (const auto&& would
>>> not be a universal const-reference would it)? I usually prefer to make my objects const if possible
>>> (to prevent myself from making errors), but the auto&& will enable me to modify the range, unless
>>> the range itself is const.
>>> 
>> You’re right, const auto&& is something else. auto&& always deduces to the right thing: It creates a variable
>> of type const Entity& if the iterator returns a const ref, and a variable of type Entity if the returned value is
>> a temporary (that variable will typically directly be initialized inside the operator* due to RVO and copy elision).
>> 
>> As I said, in our case we are fine w.r.t. to constness, as we either require the iterator to return a const ref or
>> a temporary. Using const auto& has some subtle performance implications in certain cases, see the discussion
>> in FS1511 for all the gory details…
>> 
>> Steffen
>> 
>> 
>>> Atgeirr
>>> 
>>> 
>>> 
>>> 
>>>> 12. okt. 2015 kl. 16.22 skrev Steffen Müthing <steffen.muething at iwr.uni-heidelberg.de>
>>>> :
>>>> 
>>>> Hi Bernd,
>>>> 
>>>> 
>>>>> Am 12.10.2015 um 15:50 schrieb Bernd Flemisch <bernd at iws.uni-stuttgart.de>
>>>>> :
>>>>> 
>>>>> Dear Dune,
>>>>> 
>>>>> should I use 'auto&&' or 'const auto&' in a range-based for-loop over the entities of a Dune GridView?
>>>>> 
>>>>> On the one hand, there is
>>>>> 
>>>>> https://www.dune-project.org/doc/doxygen/html/group__GIIteration.html#_details
>>>>> 
>>>>> which says "**always** use 'auto&&'"
>>>>> 
>>>>> On the other hand, there is
>>>>> 
>>>>> http://conan2.iwr.uni-heidelberg.de/git/pdelab/dune-pdelab/commit/d97c563807cd4f9aaa872dfee57c668eda12db59
>>>>> 
>>>>> together with
>>>>> 
>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63506
>>>>> 
>>>>> which indicates that a GCC bug is triggered when using 'auto&&‘.
>>>>> 
>>>> yes, it’s all quite a mess: Basically, the standard (and important people like Stroustrup and Sutter) say that you
>>>> should *always* use auto&& in a range-based for loop, but GCC has this bug that sometimes causes a compilation
>>>> failure if the range-based for appears inside a function template, so you have to use const auto&.
>>>> 
>>>> So, the (rather unfortunate) advice is: You should use auto&&, but you can’t if you target current GCC due to a bug in
>>>> GCC. In that case, you have to use const auto&.
>>>> 
>>>> We should probably update the Doxygen documentation to explain the issue (I forgot about that when I discovered the compiler
>>>> b) because we’ll be stuck with the problem for the foreseeable future - the bug is still present in the GCC 6 snapshot from
>>>> the beginning of September that I have available on my machine, and the GCC Bugzilla bug hasn’t seen any attention in a long
>>>> time. Apart from that, the bug is in GCC 5, which we will have to support for a few years to come…
>>>> 
>>>> So I think the documentation needs to explain this issue.
>>>> 
>>>> Steffen
>>>> 
>>>> 
>>>>> Kind regards
>>>>> Bernd
>>>>> 
>>>>> --
>>>>> _______________________________________________________________
>>>>> 
>>>>> Bernd Flemisch                         phone: +49 711 685 69162
>>>>> IWS, Universität Stuttgart             fax:   +49 711 685 60430
>>>>> Pfaffenwaldring 61
>>>>> email:bernd at iws.uni-stuttgart.de
>>>>> 
>>>>> D-70569 Stuttgart            url:www.hydrosys.uni-stuttgart.de
>>>>> _______________________________________________________________
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Dune mailing list
>>>>> 
>>>>> Dune at dune-project.org
>>>>> http://lists.dune-project.org/mailman/listinfo/dune
>>>>> 
>>>>> 
>>>>> 
>>>> _______________________________________________
>>>> Dune mailing list
>>>> 
>>>> Dune at dune-project.org
>>>> http://lists.dune-project.org/mailman/listinfo/dune
>>> _______________________________________________
>>> Dune mailing list
>>> 
>>> Dune at dune-project.org
>>> http://lists.dune-project.org/mailman/listinfo/dune
>> 
>> 
>> _______________________________________________
>> Dune mailing list
>> 
>> Dune at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune
> 
> 
> --
> _______________________________________________________________
> 
> Bernd Flemisch                         phone: +49 711 685 69162
> IWS, Universität Stuttgart             fax:   +49 711 685 60430
> Pfaffenwaldring 61            email:
> bernd at iws.uni-stuttgart.de
> 
> D-70569 Stuttgart            url:
> www.hydrosys.uni-stuttgart.de
> 
> _______________________________________________________________
> 
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20151013/cf035a76/attachment.sig>

More information about the Dune mailing list