[Dune-devel] Dereferencing an iterator post 2.4.

[Christian Engwer]

On Mon, Jun 08, 2015 at 05:11:16PM +0300, Steffen Müthing wrote:
> PS: We should put this somewhere more permanent, either in the 2.4 release notes or on the wiki.

I'd suggest the release notes and a supplement to the meeting minutes.

> > 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
> > 
> 



> _______________________________________________
> Dune-devel mailing list
> Dune-devel at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-devel


-- 
Prof. Dr. Christian Engwer 
Institut für Numerische und Angewandte Mathematik
Fachbereich Mathematik und Informatik der Universität Münster
Einsteinstrasse 62
48149 Münster

E-Mail	christian.engwer at uni-muenster.de
Telefon	+49 251 83-35067
FAX		+49 251 83-32729