Using the () operator for dereferencing a smart pointer

[Shankar]

Hello,

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_DISK)->getAttr1()
RefPtr(FROM_CACHE)->getAttr1().

Seeking your opinion on any issues/pitfalls? Is there any more
expressive solution?

Thanks.

 

[Alf P. Steinbach]

* 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_DISK)->getAttr1()
RefPtr(FROM_CACHE)->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.

 

[Joe Seigh]

Hello,

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_DISK)->getAttr1()
RefPtr(FROM_CACHE)->getAttr1().

Seeking your opinion on any issues/pitfalls? Is there any more
expressive solution?

If you're using the smart pointer to manage the caching then just
reassigning the pointer from the pointer to the most recent copy
should work, e.g.

RefPtr = globalPtr(); // get lastest disk version

 

[benben]

Hello,

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_DISK)->getAttr1()
RefPtr(FROM_CACHE)->getAttr1().

Seeking your opinion on any issues/pitfalls? Is there any more
expressive solution?

Thanks.

It really doesn't go with the pointer semantics. And in such situation you
always have a better choice to make everything explicit. Use ordinary
functions or member functions:

template <typename T>
T* get_from_disk();

template <typename T>
T* get_from_cache();

I don't quite get what you want to achieve but I hope this might be a little
helpful.

Regards,
Ben

 

[Mercator]

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_DISK)->getAttr1()
RefPtr(FROM_CACHE)->getAttr1().

The C++ language is, after all, a language. Would others understand
what you are trying to say?

 

[Vijai Kalyan]

I am wondering if a better design might not be to use different types
for the different functionality (disk, cache etc) and require them to
implement the same interface. The smart pointer can store a pointer to
the interface. Virtual inheritance should solve the issue of invoking
the appropriate methods. Here goes:

class ProtectedObject
{
public:
virtual void foo() = 0;
virtual void bar() = 0;
};

class Disk : public ProtectedObject
{
};

class Cache : public ProtectedObject
{
};

class SmartPointer
{
friend class Disk;
friend class Cache;
public:
ProtectedObject* operator->();
protected:
SmartPointer(ProtectedObject*);
~SmartPointer();
private:
ProtectedObject* m_object;
};

-vijai.

 

[Greg]

Hello,

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_DISK)->getAttr1()
RefPtr(FROM_CACHE)->getAttr1().

Seeking your opinion on any issues/pitfalls? Is there any more
expressive solution?

Thanks.

Not to put too fine a point on it, but overloading the function call
operator for this purpose is a truly terrible idea, guaranteed to cause
no end of side effects and confusion between the () operator and
parentheses that are being used for other reasons.

I think that a sensible approach is to have global accessor functions
that extract the desired information from the passed-in values. For
example, implementing GetDiskPtr() and GetCachePtr() helper functions
like this::

GetDiskPtr( refPtr )->GetAttr1();
GetCachePtr( refPtr )->GetAttr1();

I do have one more suggestion: Try to use complete words (or well-known
acroynyms) in function names. "GetAttr1()" conveys little to me about
the purpose of the routine and even less to help me know when to call
it instead of GetAttr2(). And unless your compiler vendor charges you
by each letter in a routine's name, I see little downside in more
descriptive names. True, longer names may take a little more time to
type - but contrary to the thinking in some circles, their presence is
unlikely to slow the program down.

Greg