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

[Carsten Gräser]

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
----------------------------------------------------------------------
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch
URL: <https://lists.dune-project.org/pipermail/dune/attachments/20100212/befe7edc/attachment.ksh>