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

[Steffen Müthing]

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

-------------- 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/20151012/69ac4846/attachment.sig>