Re: Two questions about using shared_ptr
"CppBoy" <aert_fudan@online.hotmail.com> wrote in message
news:F4E8DD51-06EB-4286-A9F2-27722FF3F331@microsoft.com
1. How to deal with cyclic reference scenario using shared_ptr?
You avoid it. If you absolutely cannot avoid it, you use weak_ptr, or
just raw pointer, to break it.
I think cyclic referencing is quite common in programming. For
example, for the tree structure, the parent node has a shared_ptr to
the child nodes, while the child node also has a backward shared_ptr
points to its parent node.
shared_ptr usually reflects ownership. Typically, a parent node owns its
child nodes, but child nodes don't own their parent node. So they can as
well refer to it by a raw pointer.
2. To ensure good interface as recommended by Scott Meyers in
Effective C++, I normally wrote the function interface as:
void f(shared_ptr<T> pObj);
I would only do this if f() is supposed to take ownership of the object.
Otherwise I'd just take raw pointer.
An example like this makes more sense:
shared_ptr<T> makeNewT();
This interface forces the client developer to use RAII which is good.
But poor developer may wrap the stack based object address with
shared_ptr and pass into the function which caused disaster.
Well, presumably if the function takes shared_ptr<T> as a parameter, it
requires an object allocated on the heap, for whatever reason. Poor
developers shouldn't go around violating preconditions. On the flip
side, library authors shouldn't go around requiring more than they
actually need, just because they've just stumbled on a cool new
technology.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925