[Dune-devel] Reference and pointer type when dereferencing EntityPointer

[Steffen Müthing]

Hi Markus,

Am 20.10.2014 um 11:36 schrieb Markus Blatt <markus at dr-blatt.de>:

> On Tue, Oct 14, 2014 at 01:25:20PM +0200, Steffen Müthing wrote:
>> 
>> Am 14.10.2014 um 10:05 schrieb Christian Engwer <christian.engwer at uni-muenster.de>:
>> 
>>> Hi Steffen,
>>> 
>>>> to my rather big surprise I just learned that operator* and operator-> in the EntityPointer facade
>>>> have always returned the Entity by non-const reference / pointer. It has been like that pretty much
>>>> forever (those lines were last changed in 2005!).
>>> 
>>> I'm tempted to say that is due to our limited C++ experience in the
>>> older days... The entity had only const methods, so at the first glace
>>> one solution was as good as the other. And obviously nobody every
>>> properly looked at it after the first couple of years.
>> 
>> OK, in that case I propose making those return types const. If nobody cries foul until
>> tomorrow, I’ll push the change.
> 
> Why not yesterday instead of tomorrow? I was not online for one week,
> therefore it would have not mattered anyway. :/
> 
> Being back I am yelling now! Moving from a mutable return type to a
> const one is disruptive and tends to break user code.

as I said, I’m sorry that I didn’t wait any longer with this - and I’ll make sure to always put out a
vote in the future.

But as I already explained in my response to Robert, in this case I don’t think the issue is even
something to vote on, but a bug fix in the interface that is a direct consequence of our decision
to have copyable entities in DUNE 2.4. We don’t want a user to be able to do this by accident:

Entity& e1 = *it1;
Entity& e2 = *it2;
e1 = e2;

This wasn’t possible before (because the facades prohibited copying), but it will work now, and it’s
something that can easily happen when people start to use the copyable entities (convert existing
const Entity& and forget about the trailing „&“), and the resulting bugs would be a PITA to debug.

Yes, it’s unfortunate that the fix breaks existing code, but there just isn’t a „nice“ way in this case. OTOH,
it breaks in a predictable way (compilation error) and can easily be fixed. That’s not the case in the scenario
I described above (well, the fix is easy, but diagnosing the problem isn’t). The fundamental problem is that
entities used to have only const methods, so it didn’t matter whether the returned reference was const or not.
By making entities copyable, we have given them non-const methods, so leaking out a non-const reference to
the user has become a *really* bad idea.

Again, is this really such a big deal? I haven’t stumbled across any code that captured by non-const Entity…

Steffen


> 
> Markus
> 
> 
> -- 
> Do you need more support with DUNE or HPC in general? 
> 
> Dr. Markus Blatt - HPC-Simulation-Software & Services http://www.dr-blatt.de
> Hans-Bunte-Str. 8-10, 69123 Heidelberg, Germany
> Tel.: +49 (0) 160 97590858
> _______________________________________________
> 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/20141020/afd246ab/attachment.sig>