[Dune] [Dune-Commit] dune-localfunctions r828 - in trunk/dune/localfunctions: common lagrange test

[Martin Drohmann]

Hi Carsten,

I tested your patch with an icc 10.1 and it works well.


-- 
Martin Drohmann
Institut für Numerische und Angewandte Mathematik
Westfälische Wilhelms-Universität Münster
Einsteinstr. 62, D-48149 Münster
Tel. +49 (0) 251 83-32753
Fax. +49 (0) 251 83-32729


On 12 February 2010 23:54, Carsten Gräser <graeser at math.fu-berlin.de> wrote:
>
> Hi Martin,
> I'm not sure if the change is satisfying. Of course we could safely
> change the implementation of the template method evaluate and still
> disable the 'using' statement. Then at least the explicitly instanciated
> template method should work for icc.
>
> Since I have no icc at hand, could you please test the
> attached version of virtualinterface.hh with the modified
> virtualshapefunctiontest.hh ?
>
> Regards
> Carsten
>
> Am 12.02.2010 23:33, schrieb Martin Drohmann:
>> Hi Dune,
>>
>> I have no voting rights, but, nonetheless, two opinions for you:
>>
>> I think Carsten should commit his patch, because in my opinion it is
>> not a big loss when we do without a template free evaluate method.
>> Indeed, I think readability of code can get really bad when only the
>> argument types of a function call, specify which derivative of a local
>> function gets evaluated.
>>
>> Concerning the support for old icc and gcc versions, I am unsure:
>>
>> - On the one hand, I dislike cluttering the code with #ifdefs for
>> different compilers. Surely, no-one likes this. And if no-one uses
>> these compilers at the moment, there surely is no reason to do so.
>>
>> - On the other hand, after I finally understood Markus' email, I think
>> there is a point:
>> If code fails with only one compiler, it is likely, that this code is
>> not standard compliant. And if some day, there emerges an awesame
>> processor architecture on which only a compiler X from a vendor Y
>> produces good code, we might be happy to have code that follows an old
>> and easy standard and can thus be quickly ported. But I do not know,
>> how likely this case is, and wether all Dune developers really want to
>> abstain from recent gcc compiler features.
>>
>> BTW: In this special case, after looking in a C++ standard document
>> from 2003, I found out, that method functions from a base class copied
>> with the using directive to the derived class's scope can be
>> overridden in the derived class. Unfortunately, the standard does not
>> say anything about *template* method functions. Here, the document
>> gives the compiler implementer room for interpretation. The g++ says
>> the rule applies as well, icc states the opposite.
>> So, code compliant with this standard, should not use this feature for
>> template method functions, and the icc reminded us of this. This is
>> also an argument for Carsten's patch.
>>
>> Regards,
>> Martin
>>
>
>
> --
> ----------------------------------------------------------------------
> Carsten Gräser           | phone: +49-30 / 838-75349
> Freie Universität Berlin | fax  : +49-30 / 838-54977
> Institut für Mathematik  | email: graeser at math.fu-berlin.de
> Arnimallee 6             |
> 14195 Berlin, Germany    | URL  : http://page.mi.fu-berlin.de/graeser
> ----------------------------------------------------------------------
>
> _______________________________________________
> Dune mailing list
> Dune at dune-project.org
> http://lists.dune-project.org/mailman/listinfo/dune
>
>