Question

Glib::RefPtr allows dereferencing via ‘->‘ but not via ‘*‘. Why is this?

I can of course do:

 class Foo {};
 Glib::RefPtr<Foo> fooPtr;

 fooPtr.operator->();

The docs specifically mention that they left operator*() out. But they do not offer any guidance as to why.

Edited with example for clarity:

I’ve seen it argued that “you should never need to dereference” a RefPtr, but IMO that seems bogus counterintuitive as any function that wants to be used with both dynamically and stack allocated objects would need the lowest common denominator interface, i.e. pass-by-reference.

Take, for instance the following example:

struct Foo 
{ 
    void print() { printf( "Success" ); } 
};

void myFunc( const Foo & foo ) { foo.print(); }

int main()
{
    Foo               foo0;
    Glib::RefPtr<Foo> foo1Ptr( new Foo );

    myFunc(  foo0    );
    myFunc( *foo1Ptr ); // error, no operator*()

    return 0;
}

Anyone know why this position is taken by the Glib team?

Answer 1

Some functions may take objects, or object references as args.

No, if an object should be used via a RefPtr, then no function will (or no function should) take it without RefPtr. Not having operator* avoids people doing this, meaning that APIs are forced to be correct, meaning that there are less memory management errors due to not using RefPtr. It’s not there because people would misuse it, and people have a hard enough time getting the hang of smartpointers already.

If you have a real problem that you think would be solved by a RefPtr::operator*(), then you might mention the actual problem so we can (probably) show how you don’t really want to use operator*() there.