Re: Problem with Gtk::manage in Visual Studio 2008

[klaus triendl <klaus triendl eu>]

Pedro Sousa schrieb:
> Yes, I'm using the correct version of the Property Sheet, file
> gtkmm-vc90-2_4 and gtkmm-vc90-d-2_4 for the Visual Studio 2008.

This error happens because one module (exe/dll) allocated memory which 
is then freed in another module.
So in your case I suppose that the Gtk::VBox is created in your exe but 
freed in the gtkmm module or its dependent modules.


1) gtkmm uses the dynamic runtime

Did you follow the instruction on http://live.gnome.org/gtkmm/MSWindows 
to use the "Multi-threaded Debug" runtime, which is the static runtime?
As far as I can tell this is incorrect because gtkmm was linked against 
the dynamic runtime library.
To solve your problem use the dynamic runtime - "Multi-threaded Debug" 
for the Debug configuration or "Multi-threaded Release" for the Release 
configuration.


2) c++ doesn't have yet a model for modules with different address spaces

The instructions for MSVC say that it is necessary to use the same 
runtime as gtkmm does and this might be necessary for various reasons - 
which should be clearly documented I think because it isn't strictly 
necessary to use the same runtime in your program like the dlls you link to.
One thing to ensure is as I indicated above that memory allocated in one 
module should be deallocated in that very same module - it always 
depends on your needs but I believe that this is an important good practice.
Glibmm/Gtkmm classes should have their own memory management functions 
(operator new/operator delete - sigc has it btw).
Also Glib::ustring and other classes handling resources are subject to 
the same-module requirement.
If you use the same dynamic runtime like all modules for your program as 
gtkmm obviously assumes then there is no problem because all modules use 
e.g. the msvcp90.dll and msvcr90.dll. But if you have modules that link 
against their own static runtime and modules that use other dynamic 
runtimes (like msvcp80.dll and msvcr80.dll) those module-bound 
allocation/deallocation operations are important.


Maybe a gtkmm developer can comment on this?


Klaus