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

[klaus triendl <klaus triendl eu>]

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

btw: I've experienced the error too (I formerly used the installer for 
gtkmm 2.10 which had no binaries for vs2008).
Today I tested gtkmm 2.14 and changed and tried both runtimes (static 
and dynamic)


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

This is an argument!


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

It doesn't influence the way how or the place where objects are created, 
it only has an impact on the location from where memory is 
allocated/deallocated for that specific object - see below.


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

Yes I mean that Gtk::Object, Glib::Object or even Glib::ObjectBase could 
override the memory allocation functions:

<code>
// header objectbase.h
class ObjectBase: virtual public sigc::trackable
{
public:
  void* operator new(size_t);
  void operator delete(void*);

// other stuff ...
};

// objectbase.cc, code will live in dll, using the dll's runtime
void* ObjectBase::operator new(size_t s)
{
  return ::operator new(s);
}
void ObjectBase::operator delete(void* p)
{
  ::operator delete(p);
}
</code>

Note that sigc::slot does the same to ensure that creation and deletion 
of slots happen in the sigc dll.
Derived objects automatically benefit from those operators unless they 
override them again themselves.
Be aware that this only affects the location from where *memory* for an 
object is allocated/deallocated. It does not influence construction and 
destruction.

Are there functions returning Glib::ustring or using Glib::ustring as 
output parameter? If yes then you would need to use a special allocator 
that binds memory operations to a specific module.


Klaus