[Dune] dune-grid does not compile when implementations of EntityPointer and Iterator are not interoperable

[Martin Nolte]

Hi Steffen,

you are right, the cast operator is indeed deprecated in the 2.1 release 
branch. This would mean it should be gone by now. Unfortunately, we are close 
to a release and I would ask the release managers whether such a change would 
still be in order. Is anybody still using the deprecated cast operator?

For the casting problem, you might want to have a look at GeometryGrid's 
entity pointer (see dune/grid/geometrygrid/entitypointer.hh). Here, the entity 
pointer stores the host iterator (which could, e.g., be a leaf iterator). You 
can then derive your iterator from the entity pointer (with the correct 
iterator passed as template argument) and, thus, satisfy the interoperability 
desired by Dune::EntityPointer. Of course, this trick has some consequences:
(a) There is no guarantee that the code will work
     (but that holds for the cast in Dune::EntityPointer as well).
(b) The last member of your entity pointer must be the host iterator
     (which is the one actually casted by the reinterpret_cast).
Apart from that, the code seems to work wonderfully. I have to admit, though, 
that I never use the deprecated cast operator in my code.

Best,

Martin

On 04/27/2012 12:08 PM, Steffen Müthing wrote:
> Hi Dune,
>
> I just noticed that it is not possible to have non-interoperable implementations of EntityPointer and any
> of the iterators - doing so will make the compiler choke on the deprecated EntityPointer reference cast.
>
> I stumbled over the problem when I forcibly disabled the interoperability (by specializing EnableIfInteroperable)
> to debug an issue in MultiDomainGrid. I was able to make fix the issue (see attached patch), but from the wording
> in entitypointer.hh, I really don't know whether or not the compilation is expected to fail for non-interoperable
> implementations (as some kind of compile-time safeguard).
>
> That said, being able to disable the possibility to do the reference cast would really simplify the MultiDomainGrid
> code quite a bit in a number of places - right now I have the problem that the cast matches rather greedily and I have to
> provide pretty elaborate template specializations of constructors and other stuff to work around that.
>
> So, is this intended behavior or should we fix it? Or do we throw out the reference cast for the new release (it was deprecated
> in 2.1)?
>
> Best,
>
> Steffen
>
>
> PS: In order to fix the problem, I had to do some trickery with the cast operator - it can't be disabled using SFINAE, because the return
> type *is* the function name. So I did a less than pretty hack and just made it convert to void if the cast is disabled (a marker type like
> InvalidCast or something might be nicer).
>
>
>
>
>
> Steffen Müthing
> Universität Stuttgart
> Institut für Parallele und Verteilte Systeme
> Universitätsstr. 38
> 70569 Stuttgart
> Tel: +49 711 685 88429
> Fax: +49 711 685 88340
> Email: steffen.muething at ipvs.uni-stuttgart.de
>
>
>
>
>
>
>
> _______________________________________________
> 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