> 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).