1. I thought this was not the only thing stopping us from using
Glib::RefPtr with Gtk::Object derived classes.

2. You still need to give an example of when it would be necessary or
useful. I wouldn't want to add the confusion without gaining anything.

I still have no answers to these questions.

I don't see any use for this until we can use RefPtr with
Gtk::Object-derived classes. Apparently the problem with that is that
the Gtk::Object can be destroyed even when there are outstanding
references.

Providing operator*() for RefPtr<> allows appropriate access to
operators of the referenced object, e.g.:

(*ptr) += some_value;
++(*ptr);
value = (*ptr)[index];

Even though there are currently no operators for any classes derived
from SigC::Object, this would make it much more practical to create
some in the future. I'm sure there are practical uses for operators
for a variety of glibmm classes.

While I can understand the original motivation for not supporting the
operator (presumably it was to avoid having programmers take and keep
"dumb" references to the referenced object; I did the same thing the
first time I wrote a smart pointer class) it really doesn't have that
effect, because anyone with a little savvy can just do something like
"pointer = ptr.operator->()" which is dirty and ugly. You're better
off removing their motivation to do that by providing the
dereferencing operator so that RefPtr<> behaves as much like a
built-in pointer type as possible.

Yes, I know that it would be useful if RefPtr<> could be used with
non-Glib::Object classes. But until it can, I see no need for it. I
see no reason to add something that should never be used.

I guess I didn't make my point effectively enough. There are basically
two reasons, having nothing to do with using RefPtr with
non-Glib::Object classes, why the dereferencing operator is useful:

1) It would make it feasible to add operators to Glib::Object-based
classes.
2) It would discourage people from using the much uglier
ptr.operator->() mechanism to get at the referenced object directly.

> 1) It would make it feasible to add operators to Glib::Object-based
> classes.

I don't understand. What would be added to what?

> 2) It would discourage people from using the much uglier
> ptr.operator->() mechanism to get at the referenced object directly.

You have not yet shown that it is necessary for anyone to use either
operator* or the uglier operator-> mechanism.

>> 1) It would make it feasible to add operators to Glib::Object-based
>> classes.
>
>I don't understand. What would be added to what?

I'm not suggesting any specific changes. I'm just saying that it would
make it feasible to exploit operators in the Glib::Object hierarchy.
Facilitating a highly useful programming technique seems to me to be a
good reason to have the dereferencing operator, even if it isn't going
to be used immediately.

>> 2) It would discourage people from using the much uglier
>> ptr.operator->() mechanism to get at the referenced object >directly.
>
>You have not yet shown that it is necessary for anyone to use either
>operator* or the uglier operator-> mechanism.

Nope, that's true. But you can't stop people from doing it if they are
determined to do so. If you make it possible to use the operator*
technique rather than the operator-> technique, then I suspect the
tendency to abuse them would be reduced. I expect that people using
the operator-> hack would be more likely to keep long-lived copies of
the dumb pointer, whereas if they can use the operator* to quickly and
succinctly get very short-lived references to the object, then they're
less likely to abuse them.

>> 1) It would make it feasible to add operators to Glib::Object-based
>> classes.
>
>I don't understand. What would be added to what?

I'm not suggesting any specific changes. I'm just saying that it would
make it feasible to exploit operators in the Glib::Object hierarchy.

Do you mean "make it feasible to add operator overrides to
Glib::Object-derived classes"? I can't think of any time when that
would be useful. Again, until we actually need it, I see no need to 
confuse the RefPtr API.

> But you can't stop people from doing it if they are
> determined to do so.
Yes, and those people know that they are doing something wrong and can
deal with the consequences.

I'm closing this bug because, still, nobody has suggested a real-world situation
in which anyone needs access to the underlying instance. Daniel might know of
such a case, in which case he should reopen this bug.