Re: A case for C++11 in Octave

[Carnë Draug]

On 15 November 2014 19:29, Mike Miller <address@hidden> wrote:
> On Sat, Nov 15, 2014 at 11:29:34 +0100, c. wrote:
>>
>> On 14 Nov 2014, at 17:58, Carnë Draug <address@hidden> 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. <address@hidden> wrote:
>
> On 14 Nov 2014, at 17:58, Carnë Draug <address@hidden> 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ë