[Dune] [Dune-Commit] dune-localfunctions r828 - in trunk/dune/localfunctions: common lagrange test
Markus Blatt
Markus.Blatt at iwr.uni-heidelberg.de
Fri Feb 12 14:39:17 CET 2010
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
More information about the Dune
mailing list