[Dune-devel] Dereferencing an iterator post 2.4.
steffen.muething at iwr.uni-heidelberg.de
Mon Jun 8 16:11:16 CEST 2015
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
> - 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…
>> 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.
>> Dune-devel mailing list
>> Dune-devel at dune-project.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Dune-devel