[Dune] Comments on Dune Developer Meeting 2014.

[Martin Nolte]

Hi Robert,

the helper construct basically looks like this:

struct EntityPointer
{
   EntityPointer ( const Entity &entity )
     : entity_( entity )
   {}

   Entity *operator-> () const { return &entity_; }

   Entity entity_;
};

I presume we will add more pointer functionality, a bit of move semantics, 
make implementation details private, and possible use another name, but 
basically this is it.

Is that thing really so fishy?

Best,

Martin


On 09/25/2014 05:43 PM, Robert Kloefkorn wrote:
> Hi Jö,
>                                                              The reason
>>> for that is, that a DUNE grid (in my opinion) is not a container. One
>>> reason is, that the Entity is a proxy class and not a real object.
>>
>> I don't understand how "'it->' must be slower than '(*it).'" follows from
>> that (if that is what meant).
>
> my statement was referring to the protocol on the topic "EntityPointer's
> future". The statement was:
>
> In order to have operator-> work, a helper object should be provided by
> the facade infrastructure.
>
> Sounds fishy to me. And fishy most likely is not what we want.
> Especially, since operator-> is not really needed.
>
> If the documentation is the problem, we can make it clear that
> EntityIterators behave like forward_iterators except for the missing
> postfix and operator->. At least that makes it clear without the
> mickeymousing suggested in the protocol (see above).
>
> Best,
>
> Rob
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
>

-- 
Dr. Martin Nolte <nolte at mathematik.uni-freiburg.de>

Universität Freiburg                                   phone: +49-761-203-5630
Abteilung für angewandte Mathematik                    fax:   +49-761-203-5632
Hermann-Herder-Straße 10
79104 Freiburg, Germany