Checker un GOBJECT

Bonjour,

Comment vérifier la qualité d'un pointeur dont l'origine est indéterminé ?
À savoir s'il s'agit bien d'un G_OJECT (ou dérivé) ?

Exemple OK :

Code:

---

1 2 3 4 5 6

... GtkWidget *widget; gboolean b; widget = gtk_window_new (GTK_WINDOW_TOPLEVEL); b = G_IS_OBJECT (widget); /* b -> TRUE */

---

Exemple KO :

Code:

---

1 2 3 4 5

... gchar *str = "bob"; gboolean b; b = G_IS_OBJECT (str); /* plantage de la libgobject */

---

Je voudrais donc pouvoir vérifier que l'objet que je reçois est bien un G_OBJECT (ou dérivé) et non autre chose (car ce n'est évidemment pas moi qui l'envoie).
Un moyen ?

Je n'ai pas l'habitude de travailler directement avec les gobjects, donc des personnes plus compétentes pourrons sans doute te donner des avis plus pertinents.

J'ai rapidement parcouru la doc, et il me semble que G_TYPE_IS_OBJECT() pourrai peut être faire l'affaire.

Sinon, si tu n'a aucune idée de ce que tu reçois, il me semble que la seule méthode est de mettre en place provisoirement une capture du signal d'erreur provoqué par le test.

Merci.

G_TYPE_IS_OBJECT pose la même difficulté en admettant un GType en argument. La conversion d'un char* par exemple en GType plantera de la même façon.

Je ne devrais recevoir que des GObject, mais ce n'est pas moi qui les envoie. Une erreur volontaire ou non de l'émetteur peut m'envoyer autre chose qui peut provoquer un crash de l'application.

Pour l'heure, j'ai mis un contrôle des objets en amont de leur cast en GObject, via des procédures internes à l'application mais je ne suis pas certain d'éliminer toutes les failles possibles ...

C'est pourquoi s'il y avait un moyen pour qu'une macro ou une fonction GObject me renvoie un simple booléen, ce serait une grose épine en moins.

Je vais voir du côté de la gestion du signal d'erreur, s'il y a un moyen.

Je ne suis pas un expert en GObject, je suis à peu près sûr que c'est faisable, mais je n'ai pas trouvé rapidement comment. Le mieux, si tu te débrouilles un peu en anglais, serait que tu poses ta question sur la mailing list gtk-app-devel-list. On est intéressés aussi par la réponse :mrgreen:.

Héhé, pas de surprises. GObject rajoute bien une couche pour de la POO mais ça reste du C ...!

Ok, donc je me suis gourré, ne n'est pas possible. Pour être exhaustif, je mets le lien vers ton fil de discussion:
http://mail.gnome.org/archives/gtk-a.../msg00099.html

On arrive aux limites du C. La réponse est finalement logique même si j'ai pu espérer une solution plus ou moins déguisée.
Écrire une gestion des exceptions ne doit vraiment pas être évidentes dans le contexte de GObject.
Ceci dit, peut-être existe-t'il un moyen d'avancer avec la GLib et ses GError ?

Plutôt que de parler de "limites du C", je parlerai plutôt de la permissivité du C.
Le C est faiblement typé, donc offre une grande liberté au programmeur, le comble étant atteint avec le type void, mais cette liberté a un prix.
Pour qu'un échange de données puisse fonctionner, il doit respecter un certain protocole, le plus courant étant d'envoyer un en-tête qui permet de caractériser les données qui vont suivre. Dans le cas contraire, ce n'est plus de l'échange de données mais de la recherche d'information, de qui est complexe, coûteux en force de calcul et présente un aspect aléatoire.
Si c'est toi qui envoie le GObject, tu peut toujours par un autre canal (canal de signalisation), envoyer un signal pour indiquer que ce qui va suivre est un GObject.

Disons que les choix de conception imposent (impliquent) des limites à ce qui est possible ensuite de faire.
Dans le cas qui me concerne ici, le contexte d'exécution n'est pas sur : l'émetteur n'est pas forcément sur de ce qu'il envoie. Et comme je ne suis pas l'émetteur ...
J'aurais apprécié avoir un second filet (j'ai déjà implémenté une série de vérifications internes lors de la réception dudit objet).

Ceci dit, je n'ai pas trouvé beaucoup de sujets sur ce thème, je ne dois pourtant pas être le seul à me confronter à ça !