[Dune-devel] [Dune] Reference and pointer type when dereferencing EntityPointer
Steffen Müthing
steffen.muething at iwr.uni-heidelberg.de
Mon Oct 20 11:20:44 CEST 2014
Hi Robert,
Am 20.10.2014 um 11:04 schrieb Robert Kloefkorn <robertk at posteo.de>:
> Hello Steffen,
>
>> yes, maybe I should have put up a vote. On the other hand, I asked about this on
>> the devel list and the only one who answered was Christian. And his answer was
>> basically „Oh, that was probably just a cock-up in the original design, we didn’t
>> know better / correctly think about this back then“.
>
> I don't read the mailing list mails every day. And even if I would I
> sometimes don't have the time to answer right away. For that reason,
> with interface changes, there has to be a grace period. Even though this
> is very frustrating for the developer. Otherwise it can be very
> frustrating for the others.
>
>
>> Yes, I’ll put up votes in the future. That said, is there a good reason to keep the non-const
>> reference? I don’t even think we really have a choice here because entities are now copyable.
>> Think about the following code:
>>
>> Entity& e1 = *it1;
>> Entity& e2 = *it2;
>> e1 = e2;
>
> Christian was right, that this is something from the old times.
> We should change it (as you already did) and now that we have it, we
> should change all code that fails because of this change.
>
>> What does that do to the internal state of it1?
> After your change this should not compile anymore, right?
> I think in the future we want something like
>
> Entity e1 = *it1 ;
> Entity e2 = *it2 ;
That is exactly what we decided to do in Berlin. In the current master, the facade
classes already allow copying entities and intersections, and we probably want
to fix all non-deprecated grids to work with this as well. For all other grids, we need
to make sure that the compiler doesn’t copy any implementation classes that do not
do a deep copy, but see FS#1511 for that discussion.
>
> Then e1 = e2 makes sense again. For grids like UGGrid or ALUGrid, where
> the Entity class carries a lot of information this can still be
> implemented via a proxy class and some smart allocation/deallocation of
> Entity objects.
That extra cost is certainly a problem, but I think the problem can be alleviated by returning
a const ref to an Entity when dereferencing the facade classes. That way, each implementation
can decide whether to return a temporary object (if creating / copying an entity is cheap) or a
const reference to an object that is stored inside the iterator (if Entity objects are large / expensive).
Steffen
>
> Best,
>
> Robert
>
-------------- 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/20141020/0bada425/attachment.sig>
More information about the Dune-devel
mailing list