Re: Hard API freeze soon

[Carl Nygard <cjnygard fast net>]

On Thu, 2005-02-24 at 19:15 +0100, Murray Cumming wrote:
> On Thu, 2005-02-24 at 13:11 -0500, Carl Nygard wrote:
> > On Thu, 2005-02-24 at 16:07 +0100, Murray Cumming wrote:
> > > On March 9th, we'll release gtkmm 2.6.0, as per the schedule:
> > > http://www.gnome.org/start/2.9/
> > > 
> > > We are already past the API freeze, but after March 9th there will
> > > really be absolutely no chance to change the API. So, please do
> > > experiment with the new 2.6 API now. See NEWS to see what's new.
> > > 
> > 
> > I'm not sure if this would be allowable, but would you consider adding:
> > 
> > Glib::RefPtr<T_CppObject>::operator T_CppObject*() const
> > 
> > I've found I needed to get the raw pointer on occasion,
> 
> Not until you tell us what the occasion is, because this would encourage
> people to do this when they shouldn't, leading to all kinds of confusion
> and brokenness. So far we know of none.

a) I want to print out the value, just for debugging purposes.
b) I want to pass the ref_ptr to a function taking the raw ptr

class MyScreen : public Gdk::Screen {}
class YourScreen : public Gdk::Screen {}

void FooFunction(Gdk::Screen* screen) {   //.... }


Glib::RefPtr<MyScreen> p;

cout << "ptr: " << (MyScreen*)p << endl;
FooFunction(p);


My alternative right now is:

cout << "ptr: " << (void*)p.operator->() << endl;
FooFunction(p.operator->());

My point is that I can write valid (and ugly) code to do the same thing,
I consider the cast operator (or get_ptr() if you want to be explicit)
syntactic sugar for something the API already allows.  

Most smart_ptr type implementations allow the use of the smart_ptr in
normal-ptr contexts, so long as you don't go destroying the pointer.

Regards,
Carl