ENH: Use std::move instead of boost::move

Summary

Use the standard library move function.

Rationale

We're on C++14, so we can just the standard library move function.

Also, avoid calling move in cases where it's actually a pessimization, see e.g. https://reviews.llvm.org/D7633.

Additional notes

r? @lhermitte

Copyright

The copyright owner is Laurențiu Nicola / CS ROMANIA and has signed the ORFEO ToolBox Contributor License Agreement.

---

Check before merging:

• All discussions are resolved
• At least 2 votes from core developers, no vote.
• The feature branch is (reasonably) up-to-date with the base branch
• Dashboard is green
• Copyright owner has signed the ORFEO ToolBox Contributor License Agreement
• Optionally, run git diff develop... -U0 --no-color | clang-format-diff.py -p1 -i on latest changes and commit

added refactoring label

changed the description

Seems fine to me. I don't remember why I (/we?) used move when returning from functions -- which is indeed a bad practice 99% of the time.

That might be the oldest C++11 code in OTB, I wouldn't sweat over it. But it does seem surprisingly convoluted.

I did start it for C++98 in mind (hence boost unique_ptr at the time), and I wanted to hide OGR raw pointers as much as possible.

I guess we can wait for the release before merging this, since it's just a cleanup?

This can be merged.

This won't be in the release as the target branch is develop and the release-7.1 has already been created !

merged

mentioned in commit 5583b6bb

Did this really break ioTvMultiDatasetReading1 and ioTvMultiDatasetReading2 on Debian Testing?

changed milestone to %8.0.0

changed milestone to %7.2.0