[Dune-devel] Dereferencing an iterator post 2.4.

[Steffen Müthing]

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/c09e2a38/attachment.sig>