GNOME Bugzilla – Bug 748630
Use of deprecated auto_ptr<>
Last modified: 2015-05-03 08:12:28 UTC
Glibmm uses the deprecated std::auto_ptr<>. This generate unecessary warnings. Example: CXX header.o In file included from /usr/include/glibmm-2.4/glibmm/object.h:29:0, from /usr/include/glibmm-2.4/glibmm/interface.h:24, from /usr/include/gtkmm-3.0/gtkmm/toolshell.h:27, from /usr/include/gtkmm-3.0/gtkmm/toolbar.h:33, from /usr/include/gtkmm-3.0/gtkmm/settings.h:29, from header.cc:30: /usr/include/glibmm-2.4/glibmm/objectbase.h:215:13: warning: ‘template<class> class std::auto_ptr’ is deprecated [-Wdeprecated-declarations] static std::auto_ptr<Threads::Mutex> extra_object_base_data_mutex; ^ In file included from /usr/include/c++/5.1.1/memory:81:0, from /usr/include/glibmm-2.4/glibmm/objectbase.h:32, from /usr/include/glibmm-2.4/glibmm/object.h:29, from /usr/include/glibmm-2.4/glibmm/interface.h:24, from /usr/include/gtkmm-3.0/gtkmm/toolshell.h:27, from /usr/include/gtkmm-3.0/gtkmm/toolbar.h:33, from /usr/include/gtkmm-3.0/gtkmm/settings.h:29, from header.cc:30: /usr/include/c++/5.1.1/bits/unique_ptr.h:49:28: note: declared here template<typename> class auto_ptr;
This is glibmm 2.44.0 and gcc 5.1 (Fedora 22)
Not sure if that can be fixed without breaking the ABI. :-/
Do you get this only when specifying --std=c++11 to g++ or do you get this warning with a normal build?
By the way, patches would be welcome for the C++11 branch I've been playing with now and then: https://git.gnome.org/browse/glibmm/log/?h=c%2b%2b11v2 (I need to rebase that again.)
(In reply to Murray Cumming from comment #3) > Do you get this only when specifying --std=c++11 to g++ or do you get this > warning with a normal build? Yes I build with --std=c++11.
Created attachment 302658 [details] [review] Proposed patch
Thanks, though, actually, when we support C++11 for real, I guess we will support only C++11, and then we can do a real ABI break. And this use of auto_ptr<> is just to avoid an ABI break anyway: " #include <memory> // auto_ptr, needed until the next ABI break. " This is the commit that added it: https://git.gnome.org/browse/glibmm/log/glib/glibmm/objectbase.h?showmsg=1 At some point soonish I'll figure out how to do it in an ABI-breaking way if you don't first. I would like something like that macro so we can already optionally support some C++11 features such as move constructors.
See comment 2. My take on moving to C++11 and requiring it? Let's break the ABI to.
In glibmm/objectbase.h: static std::auto_ptr<Threads::Mutex> extra_object_base_data_mutex; This particular instance of std::auto_ptr can be replaced by a plain pointer: static Threads::Mutex* extra_object_base_data_mutex; It's used only in glibmm/objectbase.cc and glibmm/object.cc. It's allocated in objectbase.cc before main() is entered, and kept until the program returns from main(). It doesn't matter if it won't be deleted. At an ABI break, don't replace this auto_ptr by unique_ptr or by anything else. Remove it, and change the code as described in a TODO in objectbase.h.
> It's used only in glibmm/objectbase.cc and glibmm/object.cc. Shall be: It's used only in glibmm/objectbase.cc, glibmm/object.cc and glibmm/interface.cc.
Created attachment 302721 [details] [review] patch: Glib::ObjectBase: Don't use std::auto_ptr Another proposed patch. #include <memory> is not needed in objectbase.h, if std::auto_ptr is replaced by a plain pointer. Would it be ok to remove it? Is a removal of an #include an API break? Users may depend on <memory> without including it themselves.
OK. Thanks. Please go ahead with that in git master.
Review of attachment 302721 [details] [review]: https://git.gnome.org/browse/glibmm/commit/?id=0b8237dd0b77a1e2d031256bacd97e13193039bb
I close this bug, because it's fixed by the patch in comment 11. Feel free to reopen it, if you think the patch in comment 6 should be further discussed. The AX_CXX_COMPILE_STDCXX_11() m4 macro can still be interesting, even though it's not needed for fixing the compiler warning from objectbase.h.