OpenLightingProject
Replace auto_ptr by unique_ptr
I think it's time to start replacing auto_ptr... it's in some of the header files, and auto_ptr is removed in c++20, which means that other projects that use ola can't be compiled in c++20 mode because of ola. It also solves a lot of warnings :).
This pull request solves also all ambiguous constructor std::unique_ptr(NULL) calls and fixes the linting warnings produces after the find-and-replace of (std::)auto_ptr by (std::)unique_ptr. I've also replaced unnecessary calls to release() by move construction/assignment where possible.
Looks like you caught all of the instances of
std::move()and default initializations. I didn't skim through more than what you changed but I assume you would get compile errors if you missed anything.I also assume there aren't any instances where these need to be
std::shared_ptr, but maybe @peternewman has a better idea of that.
Thanks for the review! An auto_ptr cannot be shared by copying it, so a unique_ptr should behave identical and not introduce the requirement for shared_ptrs. I saw places where raw pointers are stored, and a std::shared_ptr might be suitable in some of those cases, but I would not do that in a single pull request, as it changes the semantics (and there are higher chances of bugs).
I saw also quite a lot of places where a std::unique_ptr is released using release(), and the raw pointer is subsequently passed to a function or stored inside a class. Also in those cases, using c++11 there is probably a method to avoid moving around such raw pointers. On the other hand it all works, so why change that.
I saw you approved the pull request, but I can't merge, so someone else would have to do that.
I saw places where raw pointers are stored, and a
std::shared_ptrmight be suitable in some of those cases, but I would not do that in a single pull request, as it changes the semantics (and there are higher chances of bugs).
Yeah this is what I meant but I agree that should be a separate pull.
I saw you approved the pull request, but I can't merge, so someone else would have to do that.
That would most likely be @peternewman
@peternewman Would you want to apply these changes at some point or should I throw away the branch?
@peternewman: I'd also vote for this PR. All those auto_ptr generate quite some compiler warnings by now
