I'd say that that is probably the correct path, but really it depends on the intent of the interface.
Therefore, the pointers in the class should be shared_ptr and return weak_ptr, right?
Would there actually [...] to it to be returned?
How would you manage this without using the same pattern as 'shared_ptr'/'weak_ptr'? It would be cheaper, but beyond that?!
No. You may change the design in other ways if you wish, but if the object should own a resource, it is almost certainly going to be useless if associated with an unavailable resource. It would seem pointless for the 'pipe' to exist without a 'pipe_buffer' if the 'pipe' exists solely to write to the 'pipe_buffer'.
Should the creator of the resources assume ownership and lend non-owning pointers to the object X?
You should not be afraid of 'auto_ptr'/'unique_ptr' and friends--with 'unique_ptr' the obvious preference. (This interface naturally implies, and almost requires, that the object will obtain ownership.)
So far as I can tell, there is no way for object X to acquire ownership properly.
I use one of the possible library implementation of 'move' semantics. (My implementation is spitting distance from being a C++0x compatible 'unique_ptr'.)
So how does one usually do this?
How are we supposed to know? This is like asking: "Is the 'Singleton' pattern flawed?". It is the mechanic that makes the design fit or unfit for a particular purpose.
Is the design flawed?
Yes. No. Maybe. I don't like it. It isn't verbose; it doesn't explain the situation.
Is this a good solution?
Pass a "null deleter" to any of the new smart pointers that support "custom deleters"--my vote for 'shared_ptr' as it would lend context.
Is there any smart pointers for this purpose?