Re: [gtkmm] "manage" and Glib::RefPtr
- From: Daniel Elstner <daniel elstner gmx net>
- To: Daniel Bausch <DanielBausch gmx de>
- Cc: "Butler, Gerald" <gbutler Jewels COM>, gtkmm-list gnome org
- Subject: Re: [gtkmm] "manage" and Glib::RefPtr
- Date: 11 Oct 2002 10:44:02 +0200
Am Fre, 2002-10-11 um 03.42 schrieb Daniel Bausch:
> I'd like to tell you, why I choose gtkmm. I hope I can prevent you from
> destroying a main goal of this well designed library.
> The best thing on gtkmm is, that it really uses standard C++. C++ knows stack
> objects as well as heap objects. Heap objects are very important in dynamic
> environments. A GUI can be a dynamic environment, too. Imagine a UI that is
> constructed from a XML file. You do not know, which and how much objects you
Nobody is going to disallow that.
> Gtkmm can deal with all these types of standard C++ memory management methods.
> These are clear. And everyone who knows C++ can understand gtkmm. The only
> thing a C++ programmer does not understand easily is that he has to use
> mangage for dynamic objects.
manage() is a relict of the *current* implementation.
> He would understand if he was to delete the
> dynamic objects in the destructor of the window or at any other place. He
> would also understand, if he were to give a reference to an owning object to
> the constructor of some widget like in delphi.
My proposal is to give you a RefPtr<>. You can either keep it or throw
it away once you attached the widget to a container.
> I think every "enhachement" made to the memory management system of C++ is a
> big backstep.
I don't want more "enhancement" modes either. That's the point.
> You need no refcounting. Refcounting is a feature for programmers who spread
> pointers all over the program. There's no refcounting in standard C++ because
> the people who defined the standard are good software developers. I say:
> Before introducing such a horrible feature, organize your software!
That's nothing but a silly rant.
> programmer must have real control over the lib, not the lib over the
> programmer. The lib shall serve the programmer and not make him headaches,
> why some objects are not destroyed when he wants them to.
> PS: new/delete is standard C++ because it is flexible, transparent and easy to
I'm not sure what you mean by flexibility or transparency, but it's
definitely not easy to use. Ever had to delete *loads* of objects
manually? Ever cared to write exception safe code?
] [Thread Prev