[dune-pdelab] Variadic Templates

[Steffen Müthing]

I had some time today to look into this. The root cause is really that in the
CompositeGridFunctionSpace the corresponding ordering is constructed
by simply extracting the child orderings and sticking them into the new
Ordering, which is a CompositeNode. This breaks down if variadic templates
are not available and there are less than 10 children, as in that case, the code
will try to extract orderings from the EmptyNode markers.

The sane way to resolve this is to use a TypeTree transformation to construct
the Ordering, because the algorithm automatically takes care of not touching the
empty children. We didn't do that in March because there was no way to stop
the transformation from recursing into the tree (instead of stopping at the first level).

So I fixed that (transformation descriptors can now specify whether the algorithm
should recurse into the children of a node) and rewrote the Ordering construction
for CompositeGFS. It works for me on Apple GCC 4.2 now.
Christian, could you check if you can compile it as well (Apple's GCC is a *slightly*
non-standard beast...)?

By the way: While testing the impact of the change on the compilation performance,
I noticed that compiling testgridfunctionspace takes almost twice as long using
GCC 4.2 when compared to GCC 4.5 and uses about 20% more memory. So it
really pays off to have a recent compiler on development machines ;-)

Steffen

Am 11.06.2011 um 19:11 schrieb Jö Fahlke:

> Am Fri, 10. Jun 2011, 20:41:43 +0200 schrieb Christian Engwer:
>> I remember Jö describing a SFINAE construct to select a class,
>> depending on the presence of a certain typedef in an other class. Not
>> sure if this might help.
> 
> That would probably be something like
> 
>  template<class T>
>  struct AlwaysVoid { typedef void Type; };
> 
>  template<class T, class Dummy = void>
>  class SomeClass {
>    // Stuff that works without T::Foo
>  };
> 
>  template<class T>
>  class SomeClass<T, typename AlwaysVoid<T>::Type> {
>    // Stuff that works with T::Foo
>  };
> 
> or you can make a predicate and use enable_if
> 
>  template<class T, class Dummy = void>
>  class HasFoo : public false_type {};
> 
>  template<class T>
>  class HasFoo<T, typename AlwaysVoid<T>::Type> : public true_type { };
> 
>  template<class T, class Dummy = void>
>  class SomeClass {
>    // Stuff that works without T::Foo
>  };
> 
>  template<class T>
>  class SomeClass<T, typename enable_if<HasFoo<T>::value>::Type> {
>    // Stuff that works with T::Foo
>  };
> 
> I think the alternative approach of using a bool instead of a class for Dummy
> (which would allow to use Dune::AlwaysTrue) had a drawback, something along
> the lines of "non-trivial integral expression in a specializations template
> argument list".
> 
> 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

Steffen Müthing
Universität Stuttgart
Institut für Parallele und Verteilte Systeme
Universitätsstr. 38
70569 Stuttgart
Tel: +49 711 685 88429
Fax: +49 711 685 88340
Email: steffen.muething at ipvs.uni-stuttgart.de