octave-maintainers
[Top][All Lists]
Advanced

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

Re: Will version 4.2 require C++11?


From: Rik
Subject: Re: Will version 4.2 require C++11?
Date: Fri, 20 May 2016 16:29:22 -0700

On 05/20/2016 01:20 PM, John W. Eaton wrote:
> On 05/20/2016 12:45 PM, Rik wrote:
>> 5/20/16
>>
>> jwe,
>>
>> I notice that the 'auto' keyword is now used in 5 places in liboctave:
>>
>> system/lo-sysdep.h:const auto octave_getcwd = octave::sys::getcwd;
>> system/lo-sysdep.h:const auto octave_chdir = octave::sys::chdir;
>> system/lo-sysdep.h:const auto octave_popen2 = octave::sys::popen2;
>> util/oct-glob.h:const auto octave_fnmatch = octave::sys::fnmatch;
>> util/oct-glob.h:const auto octave_glob = octave::sys::glob;
>>
>> That keyword is a C++11 feature.  Are we going to move to require that
>> feature level for the development branch?
>
> I still think that it makes sense to use some restraint with C++11
> features, but I'm OK with using auto for things like this.

The thing with 'auto' is that it is quite a binary decision.  Prior to
C++11 the auto keyword meant automatic variable, i.e, an ordinary local
variable that was not stored in a register as specified by the 'register'
keyword.  If we are using it even once in its new sense, then we require
C++11 conformance.  We should test for that in configure, and then we might
as well use the rest of the C++11 features.  "In for a penny, in for a pound".

Just for fun, I added the flag '-std=gnu++03' to my CXXFLAGS variable,
re-configured, and re-compiled.  According to the man page for gcc, this
level is the default if no -std is explicitly given.  Sure enough, the
compilation fails at unique_ptr. 

>
> OTOH, using auto to make aliases won't work for overloaded function
> names.  In those cases I just used inline wrapper functions.  If there is
> some problem with auto then we could always just use inline wrappers for
> these cases as well.
>
> We are already using unique_ptr unconditionally and I haven't seen a lot
> of complaints about that.  So my guess is that C++11 is not causing a lot
> of trouble.

That's good.  It is 5 years after the fact, and Octave has been increasing
in functionality fairly quickly.  In order to access those features it is
easiest to build from new source which I expect means on a relatively
modern system, rather than a Cray machine.

--Rik




reply via email to

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