Your analysis is quite correct, I think. In this situation, I also would return a bare B*, or even a [const] B& if the object is guaranteed to never be null. Having had some time to peruse smart pointers, I arrived at some guidelines which tell me what to do in many cases: If you … Read more
Yes, it is possible to implement shared_ptr that way. Boost does and the C++11 standard also requires this behaviour. As an added flexibility shared_ptr manages more than just a reference counter. A so-called deleter is usually put into the same memory block that also contains the reference counters. But the fun part is that the … Read more
The direct replacement for auto_ptr (or the closest thing to one anyway) is unique_ptr. As far as the “problem” goes, it’s pretty simple: auto_ptr transfers ownership when it’s assigned. unique_ptr also transfers ownership, but thanks to codification of move semantics and the magic of rvalue references, it can do so considerably more naturally. It also … Read more
There are at least three places where you may find shared_ptr: If your C++ implementation supports C++11 (or at least the C++11 shared_ptr), then std::shared_ptr will be defined in <memory>. If your C++ implementation supports the C++ TR1 library extensions, then std::tr1::shared_ptr will likely be in <memory> (Microsoft Visual C++) or <tr1/memory> (g++’s libstdc++). Boost … Read more
1. I’m wondering if there is a non-atomic version of std::shared_ptr available Not provided by the standard. There may well be one provided by a “3rd party” library. Indeed, prior to C++11, and prior to Boost, it seemed like everyone wrote their own reference counted smart pointer (including myself). 2. My second question is why … Read more
Return smart pointers by value. As you’ve said, if you return it by reference, you won’t properly increment the reference count, which opens up the risk of deleting something at the improper time. That alone should be enough reason to not return by reference. Interfaces should be robust. The cost concern is nowadays moot thanks … Read more
Simple C++ Model In most modules I saw, by default, it was assumed that receiving pointers was not receiving ownership. In fact, functions/methods abandoning ownership of a pointer were both very rare and explicitly expressed that fact in their documentation. This model assumes that the user is owner only of what he/she explicitly allocates. Everything … Read more
C++03 std::auto_ptr – Perhaps one of the originals it suffered from first draft syndrome only providing limited garbage collection facilities. The first downside being that it calls delete upon destruction making them unacceptable for holding array allocated objects (new[]). It takes ownership of the pointer so two auto pointers shouldn’t contain the same object. Assignment … Read more
This will also happen if you’ve forgotten to specify public inheritance on the derived class, i.e. if like me you write this: class Derived : Base { }; Instead of: class Derived : public Base { };
std::unique_ptr has memory overhead only if you provide it with some non-trivial deleter. std::shared_ptr always has memory overhead for reference counter, though it is very small. std::unique_ptr has time overhead only during constructor (if it has to copy the provided deleter and/or null-initialize the pointer) and during destructor (to destroy the owned object). std::shared_ptr has … Read more