* Shankar:
We have a smart pointer class which provides the dereference
operator -> to access the underlying object pointer. Now, we have a new
requirement where a different type of object (e.g from memory, disk,
network etc) needs to be returned by the smart pointer on access.
I was thinking of using the function call operator () since that can
take arguments e.g :-
RefPtr(FROM_DIS K)->getAttr1()
RefPtr(FROM_CAC HE)->getAttr1().
Seeking your opinion on any issues/pitfalls? Is there any more
expressive solution?
As described it seems to be an UnGood design, and then the technical
"solution" to realize the design doesn't matter; UnGood is UnGood.
A smart pointer's primary responsibility is to manage the lifetime of an
underlying object and provide access to that object. It might have
selectable policies related to lifetime management (e.g. reference counted,
intrusive) and object access (e.g. threading policy). What it doesn't do is
to manage a collection of different objects (that's better solved by having
the smart pointer manage a collection object), and furthermore, leaving it
up to the client code to select the "right" object from a collection of
objects representing conceptually the same, at any given time such an object
is needed, is probably a recipe for disaster.
If it's impossible to make the storage policy of the underlying object
transparent, i.e. the client code needs to know and use aspects of that
policy and treat different kinds of objects differently, then I suggest
using different types for different kinds of objects. That's what types are
for. If, on the other hand, there's nothing that different types can
contribute to the client code, the client code treats all such objects alike
as if of the same type, then use the same type and hide the storage policy.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?