octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A case for C++11 in Octave


From: Carnë Draug
Subject: Re: A case for C++11 in Octave
Date: Fri, 14 Nov 2014 16:58:06 +0000

On 14 November 2014 16:14, c. <address@hidden> wrote:
> Hi Carnë,
>
> On 14 Nov 2014, at 16:32, Carnë Draug <address@hidden> wrote:
>
>> I understand that the reason for not making use of it is to avoid making
>> users in ancient systems to build a recent compiler.
>> While I appreciate the value of being able to build on older systems, I'd
>> like to believe that users on such systems are either more interested on
>> older versions of Octave (they avoid upgrades, after all they're still
>> running CentOS 5 and without EPEL), or are capable enough to build gcc
>> themselves.
>
> Unfortunately the situation is not that simple.
> Many recent HPC systems, as for example
> http://www.hpc.cineca.it/hardware/plx are still using
> quite old systems:
>
>   "Welcome to PLX DataPlex Cluster @ CINECA  -  RedHat EL 5.6!"
>
> and even if other versions of gcc than the default (which is 4.1.2)
> are available on that system, the most recent I managed to get
> installed there is 4.7 which does not yet implement the c++11 standard 
> completely.
>
> Indeed I am able to compile gcc 4.9 myself and that's what I need to do on
> my laptop anyway, but doing so on the cluster at the system level involves a
> lengthy and non trivial procedure.
>
> I believe the same applies to more other scientific HPC or corporate systems 
> than
> you would expect, so I don't think it is a good idea to drop backward 
> compatibility just yet ...

But I'm suggesting it for 4.2. If we keep the current release rate, it
will be released very
late in next year (3.4.0, 3.6.0, and 3.8.0 were released February
2011, January 2012, and
December 2013 respectively).  The next 4.0.X series would still build
fine on those
old systems. And by the time it gets released, will the people using
those systems
really need Octave 4.2 or will they be able to work on Octave 4.0?

What would we require to make the jump to C++11 then? Certainly it
can't be "when
there are no systems around where gcc 4.8 can't be built"?

Or instead of aiming for a specific C++ standard, we could aim for the
standard features
implemented on at least a specific version of gcc.

Carnë



reply via email to

[Prev in Thread] Current Thread [Next in Thread]