Jean-Yves Lefort wrote:
On Wed, 04 Jun 2008 15:18:45 -0400 Paul Davis <paul linuxaudiosystems com> 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.
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.
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++". -brian