[dune-pdelab] Variadic Templates

[Jurgis Pods]

Hi,

I didn't follow the discussion at all, but my latest version of 
dune-pdelab-howto does currently not compile. In the 
navier-stokes/dgstokes example, it complains about a missing member 
'ordering' in CompositeGridFunctionSpace. Is this related to the latest 
changes?

Best,
Jurgis

On 15.06.2011 17:12, Steffen Müthing wrote:
> 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
>
>
>
>
>
>
> _______________________________________________
> dune-pdelab mailing list
> dune-pdelab at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-pdelab