<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Steffen,<br>
thanks for all the work. Any simplifications to dune-typetree are
always much appreciated. :-)<br>
<br>
Am 15.09.2015 um 17:54 schrieb Steffen Müthing:<br>
</div>
<br>
<blockquote
cite="mid:6812900F-599D-4E85-8634-DA5B9BC57575@iwr.uni-heidelberg.de"
type="cite">
<pre wrap="">
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).</pre>
</blockquote>
Why can't we simply fix that? We claim that stuff in Dune::Std is
standard-compliant, so what<br>
you describe is a simple bug that should be fixed. We may advertise
this beforehand to warn<br>
people about the behavioral changes, but still... isn't this simply
a bug that needs fixing?<br>
<br>
<br>
<blockquote
cite="mid:6812900F-599D-4E85-8634-DA5B9BC57575@iwr.uni-heidelberg.de"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
Seconded -- then I could use them for MultiTypeBlockVector.<br>
<br>
Nitpicking: wouldn't constant_index be a better name than
index_constant?<br>
(I won't even try to enforce 'standard Dune' camelCase with you :-)
)<br>
<br>
<blockquote
cite="mid:6812900F-599D-4E85-8634-DA5B9BC57575@iwr.uni-heidelberg.de"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
Please enlighten me: why do we need the distinction between a
TreePath and a HybridTreePath?<br>
Isn't a fully static path simply a special case of HybridTreePath?<br>
<br>
Best,<br>
Oliver<br>
<br>
<br>
<blockquote
cite="mid:6812900F-599D-4E85-8634-DA5B9BC57575@iwr.uni-heidelberg.de"
type="cite">
<pre wrap="">
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
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
dune-functions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dune-functions@dune-project.org">dune-functions@dune-project.org</a>
<a class="moz-txt-link-freetext" href="http://lists.dune-project.org/mailman/listinfo/dune-functions">http://lists.dune-project.org/mailman/listinfo/dune-functions</a>
</pre>
</blockquote>
<br>
</body>
</html>