Chris Just wrote:
Jonathan Turkanis wrote:
Declaring a function to take an argument of type auto_ptr<...> is one way to signal that ownership is being transfered to the function. It also ensures that the managed object will be deleted, unless the function takes explicit steps to cause a leak. Passing raw pointers defeats this system.
Yes, this is true if you're calling a function that you wrote and compiled yourself, but if you're calling a 3rd party API that you didn't compile yourself, that can be dangerous (or so I've been told).
Dangeous how? Actually the opposite is true: if you declare such a function to take a raw pointer,
I'm not an expert with compilers so I'll tell you how it was explained to me. Different compilers could take the same C++ code and compile it into different machine code, causing function pointers to shift. When you pass an object that was compiled on one machine to a function that was compiled on another machine, you can't be sure that the object will be deleted properly.
I guess you're talking about passing objects between modules compiled with compilers having incompatible ABIs. In general this is a recipe for disaster. If you restrict yourself to a C language interface you often have more flexibility, but in that case you can't use smart pointers. Is this what you mean? At any rate, we've strayed considerably from the main point.
callers might think they still own the pointer after calling the function, or the function might not clean up the resource properly.
That's what documentation is for.
Self-documenting code is much better, especially if violations of the contract fail to compile. Jonathan