Re: gtkmm 3.0.



On Thu, 2010-03-25 at 14:58 -0500, Jonathon Jongsma wrote:
> For example, the following commonly-used one-liner:
> tree_view.get_selection()->set_mode(...);
> 
> would become (without validity-checking):
> tree_view.get_selection().lock()->set_mode(...);

Sorry, what does that lock() do in this case?

I don't see how anything gtkmm can do could stop a Treeselection from
being invalid/ineffective after the TreeView has been deleted.


Also, I understand the previous examples that check before
dereferencing, but I'm concerned that any part of my code could
potentially cause the TreeView to be deleted, so all my code will look
like this

if(ptr)
  ptr->do_something();
if(ptr)
  ptr->do_next_thing();
if(ptr)
  ptr->do_third_thing();

And that will be particularly awful when it forces us to declare
variables apart form their initialization, and make special efforts to
always clean up properly.
 
> which isn't much more typing but is significantly less pleasant to
> look
> at.  If you actually checked the pointer before using it, you'd get
> something more like the first example above. 

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]