Replace auto_ptr by unique_ptr

[aroffringa]

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.

[DaAwesomeP]

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.

[aroffringa]

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.

[DaAwesomeP]

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).

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

[DaAwesomeP]

@peternewman thoughts on this PR?

[aroffringa]

@peternewman Would you want to apply these changes at some point or should I throw away the branch?

[kripton]

@peternewman: I'd also vote for this PR. All those auto_ptr generate quite some compiler warnings by now

[aroffringa]

@peternewman can you please merge this PR?