[dune-functions] TypeTree now works with dune-functions again

Oliver Sander oliver.sander at tu-dresden.de
Tue Sep 15 20:54:35 CEST 2015


Hi Steffen,
thanks for all the work.  Any simplifications to dune-typetree are always much appreciated. :-)

Am 15.09.2015 um 17:54 schrieb Steffen Müthing:

>
> I also really liked Carsten’s idea of having an index_constant that’s a template alias for an
> integral_constant<std::size_t,…>, so I put that into TypeTree and started to use it extensively. There’s
> also a standard-compliant reimplementation of the integer_range and index_range functionality in
> Dune::TypeTree::Std (BTW, it’s *really* bad that we have something not quite correct in Dune::Std).
Why can't we simply fix that?  We claim that stuff in Dune::Std is standard-compliant, so what
you describe is a simple bug that should be fixed.  We may advertise this beforehand to warn
people about the behavioral changes, but still... isn't this simply a bug that needs fixing?


>
> The pre-made index objects now live in Dune::TypeTree::Indices (I thought the „Static“ was a little redundant).
> I really like the idea of those constants and would like to see them in dune-common after the release of 2.4.
Seconded -- then I could use them for MultiTypeBlockVector.

Nitpicking: wouldn't constant_index be a better name than index_constant?
(I won't even try to enforce 'standard Dune' camelCase with you :-) )

>
> There is now a new API for accessing children in TypeTree: to get a child, just write
>
> Dune::TypeTree::child(node,indices...);
>
> Indices can be either a combination of std::size_t and index_constant, a TreePath (fully static) or a HybridTreePath.
Please enlighten me: why do we need the distinction between a TreePath and a HybridTreePath?
Isn't a fully static path simply a special case of HybridTreePath?

Best,
Oliver


> For convenience (to avoid having to qualify child() all the time), there are also new member functions, so you
> can also write
>
> node.child(indices…);
>
> Beware: Doing so is problematic in generic code that expects to call node.child(treePath) with an empty TreePath
> on a leaf node. That only works with the freestanding function - the member function cannot specify the correct
> return type in that case. So generic code (like the stuff in defaultnodetorangemap.hh) will have to use the freestanding
> functions.
>
> The type of a child can be extracted using one of two template aliases:
>
> using ChildType = Dune::TypeTree::Child<Node,0,3,_2>; // this accepts both integer literals and the predefined index_constants
> using ChildType = Dune::TypeTree::ChildForTreePath<Node,TreePath>; // the path can be either TreePath or HybridTreePath
>
> I quite like the way it works now, but if you have any suggestions for improvements, shoot!
>
> Steffen
>
>
> _______________________________________________
> dune-functions mailing list
> dune-functions at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-functions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-functions/attachments/20150915/d9c91409/attachment.htm>


More information about the dune-functions mailing list