Hi Stuart,
> Can anyone think of a more elegant way of managing this, and is there a way of determining at compile-time whether a compiler supports NRVO?
I realize your example is simplified to illustrate the problem, so my answer that follows is not generally applicable. But I hope the gist of the concept is evident.
I'd write someFunc this way:
std::vector<char> someFunc()
{
std::vector<char> some_data(100);
return some_data;
}
That way you don't get into the situation of having NVRO messing up your memory ownership. The smart pointer -- in this case, the vector -- owns the array memory.
The situation you present is a smart pointer with muddled ownership, and uses a side-effect in the copy-constructor to... umm (I don't have a word for it)... "finalize" the memory ownership. (Yes, what you are doing is a side-effect, because if the SUBROUTINE's constructor is built in-place where the CALLER'S SmartPtr is located, thus eliding the unnecessary copy-constructor -- i.e., NVRO -- which makes a bug in how you've got it plumbed up.)
Alternatively, trying to keep your SmartPtr mostly as is, I'd have it used this way by adding another method:
SmartPtr someFunc()
{
char some_data[100];
SmartPtr smart_ptr;
smart_ptr.setConst(some_data, sizeof some_data);
//...
smart_ptr.finalize(); // makes its own copy instead of borrowed "ownership".
return smart_ptr;
}
The downside is remembering to call that routine which makes its own allocation which the SmartPtr then really owns and manages.
Sincerely,
--Eljay
