Move semantics for Grid (and Tree?)

[BenFrantzDale]

As far as I can tell, openvdb::Grid holds a std::shared_ptr<Tree>. I haven't figured out why the tree needs to be shared (shared non-const is scary!) but at very least that means Grid should be movable.

Describe the solution you'd like

I think this is just a matter of

GridBase(GridBase&&) = default;
GridBase& operator=(GridBase&&) = default;

and

Grid(Grid&&) = default;
Grid& operator=(Grid&&) = default;

I suspect TreeBase, Tree, RootNode, and InternalNode could get the same treatment. (LeafNode too although that only matters if people are storing things in leaves that allocate on the heap, so that's probably silly.)

Describe alternatives you've considered

At present, the use pattern seems to be very focused on shared pointers to mutable structures. (I've been watching a bunch of Sean Parent talks recently, and he rants about shared_ptr to mutable, particularly in the context of reasoning about thread safety.) There are lots of places (I think!) that I could avoid the extra allocation and get the value semantics and thread safety of a regular type.

Would y'all be open to a PR making the above additions?

[danrbailey]

I don't have a strong opinion on adding move semantics or not, I think we've briefly discussed this in the past but the benefits seemed fairly small for the tree hierarchy or otherwise the changes required to take advantage of this would have meant a significant change to ABI which we steered away from.

I can at least speak to the purpose of the std::shared_ptr<Tree> however, as the Tree can be shared by multiple Grids for cases where you might want the same voxel data but a different transform for instancing as an example.

[BenFrantzDale]

I sketched it out, including tests: https://github.com/AcademySoftwareFoundation/openvdb/compare/master...BenFrantzDale:add-move-semantics?expand=1

I didn't go all the way down the tree. Thoughts?