Smart Pointer Parameters

 

	Comment on GotW #91 Solution: Smart Pointer Parameters by earwicker And again, refer to Herb’s section that spans “2. What are the correctness implications… but in this respect it's no different than any other aliased object.)” He is not talking at all about the internal state of the pointed-to object at all. He’s talking only about “lifetime”, how it seems that “taking a copy of the shared_ptr guarantees that the function itself holds a strong refcount on the owned object, and that therefore the object will remain alive for the duration of the function body, or until the function itself chooses to modify its parameter.” But he goes on: “However, we already get this for free… (except we don’t)” I elided/paraphrased that last part, but quite adequately. Hence just as there’s no need to mention threads, there’s also no need to suppose some mutable state of the pointed-to object. The entire point here is purely and only about the lifetime of the object, as controlled by the one-or-more shared_ptrs that point to it. To make this absolutely concrete: what if the pointed-to object is immutable? Say we read a big map-of-strings-to-strings from a JSON file, and then encapsulate it inside a Config class that only allows read access to the map. This means that once loaded, we can safely share our single Config instance around (between threads or otherwise) and know its contents won’t get mutated. But we want it to be deleted when no longer in use. It’s a perfect application for shared_ptr. Even though the Config is visible from multiple places, no one can modify it, and so the only additional guarantee we need is that it won’t get destroyed at the wrong time. Read More » Comment on GotW #91 Solution: Smart Pointer Parameters by GregM Given that what you want is exactly what you get here, then we all agree. Thanks for your time. Goodbye. Read More » Comment on GotW #91 Solution: Smart Pointer Parameters by earwicker GregM, i that’s what you took away from my last comment, then obviously I worded it extraordinarily badly. I apologise! Thanks for the effort anyway. In case anyone else might still be interested, I have an issue with the advice offered in “2. What are the correctness implications…" - Object is being managed by a shared_ptr - Advice: we should pass a raw pointer to that object to some function - Caveat: “Note this assumes the pointer is not aliased” - The raw pointer we passed to the function is itself an alias of the original pointer. So we can follow this advice as long as we don’t follow this advice? Read More » Comment on GotW #93 Solution: Auto Variables, Part 2 by Anders Dalvander It would be cute to be able to write: for (auto s = v.size(), i = {}; i < s; i += 2) But `auto` doesn’t like {}, which is understandable in the simple case auto i = {}; , but here the type can be implied by `s`. Read More »