Discussion :

[Franck.H]

Je cherche une solution pour un problème sur lequel je tourne un peu en rond, j'explique...

J'ai une liste de type BList dans laquelle, chaque noeud possède un pointeur void * p_user_data, jusque là tout est clair ?

Ok passons aux choses sérieuses... Supposons que ce pointeur pointe sur un objet de type BOject.

J'aimerais savoir, sil y a un moyen quelconque, ou une astuce pour comparer ce pointeur p_user_data pour déterminer s'il est du type BOject ?

[kwariz]

Bonjour,

réponse courte : non.
void* gomme tout, ce n'est plus qu'une adresse sans information de type. Si on te donne un void* tu ne pourras jamais savoir quel en était le type (pour autant qu'il y ait eu un type ce qui n'est pas obligatoire) des données pointées.
Sauf si à la conception tu prévois une gestion personnalisée des types ...

[Franck.H]

Moui.... En fait, mon problème est là, j'ai ma liste, des noeuds pouvant contenir différents type d'objet et si lors du parcours de fermeture de ma liste, un objet de type BOject est stocké, j'appel sa propre fonction de destruction avant de détruire le noeud de la liste.

Je pense alors que le seul moyen est d'ajouter un membre dans la liste permettant de déterminer le type de l'objet stocké à la création de cet objet et de son ajout à la liste.

Cela dit, j'aurais préféré que la liste reste le plus simple et générique possible

[Franck.H]

Sauf si à la conception tu prévois une gestion personnalisée des types ...

C'est encore possible je ne suis qu'au début de mon code mais je ne vois pas trop comment faire cela à vrai dire

[kwariz]

Classiquement en C une liste générique correspond principalement à une liste d'objets de même type. Au besoin tu l'utilises pour avoir une liste d'entiers ou de pointeurs vers des structures de type fixe, rarement tu vas mélanger les types.
Ensuite tu as deux approches :

soit tu gardes le type dans ton noeud avec un enum ou une simple chaine (un peu à la printf)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
enum type { T_INT, T_DOUBLE, ..., T_STRUCT_MACHIN, ... };
struct node {
  enum type data_type; //décrit le type pointé par data
  void* data;
  struct node* next;
}

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
struct node {
  char* data_type;
  void* data;
  struct node* next;
}
 
...
  if (strcmp(current_node->data_type,"BObject")==0) {
   BObject* o=(BObject *) current_node->data;
    ...
  }

Soit tu t'arranges pour mimer des mécanismes à la c++ en ne créant que des listes de données pouvant être castés dans un type commun qui lui contient des infos sur le type réel, éventuellement des pointeurs de fonctions qui assurent la création, la suppression, etc ...

[Franck.H]

Classiquement en C une liste générique correspond principalement à une liste d'objets de même type. Au besoin tu l'utilises pour avoir une liste d'entiers ou de pointeurs vers des structures de type fixe, rarement tu vas mélanger les types.

Oui je sais mais là je sort un peu des sentiers battus. Je ne peut pas faire une liste pas type d'objets, c'est inconcevable et ce serait trop de boulot

Soit tu t'arranges pour mimer des mécanismes à la c++ en ne créant que des listes de données pouvant être castés dans un type commun qui lui contient des infos sur le type réel, éventuellement des pointeurs de fonctions qui assurent la création, la suppression, etc ...

Là franchement tu me pose une colle (ne connaissant pas le C++ ou que très peu) Tu aurait un exemple de ce que fait le C++ ?

[Franck.H]

Ce que je peut éventuellement faire pour que ce soit pas un trop gros bordel sans nom, c'est de changer le type du pointeur des noeuds de la liste par le type BOject, étant donné que ca va être le type de base de presque toute la seconde couche. Je garde un ou deux pointeurs void * comme réservation pour d'éventuels stockage mais au moins je peut tester si l'objet à l'intérieur du noeud existe alors le supprimer.

Je pense que ca reste la meilleure solution pour mon cas

[kwariz]

c++ possède un opérateur typeid qui peut te donner des renseignement sur le type mais je ne suis absolument pas un pro de c++
En revanche tu peux créer une sorte d'héritage, j'ai répondu il y a quelques temps à une question de ce genre : Spécialiser une structure à partir d'une structure existante, possible ?

En gros tu aurais une structure de base :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
struct BObject {
  char* type_name;
  void (*destructor)(struct BObject *);
  /* autres données ou fonctions utiles */
}
 
struct Machin {
  struct BObject obj_info;
  /* Tout le reste de ta structure */
}
 
...
 
struct Machin* creer_machin(...)
{
  struct Machin tmp=malloc(sizeof(*tmp));
  tmp->obj_info=creer_object("Machin", free);
  ...
  return tmp;
}
 
const char* get_type(const struct BObject* obj)
{
  return obj->type_name;
}
 
...
{
  struct Machin machin=creer_machin(...);
  ...
  /* Affichera Machin */
  printf("Type : %s\n", get_type( (const struct BObject*) machin);
  ...
  /* liberera machin */
  machin->Destructor(machin);
}

Mais bon, l'ébauche de code est tapée à la volée et est donné sans garanties ... ça va vite se compliquer ...
Si tu veux un aperçu de cette approche qui est correctement implémentée (avec rigueur et qui est non seulement utilisé mais utile) tu peux consulter GObject, GLib (et d'une manière générale tout se qui se rattache*au projet GTK+).

[kwariz]

Ce que je peut éventuellement faire pour que ce soit pas un trop gros bordel sans nom, c'est de changer le type du pointeur des noeuds de la liste par le type BOject, étant donné que ca va être le type de base de presque toute la seconde couche. Je garde un ou deux pointeurs void * comme réservation pour d'éventuels stockage mais au moins je peut tester si l'objet à l'intérieur du noeud existe alors le supprimer.

Je pense que ca reste la meilleure solution pour mon cas

Difficile à dire sans savoir ce que tu veux faire et pourquoi tu veux le faire
Là on se doute juste que tu veux utiliser des listes de données hétérogènes mais on ne sait pas si c'est nécessaire ou pas, ...

[Franck.H]

Difficile à dire sans savoir ce que tu veux faire et pourquoi tu veux le faire
Là on se doute juste que tu veux utiliser des listes de données hétérogènes mais on ne sait pas si c'est nécessaire ou pas, ...

Je travaille en ce moment sur mon moteur 2D perso basé sur SDL. Le but étant de fournir un minimum d'objets ainsi j'aurais accès à des contrôles (boutons, boîtes de dialogue, cases à cocher, etc...), le minimum qu'on trouve dans fenêtres d'options de jeux.

Boject sera la base de tous les autres objets, même l'écran de jeu ainsi que tous les autres contrôles.

Après ca viens de tilter sur le fait que si j'affiche du texte ce sera uniquement par le biais d'un objet spécialisé donc du coup ca ne posera pas de problème de spécialiser la liste sur un type d'objet spécifique, des fois je réfléchi un peu trop lentement

Dans cette première base de mon moteur se trouve la BLib (oui je sais ca ressemble étrangement à GLib ), base qui comprend une liste doublement chaînée, une pile, le fameux BOject, un traceur de mémoire et un mini garbage collector pour pouvoir libérer facilement et proprement toute la mémoire allouée.

Voilà en gros le projet pour mon prochain projet de jeu, un vieux projet que j'ai dépoussiéré

[kwariz]

Ne serait-ce pas une piste à explorer que de te baser sur la glib (qui contient en gros tout ce que tu cherches à implémenter) pour créer ta bibliothèque ? Quand je dis baser je pense utiliser surtout. Tu créerais un BWidget à partir d'un GObject (ou d'un GInitiallyUnowned), BWidget serait ton objet de base de la bibliothèque BLib .. un peu à l'instar de GTK+. Du coup tu bénéficierais de tout le travail (et évidemment des améliorations futures) fait sur la GLib et cela te permettrait de te concentrer sur le cœur de ce que tu veux implémenter : un moteur graphique

[Franck.H]

J'y ai déjà réfléchi mais c'est tellement énorme et avec tellement de dépendances Je pensais donc faire quelque chose de plus minimaliste et ajouter au fur et à mesure des besoins futurs.

[Franck.H]

Quoique en y regardant de plus près elle est normalement autonome la GLib c'est juste une suite de DLL... Mais quant à implémenter un BWidget sur la base d'un GOject... ca faut vraiment voir comment ca marche en interne. J'avais fait un tutos il y a bien longtemps sur commenter créer un Widget GTK+ mais c'était encore avec d'ancienne méthode, ca à bien changé entre temps

[kwariz]

De souvenir, au départ (il y a longtemps) tout était plus ou moins incorporé/mélangé dans GTK et après un grand ménage tout a beaucoup plus été modularisé et bien séparé
Tu peux n'utiliser que GObject, certainement GLib, pourquoi pas GIO ...
Développer ses propres descendants de GObject est compliqué, surtout au début. L'avantage que j'y vois est de ne pas avoir à debugguer ce que tu ferais certainement moins bien (dans le meilleur des cas) dans le premier jets (surtout si tu essayes d'être générique, que tu penses incorporer un gc, ...) et d'avoir un accès multiplateformes car les G* comme la SDL tournent aussi bien sur linux que windows que mac ...
Les désavantages sont évidemment la lourdeur des mécanismes mis en jeu (mais ceux que tu développerais le seraient-ils moins ?), une période d'apprentissage un peu longue, une rigueur à avoir si tu veux construire ta bibliothèque sur plusieurs plateformes ...
C'est toi qui vois mais quoi qu'il en soit, bon courage et j'espère bien voir le résultat

[Franck.H]

C'est vrai que les mécanisme sont très très lourds. Je pense que je vais rester sur ma dernière idée car pour le peu de code que j'ai déjà pondu tout est déjà bien lié (traceur, gc, liste, etc...)

Je vais sortir du cas générique et me baser sur mon objet fondamental pour la liste (la pile je ne sais pas encore si elle va me servir mais je l'ai au moins ).

Je viens de déterrer un vieux tutoriel écrit à l'époque par mon très cher ami gege2061 (gege si tu me lis... ) http://nicolasj.developpez.com/gobject/classe/ mais c'est beaucoup trop lourd pour ce que je veux faire... après avec le temps et les ajouts est-ce que ma bibliothèque sera tout aussi lourde ca je n'en sais rien

une rigueur à avoir si tu veux construire ta bibliothèque sur plusieurs plateformes ...

Ca c'est prévu dès le départ et d'ailleurs c'est toi-même qui m'a aidé pour les macro d'exportation/importation des symboles D'ailleurs, la base de la lib est uniquement en C Standard C89/C90 (POSIX.1 ... peut-être à voir)

C'est toi qui vois mais quoi qu'il en soit, bon courage et j'espère bien voir le résultat

Tu le verra car le moment venu je déterrerais un vieux topic pour recruter un graphiste et un musicos pour relancer mon projet

[kwariz]

Je viens de déterrer un vieux tutoriel écrit à l'époque par mon très cher ami gege2061 (gege si tu me lis... ) http://nicolasj.developpez.com/gobject/classe/ mais c'est beaucoup trop lourd pour ce que je veux faire... après avec le temps et les ajouts est-ce que ma bibliothèque sera tout aussi lourde ca je n'en sais rien

Il y a eu plusieurs solutions pour pallier à ce «défaut» GOB2 (à voir) et aussi indirectement Vala. Vala permet de créer très simplement des GObject (si si je t'assure ) et de créer des sources C qui vont bien (à voir aussi, il y a un exemple simple sur wikipedia).

Ca c'est prévu dès le départ et d'ailleurs c'est toi-même qui m'a aidé pour les macro d'exportation/importation des symboles D'ailleurs, la base de la lib est uniquement en C Standard C89/C90 (POSIX.1 ... peut-être à voir)

vive le C99 avec gcc ! (en attendant le C11 de gcc 4.9)
Aux oubliettes le C89 !!!!!!!

[Franck.H]

vive le C99 avec gcc ! (en attendant le C11 de gcc 4.9)
Aux oubliettes le C89 !!!!!!!

Il y a certaines choses de C99 que je n'aime pas et que je pense n'ont pas leur place dans un langage comme celui-ci, C11 c'est nouveau pour moi je n'ai pas suivi l'actu depuis bien 3 ou 4 ans, d'ailleurs c'est facile la durée pendant laquelle je n'ai pas fait de programmation

quand même de t'être attardé sur mon cas, le résultat en vaudra la peine tu verras