Hello, wxruby-users.
I`m noticed huge GDI resources leakage when working with my programs
(on windows). Fortunately, i simple fix this by calling
''delete'' on
wxBitmap object (patch bellow). But i`m wondering -- why there are no
calls to destructors of wrapped wxwidgets objects in wxruby? Is there
some problems?
This is a patch:
===============================================================---
src/bitmap.cpp 30 Nov 2003 22:54:48 -0000 1.2
+++ src/bitmap.cpp 2 May 2005 11:11:58 -0000
@@ -32,10 +32,16 @@
rb_define_method(rubyClass, "convert_to_image",
VALUEFUNC(WxBitmap::ConvertToImage), 0);
}
+void WxBitmap_free(wxBitmap *bmp) {
+ if(bmp) {
+ delete bmp;
+ };
+};
+
VALUE
WxBitmap::alloc(VALUE self)
{
- return Data_Wrap_Struct(self, 0, 0, 0);
+ return Data_Wrap_Struct(self, 0, WxBitmap_free, 0);
}
VALUE
===============================================================
--
Dmitry mailto:dmiceman@ubiz.ru
Dmitry Morozhnikov wrote:> Hello, wxruby-users. > > I`m noticed huge GDI resources leakage when working with my programs > (on windows). Fortunately, i simple fix this by calling ''delete'' on > wxBitmap object (patch bellow). But i`m wondering -- why there are no > calls to destructors of wrapped wxwidgets objects in wxruby? Is there > some problems?This is a known problem with wxruby, and the plan has been to fix it by moving to wxruby-swig. Memory handling in a C++ wrapper library like wxruby is challenging. Sometimes the C++ system initiates the object creation, and a ruby object merely wraps it. Other times, the ruby object is created, causing the underlying C++ object to be created. Similarly, sometimes C++ initiates an object destruction, while other times it is initiated by Ruby. Sometimes the Ruby object goes away while the C++ object continues to exist. It''s all quite complex, and the current philosophy is that it is better to leak than to crash due to double-frees. SWIG automatically handles many of these cases. For those that it does not handle, it provides tools that allow you to write the memory management just once, and it can be applied to all the classes with no extra effort. Contrast that with current/old wxruby 0.6, where the memory handling must first be invented, and then applied to each individual class, manually. In fact, this is one of the most compelling reasons to shift to SWIG. Another big one is SWIG''s "directors", which make it super easy to support ruby methods overriding virtual C++ methods. Kevin
Hello, Kevin. You wrote 03.05.2005, 8:40:04: KS> This is a known problem with wxruby, and the plan has been to fix it by KS> moving to wxruby-swig. KS> Memory handling in a C++ wrapper library like wxruby is challenging. KS> Sometimes the C++ system initiates the object creation, and a ruby KS> object merely wraps it. Other times, the ruby object is created, causing KS> the underlying C++ object to be created. KS> Similarly, sometimes C++ initiates an object destruction, while other KS> times it is initiated by Ruby. Sometimes the Ruby object goes away while KS> the C++ object continues to exist. It''s all quite complex, and the KS> current philosophy is that it is better to leak than to crash due to KS> double-frees. Well.. I think it is still possible to implement calls to proper destructors with plain wxruby. I see no problems for at least wxBitmap. On the other side, recently i run into nightmare with Wx::Window.get_update_region with current wxruby code (something goes wrong with wxRegion, but i have not yet check this). KS> In fact, this is one of the most compelling reasons to shift to SWIG. KS> Another big one is SWIG''s "directors", which make it super easy to KS> support ruby methods overriding virtual C++ methods. :-) You convict me to look at swig again. Especially after today fighting with wxpp.rb, when i`m tried to implement correct wrapper for wxHtmlWindow::OnLinkClicked. -- Dmitry mailto:dmiceman@ubiz.ru
>KS> In fact, this is one of the most compelling reasons to shift to SWIG. >KS> Another big one is SWIG''s "directors", which make it super easy to >KS> support ruby methods overriding virtual C++ methods. > >:-) You convict me to look at swig again. Especially after today >fighting with wxpp.rb, when i`m tried to implement correct wrapper for >wxHtmlWindow::OnLinkClicked > >:) Definitely worth another look - once I had the toolchain set up and the basic idea figured out, I was able to get four or five Wx classes working in a few hours. I''ve added some more notes on the Wiki page about Hacking Wxruby-swig. cheers a