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

Bernd Flemisch bernd at iws.uni-stuttgart.de
Wed Oct 14 09:25:09 CEST 2015 

Ok, so 'const auto&' it is. Until it will be fixed in GCC 7 and that 
becomes the minimum required compiler...

Thank you for your answers. And of course for the range-for-loops, those 
parts look really nicer now.

Bernd

On 10/13/2015 11:28 AM, Steffen Müthing wrote:
> 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


-- 
_______________________________________________________________

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
_______________________________________________________________

More information about the Dune mailing list