[Dune] [Dune-Commit] dune-localfunctions r943 - trunk/dune/localfunctions/test
Jö Fahlke
jorrit at jorrit.de
Tue Jan 4 12:00:32 CET 2011
Am Mon, 3. Jan 2011, 10:07:17 +0100 schrieb Martin Nolte:
> let me get this straight. Your code example shows that the facade
> does not guarantee a method to be present on the implementation just
> because the facade implements it -- granted. But there is a subtle
> difference: Let's assume we would call bar instead of foo in the
> main program of your example. With the facade, the error occurs in
> Facade::bar, while without the facade the error occurs in the main
> program (read: user code). So, with the facade, the user tell the
> difference between an error in his code and an error in the grid
> implementation.
On the other hand, it makes error messages longer, and missing interfaces
should be detected by unit-tests anyway.
> Finally, the incomplete type problem is as follows. When I wrote my
> first DUNE grid, I tried to extract the types from the const Grid
> provided to, e.g., the geometry. This failed due to the grid being
> an incomplete type. Today I know that I have to use remove_const to
> get around this. But the lesson I learned is: Think whether it is
> necessary to extract stuff from a template argument which is not a
> traits class.
I still don't understand. For instance, why is the geometry provided with a
const Grid template parameter?
> Just by the way, I wanted to specialize as follows:
>
> template< int mydim, int cdim, class GridImp, template< int, int, class > Impl >
> struct MyObjectWrapper< Geometry< mydim, cdim, GridImp, Impl > > { ... };
>
> template< int codim, int dim, class GridImp, template< int, int, class > Impl >
> struct MyObjectWrapper< Entity< codim, dim, GridImp, Impl > > { ... };
>
> You can't do this trick without the Facade. But your example of
> specializing over the codimension is a really good one, too.
Ah, OK, I misunderstood you there. Yes, you are right, you need some
provision from the Geometry/Entity to be able to do that, and I guess
Facade classes are one of the better ways to do this. This is the best
argument in favour of them I have heard so far, and it explains why there is a
problem with MockGeometry.
In summary, I am convinced that we need some way to check whether a type is a
geometry, and the Dune::Geometry template is probably as good as any. I am
not yet convinced about the mydim, cdim, and ctype template parameters, but I
regard that as a minor issue. IMO it is most important that we get rid of
Dune::Geometry's GridImp template parameters.
Bye,
Jö.
--
http://www.heise.de/tp/deutsch/inhalt/te/17529/1.html
"Wer nichts zu verbergen hat, kann auch seine echte Emailadresse
angeben." -- Luke321 im Telepolis-Forum
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20110104/cbb3ed0e/attachment.sig>
More information about the Dune
mailing list