[dune-functions] [Dune-functions-commit] [Commit] dune-functions - 3979792: Add helper to directly access the type of nested children

[Carsten Gräser]

Hi,

Am 11.09.2015 um 14:07 schrieb Steffen Müthing:
[...]
> I don’t like that idea, because it’s not clear what to specialize for, in particular
> it’s not clear what to use for the type of the integral_constant. You’ve used int,
> but typetree always uses std::size_t internally. That might create ugly surprises for
> people… By really having fixed_index as a separate type, we make it much clearer
> that the index type is part of the interface. And I *want* people to specialize / overload
> using fixed_index because it increases code readability quite a bit.
I don't why we need a typetree-specific type for static indices.
For dynamic indices we use classic types as well and don't derive
from them. From this perspective an alias seems to be more readable.
You can then still use the alias in a specialization. And the alias
would also fix int/size_t. IMHO

  template<std::size_t i>
  using fixed_index = std::integral_constant<std::size_type, i>;

is the least surprising solution. In view of std::index_sequence
we could also call it index_constant.

[...]
> Yes, it’s a special case, and there are different trade-offs. When traversing a tree
> using typetree’s applyToTree() algorithm, it is possible to choose between having a
> fully dynamic or a fully static TreePath (the algorithm can do that because the TreePath
> is generated during the tree traversal, and if you want a fully static index, it will just use
> a TMP instead of a run time loop for PowerNode.
> 
> There are different approaches for this, but I think it is important to keep the invariant
> that all children of a PowerNode have the exact same type because it reduces code size
> and makes iteration easier for stuff like a Navier-Stokes assembler that can simply loop
> over the children with a for loop. If you absolutely need the static index (from my experience,
> you rarely do outside of some visitors, which have the information available anyway), use
> a CompositeNode.
> 
> TL;DR: I also want to keep the status quo, even though it means having to ship around those
> TreePath (on the other hand, that only happens once during construction anyway).
Then let's just keep it as it is, clean and simple. Passing the
TreePath around is really no issue - you just pass it to the
node constructors.

Carsten


-- 
Prof. Dr. Carsten Gräser
Freie Universität Berlin
Institut für Mathematik
Arnimallee 6
14195 Berlin, Germany
phone: +49 30 838 72637
fax  : +49 30 838 472637
email: graeser at mi.fu-berlin.de
URL  : http://page.mi.fu-berlin.de/graeser

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dune-project.org/pipermail/dune-functions/attachments/20150911/0d55cbf0/attachment.sig>