Re: C++11 now default?

[Ben Abbott]

> On Feb 19, 2016, at 9:55 AM, 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?
> 
> Are there issues other than auto_ptr being deprecated?
> 
> jwe

Sorry for not checking on this earlier. I had (have) other problems building, 
but just got things going again. In any event, Apple’s clang looks to be 
derived from gcc 4.2.1 ...

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

… and I’m unable to compile with the unique_ptr.

In file included from libinterp/dldfcn/__delaunayn__.cc:50:
In file included from libinterp/corefcn/Cell.h:31:
In file included from ./liboctave/array/Array.h:38:
./liboctave/array/idx-vector.h:68:3: error: too few template parameters in 
template redeclaration
  template <typename T> friend class std::unique_ptr;
  ^~~~~~~~~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:2486:1:
 note: previous template declaration is here
template <class _Tp, class _Dp = default_delete<_Tp> >
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
libinterp/dldfcn/__delaunayn__.cc:194:19: warning: use of old-style cast 
[-Wold-style-cast]
                  FOREACHvertex_ (facet->vertices)
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/sw/include/libqhull/libqhull.h:912:34: note: expanded from macro 
'FOREACHvertex_'
#define FOREACHvertex_(vertices) FOREACHsetelement_(vertexT, vertices,vertex)
                                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/sw/include/libqhull/qset.h:137:24: note: expanded from macro 
'FOREACHsetelement_'
          variable##p= (type **)&((set)->e[0].p); \
                       ^        ~~~~~~~~~~~~~~~~
1 warning and 1 error generated.

When I revert changeset 61c96c37ce69

        http://hg.savannah.gnu.org/hgweb/octave/rev/61c96c37ce69

I am able to build (I have other problems with crashes. I’ll follow up on 
another thread once I track down the problem).

Ben