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@xxxxxxxxx. On 14 May 2015 at 10:27, Jean-Marie Delapierre <jean-marie.delapierre@xxxxxxxxxx> 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. -- https://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
