On 12/23/2014 10:48 AM, L. David Baron wrote: > Our convention has always been to pass raw pointers, generally with > the assumption that the caller is expected to ensure the pointer > lives across the function call.
Like Eric, I would like us to move away from this convention over time, or at least stay away from it in the places that are fresher and better-adjusted. > Passing references to smart pointers doesn't work if you need > implicit conversions from derived class to base class (e.g., if the > function takes Base*, and the caller has nsRefPtr<Derived>), which > is pretty important in many areas of our codebase. Passing references to smart pointers is also mildly more expensive because you have an extra dereference operation, in the general case. But that almost certainly far outweighs not addrefing/releasing through even a well-predicted vtable, as you go on to say. Really, tho, I don't think we have to forego a smart pointer argument type. We just need a separate smart pointer type ArgumentPtr<T> (name not seriously proposed, just to have a handle on the concept), implicitly constructible from the various smart pointer types of U, where U derives from T. And concerning the binary compatibility argument -- which I don't think really matters any more, and if it does a11y could have its own MSCOM smart pointer class for its own special-snowflake uses -- it seems fairly likely to me that there's a smart pointer class that could preserve that binary compatibility. Although I haven't investigated deeply to conclude so for sure. Jeff _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
