Re: C++11 now default?

[Carnë Draug]

On 19 February 2016 at 14:55, John W. Eaton <address@hidden> wrote:
> On 02/18/2016 09:15 PM, Mike Miller wrote:
>>
>> On Thu, Feb 18, 2016 at 17:30:36 -0800, Rik wrote:
>>>
>>> Changset 21304:0cf6c08cb252 uses Autoconf macros to check for the
>>> presence
>>> of a C++ compiler that supports the 2011 standard, and defaults to that
>>> compiler if it exists.  This is producing a lot of warnings because the
>>> Octave code base is not written to that standard.  For example:
>>>
>>>   ./liboctave/util/unwind-prot.h:71:14: warning: 'template<class> class
>>> std::auto_ptr' is deprecated [-Wdeprecated-declarations]
>>>
>>> I don't mind shifting if that is the consensus decision, but we should
>>> make
>>> it a conscious choice.  It has been 5 years since the standard was
>>> published, but I'm sure Octave also gets compiled on ancient machines
>>> where
>>> there may not be a 2011-compliant compiler.
>>
>>
>> My understanding from previous discussions, and from patch #8906 where
>> this was worked out, is that the intent is to allow the compiler to use
>> the newest standard when available, but that we are not going to start
>> requiring a C++11 compatible compiler at all.
>>
>> By the way, when gcc 6 starts to become available in distros soon, it
>> will enable the GNU flavors of C11 and C++14 by default without any -std
>> options.
>>
>> Yes, I see the same warnings as you and it's a little annoying, and
>> maybe we can test for the availability of std::unique_ptr and
>> conditionally use that instead of std::auto_ptr.
>
>
> It looks like GCC added support for unique_ptr in version 4.4 and that was
> released in April 2009.  Do we really need a configure check, or should we
> just switch to using that instead of auto_ptr?  I hesitate to clutter the
> code with a UNIQUE_PTR macro (or similar) to cope with the possibility of
> not having unique_ptr.  I suppose we can do that if necessary, but maybe we
> should start by just using unique_ptr and seeing if anyone complains.  If
> there are many complaints, then maybe we could add the check?

We can have a configure check that requires unique_ptr so at least it
will fail at configure time.

> Are there issues other than auto_ptr being deprecated?

I have been building with C++11 for several months now  (Debian stable,
gcc 4.9.2) and that's the only one I noticed.

My plan was to work on this once the change of default got accepted but if
we make unique_ptr a build requirement, that's a lot less work.

Carnë