Re: [gtkmm] "manage" and Glib::RefPtr

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

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.

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

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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]