[dune-pdelab] Variadic Templates

[Steffen Müthing]

Hi Jurgis,

thanks for the heads up. The problem was that dgstokes still used the old
*Mapper types in the CompositeGFS instead of *OrderingTag. I don't know
why nobody noticed this earlier, but this backward compatibility code was broken
for GridFunctionSpaceComponentBlockwiseMapper. I fixed the backward
compatibility issue, added a note reminding users to change their code to
README.Changes and did the replacement in dgstokes.cc.

We should probably deprecate the old types, but I somehow completely failed
when trying to deprecate GridFunctionSpaceComponentBlockwiseMapper.
Perhaps someone else could look into that?

Thanks,

Steffen

Am 21.06.2011 um 16:37 schrieb 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
> 
> _______________________________________________
> dune-pdelab mailing list
> dune-pdelab at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune-pdelab

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