David Williams wrote:
For normal C++ I therefore think the copy constructor should be defined to prevent the compiler creating one, but made protected to prevent the user from calling it. I guess the same would be true of the assignment operator? Does this have any negative implications?
I believe this is the standard way of making a class non-copyable (like is done in
boost::noncopyable) and so I think it would be appropriate here. If we make this change (I guess we could make it before the 0.2 release) we should be sure to add a little documentation showing how to manually copy a volume using the sampler (or perhaps add an explicit
clone() method to the class).
David Williams wrote:
For C++11:
I'm not familier enough with move semantics and rvalue references to know whether a move constructor would still be appropriate or beneficial after the above changes had been made... so I'll leave that discussion to those who have more idea. If it's a good idea then we can include one.
I think that a move constructor would be very useful as it would allow the user to do things like pass it to functions or store it in standard library containers (as long as they explicitly move it there).
While it has been suggested (by Scott Meyers no less) that move constructors should just be seen as an optimisation on top of copy constructors, I think that in this case we're using the different semantics of the two to help define our API and recommended usage.
