[Dune-devel] Dereferencing an iterator post 2.4.

[Steffen Müthing]

PS: We should put this somewhere more permanent, either in the 2.4 release notes or on the wiki.


> Am 08.06.2015 um 17:10 schrieb Steffen Müthing <steffen.muething at iwr.uni-heidelberg.de>:
> 
> Hi everyone,
> 
> 
>> Am 08.06.2015 um 11:12 schrieb Carsten Gräser <graeser at mi.fu-Berlin.de>:
>> 
>> Dear all,
>> may I point your attention to this question recently asked by Jonathan:
>> 
>> Am 29.05.2015 um 10:57 schrieb Jonathan Youett:>
>>> I am currently adjusting a meta grid to 'future 2.4'. In the 2.4 release
>>> notes it says
>>> 
>>> 'Iterators are now allowed to return temporary Entity or Intersection
>>> objects instead of references'
>>> 
>>> Is it already specified what the return type will be after the
>>> transition phase e.g. in 3.0? Or will it always stay grid-dependent?
> 
> I just saw this right now (was on vacation last week). As I did most of the work
> related to this change, I’m probably the natural person to answer this…
> 
> The answers are hidden in the (unfortunately rather long and convoluted) FS#1511
> at https://dune-project.org/flyspray/index.php?do=details&task_id=1511.
> 
> The gist of it is the following (at least that’s how I ported the meta grids in dune-grid
> and MultiDomainGrid):
> 
> - *All* grid managers should be ported to the new interface ASAP
> - Existing user code is still expected to work unchanged on top of Dune 2.4, albeit
>  with a torrent of deprecation warnings
> - Importantly for Jonathan’s question, meta grids are an exception: A meta grid may
>  (and usually will) be ported in such a way that it only works with grids that offer the new
>  interface. That’s the current state of IdentityGrid, GeometryGrid and MultiDomainGrid:
>  You cannot use those grids on top of an unported host grid. The main reason is that copyable
>  entities and intersections greatly simplify the internals of meta grids, and if you want to exploit
>  these changes, there is no way (at least I didn’t find one) to do so in a backwards-compatible
>  fashion.
> - The decision about temporaries vs. const refs was deliberately postponed because
>  there are good reasons for both alternatives: Meta grids really benefit from being able to return
>  temporaries (because it frees them from the responsibility of keeping internal state, i.e. the object
>  pointed at by the returned const ref), while grid managers with heavy-weight entities might want
>  to avoid copying internal state that is available anyway every time an iterator is dereferenced.
>  To the user, this is mostly transparent: The policy was supposed to be this:
>  - If you need to keep an entity or intersection around for any reason (e.g. as a member variable),
>    *always* make a copy.
>  - Loops should be based on range-based for and optimally use auto&& for
>    the loop variable type, but that doesn’t work right now due to a GCC bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63506)
>  So, TLDR: That decision hasn’t been made yet, but returning a const ref is considered an implementation
>  detail for optimization purposes.
> 
> For someone writing a meta grid (like Jonathan), the first case above applies, so you have to copy
> the object anyway, and for that purpose, it doesn’t matter whether the host grid returns a temporary
> or a const ref.
> 
>> 
>> By producing all the deprecation warnings in 2.4 we clearly state that
>> user code and 3rd party grid managers have to be adjusted.
>> But we do not clearly state in which direction this has to be done.
>> This does especially include the answer to this question.
>> 
>> Another question, that was IMO never discussed is, if we also
>> allow to return copies of EntityImp instead of Entity. Currently
>> the compatibility code in the interface enforces that this is
>> not OK (altough it could be adjusted accordingly). But once the
>> code is removed, it may compile and work perfectly.
> 
> You’re right, this was never discussed. I had to enforce the Entity return type to work around some problems
> with the interface compatibility layer on GCC 4.4. So for 2.4 at least, we definitely require grid writers to return
> an interface object.
> 
> I hope this answers most of the questions…
> 
> Cheers,
> Steffen
> 
>> 
>> In my opinion we should sort these kind of things out to give
>> (meta-)grid developers a clear perspective. And it would be best
>> to do this before the release.
>> 
>> Best,
>> Carsten
>> 
>> _______________________________________________
>> Dune-devel mailing list
>> Dune-devel at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune-devel
> 

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