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

[Oliver Sander]

Hi,
I have yet to see a convincing example where using const auto& incurs a performance penalty.
I prefer using const whenever possible, to make it clear to the reader that the loop will
not modify the container.
Best,
Oliver

Am 13.10.2015 um 10:50 schrieb Bernd Flemisch:
> 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?
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
>