A case for C++11 in Octave

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

A case for C++11 in Octave

Carnë Draug
Hi

I would like to suggest we start making use of C++11 features in Octave.
It is been around for a while now and will have been around for even
longer by the time we release what's on the default branch.

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.

The reasoning is that we are paying a cost for not making use of C++11,
only to make things a bit easier (but far from impossible) on what
I believe to be a capable minority.  Yes, we can around the lack of features
added in C++11 but is the extra burden worth it?  This is not new, see
the following comment on [1]

  // FIXME: this would be simpler once C++0x is available

or [2]

  // FIXME: this mostly duplicates the code in the print_nd_array<>
  // function. Can fix this with std::is_same from C++11.

There are other occurrences in the source [3, 4, 5], and of course these
are only the cases where people actually wrote it down.

I don't mean that we should go back and start changing all the pieces
that could make use of C++11. I am only proposing that we start using
those features when using them makes our lives easier.

If the decision is to still keep away from C++11, can we decide on a set
of requirements before we can make use of it?  Something like, "it must
have been supported by compilers A, B, and C, for at least N years" or,
"distros A, B, and C must have dropped support for all releases that
still don't support it".

Carnë

[1] http://hg.savannah.gnu.org/hgweb/octave/file/1f4455ff2329/liboctave/array/Array.h#l750
[2] http://hg.savannah.gnu.org/hgweb/octave/file/1f4455ff2329/libinterp/corefcn/pr-output.cc#l2869
[2] http://hg.savannah.gnu.org/hgweb/octave/file/1f4455ff2329/libinterp/corefcn/jit-ir.h#l294
[3] http://hg.savannah.gnu.org/hgweb/octave/file/1f4455ff2329/libinterp/corefcn/toplev.cc#l290
[4] http://hg.savannah.gnu.org/hgweb/octave/file/1f4455ff2329/libinterp/corefcn/gcd.cc#l61
[5] http://hg.savannah.gnu.org/hgweb/octave/file/1f4455ff2329/liboctave/cruft/Faddeeva/Faddeeva.cc#l183

Reply | Threaded
Open this post in threaded view
|

Re: A case for C++11 in Octave

c.-2
Hi Carnë,

On 14 Nov 2014, at 16:32, Carnë Draug <[hidden email]> 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 ...

Just my two .2€,
c.
Reply | Threaded
Open this post in threaded view
|

Re: A case for C++11 in Octave

Carnë Draug
On 14 November 2014 16:14, c. <[hidden email]> wrote:

> Hi Carnë,
>
> On 14 Nov 2014, at 16:32, Carnë Draug <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: A case for C++11 in Octave

Michael Godfrey
In reply to this post by Carnë Draug
This is a good idea and should be done as soon as feasible. One obvious
requirement is that all the main packagers are able to handle C++11.  It should
the case that they all can already, but...
Individuals who compile from source should be able to upgrade if necessary.

Giving advance warning will be important.
Reply | Threaded
Open this post in threaded view
|

Re: A case for C++11 in Octave

c.-2
In reply to this post by Carnë Draug

On 14 Nov 2014, at 17:58, Carnë Draug <[hidden email]> wrote:

> 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.

what features in particular would you like to start using?

We should at least check carefully and document clearly what
minimum version of c++/clang++/icc/XL-c++ we will be requiring.

Version compatibility tables are available for all compilers I know,
here is the tabel for g++, for example:

https://gcc.gnu.org/projects/cxx0x.html

c.
Reply | Threaded
Open this post in threaded view
|

Re: A case for C++11 in Octave

c.-2
In reply to this post by Carnë Draug

On 14 Nov 2014, at 17:58, Carnë Draug <[hidden email]> wrote:

> But I'm suggesting it for 4.2. If we keep the current release rate, it
> will be released very

I am currently running the development version of Octave from mercurial
on PLX, tis would stop working then ...
c.


Reply | Threaded
Open this post in threaded view
|

Re: A case for C++11 in Octave

Mike Miller
In reply to this post by c.-2
On Sat, Nov 15, 2014 at 11:29:34 +0100, c. wrote:
>
> On 14 Nov 2014, at 17:58, Carnë Draug <[hidden email]> wrote:
>
> > 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.
>
> what features in particular would you like to start using?

I'm also interested in seeing which particular features you're
interested in using for Octave.

> We should at least check carefully and document clearly what
> minimum version of c++/clang++/icc/XL-c++ we will be requiring.

+1

I'm a little on the skeptical side I guess, I lean more towards keeping
backwards and compiler-neutral compatibility, but if the group agrees it
would be advantageous to start using some C++11 features, I can be
flexible.

At this point in time it might be nice to continue supporting at least
gcc 4.4, to continue to be open to new contributors using "stable"
distro releases.

Thanks,

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: A case for C++11 in Octave

Carnë Draug
On 15 November 2014 19:29, Mike Miller <[hidden email]> wrote:

> On Sat, Nov 15, 2014 at 11:29:34 +0100, c. wrote:
>>
>> On 14 Nov 2014, at 17:58, Carnë Draug <[hidden email]> wrote:
>>
>> > 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.
>>
>> what features in particular would you like to start using?
>
> I'm also interested in seeing which particular features you're
> interested in using for Octave.

The one I last wanted to use was inheriting constructors from a parent
class.  This requires gcc 4.8 which is not acceptable since
Debian stable is still on 4.7.  Still, I'm only making the case now after
noticing the comments from others in the source files which suggests I'm
not the first here who wanted to make use of C++11 features.

>> We should at least check carefully and document clearly what
>> minimum version of c++/clang++/icc/XL-c++ we will be requiring.
>
> +1
>
> I'm a little on the skeptical side I guess, I lean more towards keeping
> backwards and compiler-neutral compatibility, but if the group agrees it
> would be advantageous to start using some C++11 features, I can be
> flexible.
>
> At this point in time it might be nice to continue supporting at least
> gcc 4.4, to continue to be open to new contributors using "stable"
> distro releases.

Version of gcc in the stable releases of Debian (wheezy) and RHEL (7)
are 4.7.2 and 4.8.2 respectively.  If we were to go with at least gcc 4.7,
we could already make use of some C++11 features.

On 15 November 2014 10:31, c. <[hidden email]> wrote:
>
> On 14 Nov 2014, at 17:58, Carnë Draug <[hidden email]> wrote:
>
>> But I'm suggesting it for 4.2. If we keep the current release rate, it
>> will be released very
>
> I am currently running the development version of Octave from mercurial
> on PLX, tis would stop working then ...

It won't change a thing for you.  You will still be able to build todays
development version just fine.  You will not be able to build next month
version but then again, you already can't build next month development
version today.


But if we agree that people locked on oldstable versions (or veryoldstable
in the case of RHEL and CentOS 5) are capable people, and that gcc 4.7
is the best that they can build there, can we go with features available
at least on that version?

Carnë

Reply | Threaded
Open this post in threaded view
|

Re: A case for C++11 in Octave

Thomas Weber-3
In reply to this post by c.-2
On Fri, Nov 14, 2014 at 05:14:03PM +0100, c. wrote:

> Hi Carnë,
>
> On 14 Nov 2014, at 16:32, Carnë Draug <[hidden email]> 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.

I used to be in that situation, a long time ago on a Redhat-based
cluster. In order to build Octave, I first had to build a newer gcc
(installed version was 2.x something), than the ATLAS and some other
libraries and then Octave. So, this is not really a new situation for
Octave!

That said, if you decide to require a newer compiler, go the full way!
Take the *latest* available compiler and use all the features. As soon
as some people have to build a newer compiler, it does not matter if
they have to build 4.x or 4.x+1 - the work should be the same.
Of course, having some documentation on how to build Octave and its
build-dependencies.

> 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.

Ask the administrators. If you are one of them, ask for help on some
other forums (maybe the GCC mailling lists, I don't know). This cluster
will run for a few years, so at some point in time the pressure for you
to provide a C++11 compiler will be so high that you have to give in ...

> 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 ...

The pressue on these systems and their administrators will be mounting
anyways - Octave is hardly unique in willing to exploit the benefits of
C++11.

        Thomas

Reply | Threaded
Open this post in threaded view
|

Re: A case for C++11 in Octave

c.-2
In reply to this post by Carnë Draug

On 16 Nov 2014, at 15:53, Carnë Draug <[hidden email]> wrote:

> But if we agree that people locked on oldstable versions (or veryoldstable
> in the case of RHEL and CentOS 5) are capable people, and that gcc 4.7
> is the best that they can build there, can we go with features available
> at least on that version?

While administrators of such old and supposedly "stable" systems are usually
indeed very capable they are also usually VERY conservative as they have to
work with extremely strict internal policy rules.

In the case of the particular system I was referring to, on that one gcc 4.7
is indeed available, so compiling Octave with that version would be in principle possible ...

Except that most, if not all, libraries on which Octave depends on are NOT built with
that compiler, mostly they are not even built with gcc, so making them work together is
a nightmare ...

To sum up, I don't want you to stop from using C++11 to solve my personal problem,
I am just pointing out that there is a non-negligible share of users out there that
may get into trouble if we break compatibility with older compilers

In my experience many of such users will end up with solutions like sticking to Octave 3.x
until the default system compiler supports all features required by 4.x to build.

c.
Reply | Threaded
Open this post in threaded view
|

Re: A case for C++11 in Octave

Michael Godfrey
It is certainly true that there a quite a few "legacy" sites which
are frozen into very old systems. There are many reasons for
this including use of legacy software, fear of change, Company
rules, etc.,... I have direct experience of such sites.
Many of these sites would prefer an older Octave in any case.

So, on balance, it seems better to move ahead and make Octave
better for the user community which is able to keep reasonably
up-to-date.

Michael
Reply | Threaded
Open this post in threaded view
|

Re: A case for C++11 in Octave

Mike Miller
In reply to this post by Carnë Draug
On Sun, Nov 16, 2014 at 14:53:39 +0000, Carnë Draug wrote:
> But if we agree that people locked on oldstable versions (or veryoldstable
> in the case of RHEL and CentOS 5) are capable people, and that gcc 4.7
> is the best that they can build there, can we go with features available
> at least on that version?

It's a tradeoff, we just have to decide if the benefit to
maintenance/convenience of development is worth the cost of possibly
alienating some class of current or potential users and contributors.

I don't think it is, but I'm also not very fluent in or excited about
the C++11 language additions, so I have a bias. I'm willing to accept
that others who are more familiar with the language may see great
benefits and come to a consensus that it is highly worth it.

It's my understanding there are also some who want to build or develop
with Octave using other compilers not mentioned here so far, such as
MSVC or Intel. Does anyone know if this will no longer be possible?

And on Mon, Nov 17, 2014 at 08:54:38 +0100, Thomas Weber wrote:
> That said, if you decide to require a newer compiler, go the full way!
> Take the *latest* available compiler and use all the features.

Agreed, if the consensus is to start using C++11 features, and not to
limit Octave to some compatible "oldstable" gcc, you might as well
start using whatever beneficial features are available in the latest
versions.

That said, there should probably be feature checks in the configure
script for each of the specific language features that you do want to
use.

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: A case for C++11 in Octave

Michael Goffioul
On Mon, Nov 17, 2014 at 11:44 AM, Mike Miller <[hidden email]> wrote:
On Sun, Nov 16, 2014 at 14:53:39 +0000, Carnë Draug wrote:
> But if we agree that people locked on oldstable versions (or veryoldstable
> in the case of RHEL and CentOS 5) are capable people, and that gcc 4.7
> is the best that they can build there, can we go with features available
> at least on that version?

It's a tradeoff, we just have to decide if the benefit to
maintenance/convenience of development is worth the cost of possibly
alienating some class of current or potential users and contributors.

I don't think it is, but I'm also not very fluent in or excited about
the C++11 language additions, so I have a bias. I'm willing to accept
that others who are more familiar with the language may see great
benefits and come to a consensus that it is highly worth it.

It's my understanding there are also some who want to build or develop
with Octave using other compilers not mentioned here so far, such as
MSVC or Intel. Does anyone know if this will no longer be possible?

As far as I know, MSVC has always put the emphasis on C++ rather than C (hence to miserable lack of some C99 features). But obviously, it depends on the specific wanted feature. The compliance list is available here:

Michael.

Reply | Threaded
Open this post in threaded view
|

Re: A case for C++11 in Octave

John W. Eaton
Administrator
I recently tried to build Octave with the "native" compiler on one of
these old but widely used systems.  I think it was SuSE 10.4, but the
results probably would have been the same on RHEL 5.8 (or equivalently,
CentOS).  I was pleasantly surprised that there were no problems
building Octave but when I tried to build packages I encountered failure
for the image package because it uses some c++11 features in one file,
union-find.h++.  I'm not sure of the reasons why c++11 features are
really needed in that file, but it is annoying to find that building
with the native compiler won't work.

Consider that I found this annoying, and I'm quite experienced building
Octave, GCC, and many other tools.  My experience is that when most
people hit failures like this, they just give up and curse the whole
experience.  It does NOT encourage them to upgrade their compiler or OS.

Further, if you rely on the latest features of the latest versions of
the tools you use, you are also likely to make things more difficult on
yourself.  What happens when those latest features have critical bugs
but you can't build with older versions of the tools?

I'd really prefer to be conservative about what new compiler features we
require to build Octave.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: A case for C++11 in Octave

Jordi Gutiérrez Hermoso-2
On Mon, 2014-11-17 at 14:07 -0500, John W. Eaton wrote:
> I was pleasantly surprised that there were no problems building
> Octave but when I tried to build packages I encountered failure for
> the image package because it uses some c++11 features in one file,
> union-find.h++. I'm not sure of the reasons why c++11 features are
> really needed in that file, but it is annoying to find that building
> with the native compiler won't work.

Yeah, my bad. I could get rid of the C++11 in the bwlabeln code. I
figured I had more leeway in an OF package than in Octave itself, and
it just looked better to do this with C++11. Note I also used my own
personal preference for filename extensions, .h++.

As I recall, the only nontrivial thing I needed was unordered_map, but
that's already in C++03 + TR1. I could patch it.

> Consider that I found this annoying,

If it's a big deal, I could go and patch this file to not use C++11. I
would also have to come up with autoconf checks to figure out where
unordered_map is.

- Jordi G. H.



Reply | Threaded
Open this post in threaded view
|

Re: A case for C++11 in Octave

Michael Godfrey
In reply to this post by John W. Eaton
John,

Previously I said that C++11 might be justified. In doing this I set
aside experience much like yours. It is unfortunate that the community
developing C++ and other components has not developed a
plan which could lead to long-term stability.
In any case, I think that your choice is the right one.

Michael