On 08/28/2015 09:09 PM, Jean-Marie Delapierre wrote: >> Hi; > >> this mailing list is probably not the one you want to use — >> development of the GLib/GTK+ libraries is discussed on >> gtk-devel-list gnome org > >> On 14 May 2015 at 10:27, Jean-Marie Delapierre >> <jean-marie delapierre 9online fr> wrote: > > I have coded in C language with GTK+ since a few months. > In the first times, I have used the usual pointer casting provided > with the > library: GTK_CONTAINER (my_window) for exemple. > > In my opinion, there are two disadvantages with this system: > > first, the widget pointers are not "object style" written, > second, if you cast a pointer with a type which is not of one of its > parents > widget, you get no error at compiling time and you get an execution > error > only if you compile with widget type control. > > What I suggest is to define the widget descriptors as unions of pointers > representing the hierarchy of the widgets. > >> No. > >> You misunderstand the way unions work in C. You're just adding a bunch >> of identically pointer-sized fields inside the same union, which is >> entirely pointless since you'll need to know the size of the >> allocation of each one of them — thus, you'll need to define a >> instance structure for each; it won't also do you any good: you're >> exploiting the fact that GObject instance and class structures contain >> their parent's instance and class structure, respectively, so >> allocating a derived type will automatically allocate enough memory >> for you to cast a pointer to its parent type. > >> Even if we used this trick (which is actually more verbose, more error >> prone, and less clear than a cast all at the same time, in itself >> quite a feat) you would just consume more space and have no benefit >> over the existing 'include the parent structure inside the >> instance/class structure of a derived type and cast'. It would also >> not solve the issue of interfaces implemented by a type, since you can >> add an interface to an existing type without breaking API/ABI, whereas >> you cannot change the size of a structure or union compatibly — even >> if you are, in effect, just allocating enough room for a single >> pointer. > >> This would also not be API and ABI compatible, so it's an immediate >> no-go. > > But, there is one disadvantage. This coding style is only available > in C and > C++ languages. > >> Which is another moot point, since we use the type system for bindings >> as well. > >> The GType type system is not without its flaws, but the fact that it's >> a run-time type system is not really one of them. It's just the price >> you pay for implementing additional types on top of the C type system. >> Additionally, any language that allows casting is inherently hard (or, >> in some cases, even impossible) to be fully validated at compile time. > >> Validation of the GType type system should be the realm of static code >> analysis. > >> Ciao, >> Emmanuele. > > Hi, > > I have let spend some time before to respond to your message, not to > react about your writing style. > > Yes, I have made an enormous mistake. I have considered that the example > included in my original message would have been enough to make you > understand what I mean. Which was the mistake. > > But, let me explain little more. > > First of all, I do precisely NOTHING to the glib or GTK objects. > > When you use the actual coding style with the GTK objects, you declare a > pointer which is usually of GtkWidget* type, and when you want to use it > in a function, you cast it like this: “gtk_window_set_title (GTK_WINDOW > (window)…” (in the preceding example, the keyword “window’ have been > declared as GtkWidget *window;). > In fact, doing this means that you use two different pointers (one of > GtkWidget* type and one of GtkWindow* type) sharing the same memory > location. > > What I suggest is only and exactly the same, but with a coding style I > consider cleaner than the actual coding style and less error prone. > > The trick is to declare a union of pointers (not objects), sharing the > same memory location, pointing to the types limited to only the valid > types for a given object. > > What you have to notice is that in actual coding style, you declare a > descriptor which is a pointer to an object (with an indirection) and > with the coding style I suggest, you declare a descriptor which is of > union type (not a pointer). The indirection been carried by the > collection of pointers in the union. > > Thus, the two coding styles a fully interoperable with one difference: > With the actual coding style, you can cast your pointer to a type which > is not compatible with the object you are pointing to. With the one I > suggest, you can’t. The compiler will detect the error for you before > the execution time. > > In the end, you said that it’s more verbose. OK. > > But, tell me which is more verbose: > > This “gtk_window_set_title (GTK_WINDOW (window), "Hello World");”, > Or this “gtk_window_set_title (window.gtkwindow, "Hello World");”. > > Regards. > > Jean-Marie > > > > > _______________________________________________ > gtk-list mailing list > gtk-list@xxxxxxxxx > https://mail.gnome.org/mailman/listinfo/gtk-list > You're still on the wrong list. Emmanuele is still right that the union of child objects has to change when a parent type starts implementing an interface. I also don't know how you would conveniently declare such a union with mere macros. _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
