[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtkmm
Subject:    Re: [Fwd: [gtkmm] Changelog clarification: Menu elements 'clipable']
From:       Karl Nelson <kenelson () ece ! ucdavis ! edu>
Date:       2002-01-28 17:18:04
[Download RAW message or body]

> On Fri, 2002-01-25 at 23:17, Karl Nelson wrote:
> > > On Fri, 2002-01-25 at 22:34, Karl Nelson wrote:
> > > > Many users are likely to need to use RefPtr<> on Widget especially
> > > > when they want to "move" widgets from one container to another.
> > > 
> > > There's Widget::reparent(). Do you have other examples?
> > 
> > I am sure others can come up with examples.  Reparenting or
> > more generally taking an item out of a container and doing
> > something with it is a fairly common action in advanced codes.
> 
> I'm willing to accept that possiblity, but I'd like to know about some
> of those examples, and it looks like forcing people to complain might be
> the best way to get told about them.

Well I registered the first complaint.  It simply isn't possible
to use Glib::RefPtr on MenuItem in any meaningfull way.  You can't
add them to the container without operator * and you can't 
assign them after initialization without operator =.



> > Also making exception safe code requires a proper pointer class.
> > 
> >    { 
> >      Gtk::Button* b=manage(new Gtk::Button);
> > 
> >      /*... do something */  // exception may happen
> > 
> >      window.add(*button);
> >    }
> > 
> > Thus RefPtr is needed here.  HOWEVER, to be absolutely clear
> > I don't want to consider the solution which Havoc proposed which
> > was to force RefPtr everywhere.
> 
> I think it might be easier for people to write smaller try/catch blocks
> and do appropriate cleanups here, rather than tell them to use a RefPtr.
> If they start trusting a big try/catch then they'll have to start using
> RefPtr everywhere.

There are far more cases than that above.  You can get into places
like the above if the ctor throws an exception as well and does not
place the thing it is building into the container window as well.
Trying to force the user to "code correctly", is not a good idea. 
We can make the interfaces as safe as possible under expected 
use and warn them what is not acceptable.  

Forcing RefPtr<> is really slow because you will reference every
use once it is placed in the container.  It is annoying and slow.




 
> > A non-full pointer class is way too strict.   I wouldn't injure the
> > interface in such without finding out if users don't know of uses
> > beyond what you anticipate.  
> 
> Until I discover what those needs might be, I'm inclined to reply with
> my normal 'Use gobj() and the C API if you need to, and tell us so we
> can wrap it properly in future'.

gobj() won't work in the MenuElement interface either.  It must
be a reference class.



> > (Not to mention the user can always get the pointer with 
> >   Foo* f=ptr.operator->();  
> > so sheilding it is such a fashion is totally artifical.)
> 
> As I've tried to make clear in comments whenever I've used that hack, I
> think it's OK because people would see clearly that's we don't intend it
> to be used like that.

If you have to use that hack then the pointer class is broken.  
(I am not even sure the above is portable.)  If you must not
have operator* then give a   .ptr() method which has documentation
that you can't delete the resulting pointer.



> > > RefPtr isn't meant to be a generic smartpointer - it's meant to prevent
> > > access to the underlying pointer.
> > 
> > What danger could you do with the underlaying pointer?  I see very little
> > other than holding the pointer without reference, but then that is
> > needed to establish relationships like parent.  It you have no
> > way to use anything but RefPtr you will force the user to create 
> > referencing loops, thus forcing them to create memory leaks.  
> 
> They could delete the underlying C++ instance - something which the
> RefPtr is designed to prevent. They could end up with invalid pointers -
> something that's more likely with these objects than others.

They can always delete the underlaying implementation.  Even if it
is on the stack.  It is a error and they deserve the seg fault.
You are trying to be java and protect the user from using powerful 
tools.  (BTW have you ever read the short story "With Folded Hands".)



> > None of the gtkmm interfaces use Glib::Object* and thus unless you
> > are trying to do something "advanced" you would have no reason
> > whatsoever to access one.  Further, (*f). is used by STL because
> > iterators don't have f-> so you are going to rule out much more
> > than you intend.
> 
> Can you give me an example of what's not possible now? We are using
> RefPtr<>s in STL container already.

I believe some of the algorithms may call (*i). but then I haven't
looked through the current implementations well.  Do notice that
vector::iterator and other STL stuff implement only operator * and 
not operator ->  thus our pointer class is against the grain.

 
 
> > Can I ask what potential problems you see for a full pointer class?
> 
> If we become as successful as I think we're going to be then we can
> expect all kinds of clueless coders to pit their wits against our
> interfaces. I can imagine people not understanding the smartpointer idea
> and trying to bypass it. And if we say that it's just a generic
> smartpointer then people will feel that they have the choice not to use
> it.
> 
> What I'm trying to avoid is the horror that I remember from working with
> the various Micorosoft COM wrappers and frameworks. Inconsistencies were
> often overcome by the occasional extra ref, and as soon as something did
> that kind of local fix it destroyed the whole scheme until everybody
> starts refing and unrefing all over the place until it just works, until
> somebody else does an extra ref/unref and breaks it. If I can say 'Just
> use the RefPtr and trust it, because we've thought of everything' then
> maybe we can avoid that. It's a lofty goal, I know.

Yes, and thus RefPtr really should work on Gtk::Widget and be usable.
I changed over MenuElement to specifically solve a memory leak.  I
thought it would be a 2 minute job as you have a fairly complete
RefPtr.  (Almost checked in without compiling it seemed such a 
trivial change.)  However, when I compiled it it broke in dozens of places
because it was too restrictive.  If I was an average user I would
have given up on RefPtr and done something different (and thus
still have the leak).  



> > I do what to state the alternative.  If Glib::RefPtr<> is not a
> > full pointer than advanced codes will need to use something other
> > than RefPtr<> for manipulation Widgets.
> 
> I have considered that but I think it would be silly and involve a lot
> of code duplication. If the need is proved then I'd prefer to open up
> RefPtr as you propose.

SigC::Ptr<> is already there so there is no replication.  I could
safely use it internally to gtkmm.  It is just that I think that
would confuse users more.


 
> I want to consider this point unresolved. I think that by restricting
> the API in the short term we will learn about considerations for the
> long term, whereas by opening it now for theoretical reasons we will
> never know whether the needs were real.

If you restrict it then you get to try to solve the memory leak in
the Element Interfaces.  I mean this in a friendly way, not
as "If you do Y, I won't code X."   Simply I don't think I can
get my point across without you trying to see for yourself 
where RefPtr restrictions get to be a pain.  For my part I will try
to find those leaks and get you a list so you can look at them.
There were a number of them at one point, but some I fixed by
other means.  (Gnome::Stock stuff)


--Karl

_______________________________________________
to unsubscribe or change your subscription parameters :
https://lists.sourceforge.net/lists/listinfo/gtkmm-main
[prev in list] [next in list] [prev in thread] [next in thread]