"template<class> class std::auto_ptr" is deprecated in C++11/C++14 (GCC6 default)

[daveol]

When the rebuild for Fedora 24 triggered it failed. This was due to a deprecation warning that was treated as a error.

The deprecation warning was about template<class> class std::auto_ptr since this is used in protoc/CppGenerator.cpp on line 52 and line 57

The koji build job is here and the build log is here

[peternewman]

-Wno-deprecated-declarations appears to be the immediate workaround.

See also:
http://stackoverflow.com/questions/2404115/is-auto-ptr-deprecated

This seems to imply it can be bypassed/fixed with some compiler flags:
fuzzylite/fuzzylite#65

[peternewman]

It would appear the main cause is:
"The default mode for C++ is now -std=gnu++14 instead of -std=gnu++98."

[daveol]

I can confirm this, since a build with -std=gnu++98 didn't fail

[daveol]

For what it's worth, this is the patch I made for the fedora package:

diff --git a/configure.ac b/configure.ac
index ef31e09..3e98692 100644
--- a/configure.ac
+++ b/configure.ac
@@ -34,6 +34,9 @@ AC_PROG_LN_S
 AC_PROG_MAKE_SET
 AC_PROG_MKDIR_P

+# Ensure we use gnu++98 instead of c++14
+CPPFLAGS="$CPPFLAGS -std=gnu++98"
+
 # Checks for header files.
 AC_HEADER_DIRENT
 AC_HEADER_RESOLV

[peternewman]

Thanks for the confirmation @daveol . @nomis52 any feeling on how we should progress?

[daveol]

did some more searching, auto_ptr is deprecated in c++11 and the replacement of it would be unique_ptr, which was only introduced in c++11...

[nomis52]

We've discussed this before so I'll put the notes here.

This comes down to Precise.

gcc 4.7 was the first to ship with -std=c++11 . The Ubuntu situation is:

• Precise, gcc 4.6 , EOL Apr 2017
• Trusty, gcc 4.8 , EOL Apr 2019

As a comparison Jesse uses gcc 4.9.

So on Apr 2017, I'll be more than happy to accept a patch switching to unique_ptr.

[peternewman]

Until April 2017 though, it seems like we could do with a patch to detect -std=gnu++14 as the default and set it back to 98 or whatever so it builds correctly.

[peternewman]

See #1080 for some commits that detect when -std=gnu++11 and -std=gnu++98 are both available and then force gnu++98 to be added to the flags.

We could call this a fix or leave it until we've removed auto_ptr support? We may also be able to do something clever with macros to support both, but I don't know if it's worth the codebase hassle.

[nomis52]

I think the fix in #1080 is sufficient to close this.

[peternewman]

Fixed in #1090 which will be in 0.10.3.

[nomis52]

Reopening.

Precise is no longer supported so we're free to switch to -std=c++11 and unique_ptr.

[peternewman]

#1258 allows us to compile on C++11 (by disabling the errors) or C++98, so if we add new C++11 language features we'll need to break the older builds.

[davoc]

I've just started using odb and c++, I had this issue while playing around with some stuff. I found that -Wno-deprecated-declarations (as suggested by peternewman) with -std=c++11 works for me (g++ on ubuntu 17.10)

[peternewman]

@davoc do you mean you had this issue with OLA, it should have been fixed in our releases since 0.10.5 so you don't need to do anything and don't get the error (it autodetects and adds the -Wno argument as necessary. Or are you saying this wasn't the case for you?

[peternewman]

Another C++11 thing to add back in. #1556 (comment)

[peternewman]

Personally I'd like to get master released as 0.11.0 before we require C++11, given it's had a lot of changes added and is pretty stable (and gives people on more random platforms a bit more C++11 support). We can then branch that and all future master commits can be C++11 capable (i.e. Ubuntu 14.04 compatible).

[Lotharyx]

It's a couple years later...any further thoughts/discussion/decision on whether to advance OLA to C++11?

I would be happy to contribute to the effort as time permits. I know everyone is busy.

[kiilerix]

So, in 2021, we still can't use C++11, also not in the upcoming major version 0.11, but can only expect that in 0.12? That seems like an extremely conservative approach that make this project seem outdated and hinder clean packaging in distros.

Please reconsider.