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

[Armin Burgmeier <armin arbur net>]

On Sat, 2008-12-20 at 16:55 +0100, klaus triendl wrote:
> 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.

You might be right here. I'll change the Wiki page accordingly if Pedro
confirms that this is the problem he's experiencing.

> 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.

I'd actually like to keep this section quite simple, without too much
complication. If people use the same runtime everywhere, then things
will work fine. As soon as someone violates that rule, they must know
what they are doing.

> 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.

I don't think we can guarantee this for gtkmm. For example, the whole
point of Gtk::manage is that the caller creates the object, but
delegates ownership to gtkmm.

> Glibmm/Gtkmm classes should have their own memory management functions 
> (operator new/operator delete - sigc has it btw).

How would this look like? Would this mean that all gtkmm (and derived)
objects are allocated with our own operator new, and deallocated with
our own operator delete?

Patches would be welcome, I think.

> 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.

Armin