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
