lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Really 'delete' what wxMenuBar::Remove() returns?


From: Vadim Zeitlin
Subject: Re: [lmi] Really 'delete' what wxMenuBar::Remove() returns?
Date: Fri, 1 Jun 2007 23:15:19 +0200

On Mon, 28 May 2007 22:32:38 +0000 Greg Chicares <address@hidden> wrote:

GC> http://cvs.savannah.gnu.org/viewvc/lmi/lmi/main_wx.cpp?r1=1.74&r2=1.75
GC> 
GC> I'm troubled by this line that I recently wrote:
GC>   delete menu_bar.Remove(test_menu_index);
GC> To 'delete' anything I didn't create with 'new' myself
GC> just seems so unusual that I'd like to ask the experts,
GC> even though I'm pretty sure that's what the manual means:
GC> 
GC>   http://www.wxwidgets.org/manuals/stable/wx_wxmenubar.html#wxmenubarremove
GC> 
GC> "returns the menu object - the caller is responsible for deleting it."

 Yes, you're indeed supposed to delete the returned object.

GC> The whole menubar, BTW, comes from a wxxrc resource.
GC> Typically I call wxXmlResource::LoadMenuBar() several
GC> times to get equivalent menubars from the same resource,
GC> and 'delete' this menu on each one. I have not observed
GC> any problem.

 There shouldn't be any, as all the objects are created with the operator
new by the library.

GC> Would it make sense to add a companion function
GC> wxMenuBar::Destroy(), just as class wxMenu has Destroy()
GC> as well as Remove()?

 To be honest I don't think it would be really helpful as it would do
nothing other than deleting the pointer but could actually confuse matters
and would also prevent you from using std::auto_ptr and similar classes
(e.g. boost smart pointers) for the life-time management of wxMenu objects
(suppose you wanted to keep the menu you removed in order to possibly
insert it back later).

 As for the argument that deleting something you didn't allocate is
unusual, I don't really see it as much different from leaving the library
to delete the objects you allocate and this happens with all window
objects. So while I fully agree that the current situation is not ideal,
the only real solution would be to replace all pointers with smart pointer
like objects and avoid any calls to new/delete at all. Changing it just
here wouldn't make much difference IMHO.

 Regards,
VZ





reply via email to

[Prev in Thread] Current Thread [Next in Thread]