Copy constructor not being called on function return

Stuart Brooks stuartb@cat.co.za
Tue Nov 4 12:50:00 GMT 2008


John (Eljay) Love-Jensen wrote:
> 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.)
>
>   
Thanks Eljay. You're right, the ownership is muddled. In my specific 
case this is very powerful because it allows bulk data to be passed and 
either used immediately without requiring an expensive copy, or stored 
for later use in which case the allocation and copy happen 
transparently. It works well, I just hadn't counted on NRVO :-) I think 
the use of a finalise as you've suggested or an extractor which forces a 
copy are my best options, I'll just have to be rigorous in enforcing 
their use.

Thanks again for the responses, they're much appreciated.

Kind regards
 Stuart



More information about the Gcc-help mailing list