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

Fri Feb 12 23:33:36 CET 2010

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

-- 
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 20:20, Carsten Gräser <graeser at math.fu-berlin.de> wrote:
> No one seems to know which old compilers are still used
> with dune. As the developers all seem to use more recent
> compilers it would be nice to also have feedback from the
> users which compilers/versions are actually used.
>
> Otherwise the 'Perhaps compiler-x.y is still used' argument
> are valid forever. When do we want to drop support for older
> (and less standard conforming) compilers ?
>
> E.g. the first gcc-4.x release is about 5 years old and the last
> gcc-3.4.x release about 4 years.
>
> Of course supporting other compilers (xlc, sun ?) would
> be nice, but this seems to be a different issues. If we
> want to have support for them this is in no way guaranteed
> by supporting older gcc/icc versions.
>
> Regards
> Carsten
>
> Am 12.02.2010 15:57, schrieb Andreas Dedner:
>> Of course I would agree that xlc would be good to have on the support list.
>> But is there any direct correspondence between gcc 3.4 and xlc?
>> I think that especially testing with gcc 3.4 although we are close to
>> having a gcc 4.5 is unnecessary - bur is adding a test for xlc (if
>> possibl)e not
>> a different issue?
>>
>> Andreas
>>
>> Markus Blatt wrote:
>>> Hi,
>>>
>>> On Fri, Feb 12, 2010 at 02:25:42PM +0100, Oliver Sander wrote:
>>>
>>>> I agree with this.  Do we know of actually users who need the backward
>>>> compatibility and cannot stay with Dune 1.2.2 at the same time?
>>>>
>>>>
>>>> Andreas Dedner schrieb:
>>>>
>>>>> Hi,
>>>>> I think we have to discuss to what extend we really want to still
>>>>> support these old compiler - especially icc 7 and gcc 3.4.
>>>>> Could somebody who really uses them comment on this. For example
>>>>> in Karlsruhe on their cluster they have gcc 4.2 and icc 12.
>>>>> We said we wanted to have the compatibility for 2.0 and lets go ahead
>>>>> with that but some of the fixes checked in to manage this have  not
>>>>> been
>>>>> very nice code and if nobody requires the old compiler I would
>>>>> suggest to revert some of the changes (e.g. in
>>>>> dune-lf/dune/lf/utility/field.hh)
>>>>> in the trunk and to drop those old compilers from the compatibility
>>>>> list
>>>>> for the next release.
>>>>> Best
>>>>> Andreas
>>>>>
>>>
>>>
>>> While I agree that few people use this compilers, I still think
>>> dropping support for them is not the way to go. The more compilers we
>>> support the more standard compliant we are. In the last weeks several
>>> non standard-conformant things were patched due to supporting these
>>> rather old compilers.
>>>
>>> My fear is that if we drop support we will maybe not drop standard
>>> conformance, but use more and more features that are just supported by
>>> the leading pack of the compilers. This would prevent other compilers
>>> (e.g. IBM's xlc) from catching up.
>>>
>>> There are compilers on supercomputers (xlc on the Blue Gene) that I
>>> would like to see being supported by Dune. IMO support here means giving
>>> them time to implement the standard correctly before DUNE moves to the
>>> next standard.
>>> Having said that, I agree that using typedefs in code to do this is a
>>> real pain and not beautiful/readable etc.
>>>
>>> Just my 2 cents.
>>>
>>> Marus
>>>
>>> _______________________________________________
>>> Dune mailing list
>>> Dune at dune-project.org
>>> http://lists.dune-project.org/mailman/listinfo/dune
>>>
>>
>>
>> _______________________________________________
>> Dune mailing list
>> Dune at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune
>
>
> --
> ----------------------------------------------------------------------
> 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
>