On Wed, 04 Jun 2008 12:50:48 -0700 "Brian J. Tarricone" <[EMAIL PROTECTED]> wrote:
> Jean-Yves Lefort wrote: > > On Wed, 04 Jun 2008 15:18:45 -0400 > > Paul Davis <[EMAIL PROTECTED]> wrote: > > > >> On Wed, 2008-06-04 at 20:57 +0200, Jean-Yves Lefort wrote: > >> > >>> Rather than calling my suggestions silly, why don't you actually try > >>> to explain how the non-preprocessed, dynamic-only GLib property design > >>> is superior to the Qt design (or at least not inferior), or describe > >>> these specific reasons that you are talking about? > >> because i really don't give a damn. i don't use GTK+, i use gtkmm, and > >> there is no feature of Qt that i ever find lacking. although Qt has > >> closed the gap, for a long time it was the poor cousin of gtkmm when it > >> came to type-safety, integration with the STL and more. i'm really not > >> all that interested in what happens at the GObject level, other than > >> that it maps into a decently performing layer by the time i interact > >> with it at the C++ level. i also don't want to see glib/gobject > >> developers wasting time trying to do what C++ plus a preprocessor does > >> in plain C or C plus Yet Another PreProcessor. > > > > You didn't get the point. As explained in my initial message, a > > preprocessor would be used to fix the performance of the property > > system. > > I wouldn't think that this is worth it. As Tim mentioned elsewhere, for > properties that need to be read/written in a time-critical fashion, it's > best to add specific getters/setters. GTK already does this in many > places (often for convenience, not for performance reasons), so I don't > see how this is a huge burden. If the global get_property()/set_property() functions were axed and the invididual property accessors were made mandatory and used by the property system, an object author would not be left having to decide whether property x or y is going to be accessed in a time-critical fashion or not (when faced with such decisions, authors are often tempted to choose the quickest path). Of course, everybody will have its own opinion on whether this or other improvements that would reduce the gap with the main competitor is worth it or not. If the GLib/GTK+ maintainers believe that selling an ABI breakage and a major release with just "we've mangled fields; we've removed deprecated cruft" is ambitious enough, then who am I oppose. > Regardless, have you done any benchmarking? You might find the > performance issues to be negligible. And you might not. But throwing > around statements like "it's definitely much slower" is meaningless > without numbers. One does not need to create a benchmark for figuring out that since most accessors simply return or set a struct field, calling the individual accessor function is dramatically faster than calling g_object_get()/g_object_set(). > > Ease of use is not the main goal, it's only a secondary > > benefit. As you might know, Qt is implemented in plain C++, and > > nevertheless uses a preprocessor (moc). > > If it needs a preprocessor, it's not "plain C++". You're right, I worded it badly. I meant that as far as I know, Qt is implemented entirely in C++ (no C parts), and still finds the use for a preprocessor. -- Jean-Yves Lefort <[EMAIL PROTECTED]>
pgp4KTBchv9wV.pgp
Description: PGP signature
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
