On 10 November 2015 at 14:31, Vladimir Prus
On 10-Nov-15 4:08 PM, Andrey Semashev wrote:
On 2015-11-10 15:51, Artyom Beilis wrote:
On 2015-11-09 18:52, Marshall Clow wrote:
[snip] I'm seeing lots of warnings about use of deprecated std::auto_ptr in
different libraries: Boost.DateTime, Boost.Locale, Boost.Signals. I've attached the list of places where these warnings occur. [snip]
See... unlike Boost, most of the ordinary world still uses C++2003 and will use it for a long time especially for existing projects.
Existing libraries like Boost.Locale support C++2003.
std::auto_ptr is perfect way to provide ownership move semantics without rvalue reference despite the fact some may abuse it.
I wouldn't call it perfect. In the lack of rvalue references I would have preferred an explicit method to return a proxy that acts like rvalue reference. But that's offtopic.
Would you consider porting Boost.Locale to boost::movelib::unique_ptr from Boost.Move?
Note that you will have to switch at some point as MSVC developers are planning to remove auto_ptr from the standard library at some point.
Do you have a link saying so? That's quite unfortunate stance, indeed.
I think, this is the relevant announcement: http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-... """ [2015 opt-in] Available in VS 2015 RC, but guarded by a macro. By default, we provide auto_ptr/etc. If you define _HAS_AUTO_PTR_ETC to 0 project-wide (which you should do via the command line or project file, not via #define), then we won't provide auto_ptr/etc. This opt-in behavior will remain unchanged in 2015 RTM. In the next major version, I'm planning to make this opt-out, and in the major version after that, I'm planning to eliminate auto_ptr/etc. entirely. Now would be a good time to start migrating your code. (I've already informed Boost's maintainers.) """ BTW, I have been asking about _HAS_AUTO_PTR_ETC support too http://lists.boost.org/boost-users/2015/09/84965.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net