[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: C++11 now default?
From: |
Carnë Draug |
Subject: |
Re: C++11 now default? |
Date: |
Sat, 20 Feb 2016 15:22:15 +0000 |
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ë
- Re: C++11 now default?, Rik, 2016/02/22
- Re: C++11 now default?, Mike Miller, 2016/02/22
- Re: C++11 now default?, John W. Eaton, 2016/02/22
- Re: C++11 now default?, Mike Miller, 2016/02/22
- Re: C++11 now default?, John W. Eaton, 2016/02/22
- Re: C++11 now default?, Ben Abbott, 2016/02/23
- Re: C++11 now default?, Ben Abbott, 2016/02/23
- Re: C++11 now default?, John W. Eaton, 2016/02/23
- Re: C++11 now default?, Ben Abbott, 2016/02/23