New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare a migration path away from auto_ptr #323

Closed
lballabio opened this Issue Oct 20, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@lballabio
Copy link
Owner

lballabio commented Oct 20, 2017

auto_ptr was deprecated in the C++11 standard and removed in C++17.

We should think of a way to prevent errors in future versions of compilers while keeping backwards compatibility as usual. One way would be to provide a compilation flag enabling a switch from auto_ptr to unique_ptr. To begin with, passing the flag might be left to the user. Later, the need for it might be detected in configure or based on the compiler version.

@jgsogo

This comment has been minimized.

Copy link
Contributor

jgsogo commented Nov 1, 2017

auto_ptr and unique_ptr are not 100% compatible, it can be difficult to keep code as is.

One alternative could be to use boost::unique_ptr for C++03 compilers and deprecating support for older ones. A typedef and a config variable could do the rest.

@lballabio

This comment has been minimized.

Copy link
Owner Author

lballabio commented Nov 2, 2017

True, they have different semantics. However, from a quick grep, it seems that auto_ptr is only used to return from clone() methods and the contained raw pointer is immediately stored into a shared_ptr or some other structure. unique_ptr should behave in the same way for this specific use case. Truth be told, we might also return a shared_ptr and be done with it...

@jgsogo

This comment has been minimized.

Copy link
Contributor

jgsogo commented Nov 2, 2017

+1 to shared_ptr and get rid of the problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment