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

[Carsten Gräser]

Am 10.09.2015 um 14:56 schrieb Steffen Müthing:
> Hi,
>
>
>> Am 10.09.2015 um 00:01 schrieb Carsten Gräser <graeser at mi.fu-Berlin.de>:
>>
>> Am 09.09.2015 um 23:32 schrieb Christian Engwer:
>>> shouldn't parts of these changes go to typetree?
>> Yes, of course. This is true for most stuff in this header, but:
>>
>> a) I'm not sure, if I have write access.
>> b) I'd like to discuss this with Steffen before.
>
> sorry for replying a little late…
No problem.
>
>> c) I can imagine that typetree already contains such functionality
>>   and I just don't know where to find and how to use it.
>>
>
>
> There is already something like ChildType in typetree, but its
interface is a little less pretty. I finished
> implementing the nice child(node,_1,3,_4,…) syntax yesterday (adding
the SFINAE safeguards tripled
> the size of the implementation), and that turns ChildType into a
simple template alias to a decltype. I’ll
> put that into typetree and push it as soon as I’ve written the
documentation.
Sound's nice.

> I had to discover that while I implemented a hybrid TreePath, it was
never used and thus kind of ugly.
> I’ll clean that up and put it into the implementation of dune-functions.
>
> @Carsten: My implementation is basically built around a std::tuple as
well, I just don’t use std::integral_constant
> directly, but an inherited type fixed_index. Those types are also used
for the fixed indices in the child method
> (_1,_2), and when overloading those things, it’s just clearer to write
fixed_index<i> instead of integral_constant<std::size_t,i>.
> The Path itself also inherits from std::tuple, again mostly because it
is clearer for anyone who has to read the code.
Shouldn't we then still use plain integral_constant and make
fixed_index a template alias. Seems to be cleaner and less
surprising. For a type describing a static int, the user will
expect integral_constant. If he tries to specialize for this
it will not work.

> There is also a function in TypeTree that takes a TreePath and gets
the corresponding child (but I’ll make that
> forward to the new child method…).

I found one more thing that we could perhaps improve: Originally I
thought that a PowerNode has a dynamic number of children. But that's
not true. Hence we could describe the TreePath in a completely static
way. But there's an issue with this: The PowerNode assumes that all
children have the same type. If we want to store the TreePath in the
nodes as we currently do, and use a fully static describtion, it will
have a different type for all children. Hence the type of the children
will differ and we can no longer use PowerNode. There's three possible
solutions for this dilemma:

a)As a workaround, make the index for PowerNode children dynamic.
b)Only use CompositeNode.
c)Introduce a SemiPowerNode whose children are given as templates
with a single parameter that is filled with the static index
and require that the behaviour is exactly the same, up to the
index.

b) can currently be done if you want to allow the compiler
to optimize TreePaths away completely. c) looks like it will
be a lot of work. a) is what we currently implement, on totally
fine for me. I only wanted to point out these choices for completeness.

Best,
Carsten


-------------- 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/20150910/7fa27175/attachment.sig>