Discussion :

[giviz]

Voila j'ai un petit problème de pointeurs, satanés pointeurs!

Ma fonction est la suivante:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
int
give_place (void **stock, const int struct_nbr, const int port)
{
    int i;
 
    /* check all places */
    for (i=0; i < struct_nbr; i++)
        if ((*stock+i)->port == port)
            return (i);
 
    /* port not found */
    return (-1);
}

Cette fonction recherche dans un tableau (stock) de struct_nbr cases le port donné.

Mon problème est le suivant:
Le pointeur *stock peut etre de différents types, i_http, i_ftp...

Ici a la compilation j'ai les 2 erreurs suivantes:
retrosniffMemory.c:40: attention : dereferencing `void *' pointer
retrosniffMemory.c:40: error: void value not ignored as it ought to be

Un parametre que je pourrais passé en plus a la fonction pourrait me permettre de connaitre le type qu'il faut utiliser pour *stock mais je ne vois vraiment pas comment intégrer le changement dynamique du type du pointeur sans faire un switch et réécrire le coeur de la fonction pour chaque type

Si qunlqun a une suggestion

[Balises CODE ajoutées par Anomaly - Merci d'y penser vous-même à l'avenir ]

[darkalia]

essaie de remplacer ton (*stock+i) par *stock[i]. Je suis pas sur de moi, mais ta facon d acceder a la i eme place me semble bizarre

[gl]

essaie de remplacer ton (*stock+i) par *stock[i]. Je suis pas sur de moi, mais ta facon d acceder a la i eme place me semble bizarre

Non le probleme est que tu ne peux pas te deplacer dans un pointeur de void, il faut imperativement connaitre le type pointe que ce soit pour faire *stock+i que stock[i].

Je ne vois pas d'autre solution que de passer par des switch (ou moins pour convertir le pointeur, par forcement pour tout le traitement).

[giviz]

Oki ben si passer par les switch il faut par les switch je passerais

Je créerais une sous fonction pour le code qui se répète ;p

Merci pour les réponses )

[mat.M]

Le problème soulevé n'est pas remédiable comme le suggère GL car il faut connaître le type d'identifiant.
C'est pour cette raison que les Templates ont été crées en C++...

Sinon une solution serait de créer une sorte de structure générique comme une classe de "Variant"

Code :

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

1
2
3
4
5
6
7
8
 
typedef struct {
int entier2;
double reel4;
char * charactere;
// etc...
 
} variant;

[Gandalf]

mat.M > oui mais to type variant est tout à la fois, ca va finir par etre enorme pour pas grand chose :

je proposerais plutot

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
 
enum eTypeEffectif
{
    entier,
    flottant,
    chaine
};
 
union uMultiType
{
    int entier;
    double flottant;
     char* chaine;
};
 
struct sVariant
{
   enum eTypeEffectif type;
   union uMultiType valeur;
}

qui donc s'utilise de la sorte :

Code :

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

1
2
3
struct sVariant titi;
titi.type = entier;
titi.valeur.eniter = 12;

[Be!!e F3e G0re]

t'es quand même obligé de passer par un switch pour différencier les types

[Gandalf]

L'interet par rapport au variant de mat.M est double :

*d'une part en terme d'occupation memoire, mon sVariant occupe 1 int + 1 double, ou plus exactement un enum + le plus gros des types de l'union, alors que la solution initiale occupe la somme de tous les types proposés...

*d'autre part cette solution integre l'aiguilleur du switch.

Cette solution n'est pas une chimere qui sort tout droit de mon esprit tortueux, mais c'est celle retenue par Motif pour les evenements ( a quelque chose près)...

après, faut il un switch ?
Mon esprit de contradiction dirait non... ....pas obligatoirement.

Certes le switch n'est pas une mauvaise solution, mais on peut aussi faire des fonctions pour chaque cas, puis construire un tableau de fonctions (appelons le funcTab) de sorte que funcTab[i] pointe sur la fonction qui traite le cas où type vaut i et le switch devient :

Code :

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

(funcTab[titi.type])(titi);

et on a reconstruit quelque chose qui ressemble ( de loin certes) au polymorphisme...

C'est une solution, qui, si elle est elegante, ne manquera pas de destabiliser nombre de relcteur du code, donc si on la chosit il faudra documenter le code de facon a etre sur d'etre compris...

[gl]

Le problème soulevé n'est pas remédiable comme le suggère GL car il faut connaître le type d'identifiant.

Si tu passe en plus un parametre qui defini d'une maniere ou d'une autre le type est que tu cast ton pointeur en fonction de ce parametre (dans un switch), ca marche bien (certes c'est galere). Je ne vois pas en quoi je propose une solution qui n'est pas applicable ?

[mat.M]

Le problème soulevé n'est pas remédiable comme le suggère GL car il faut connaître le type d'identifiant.

Si tu passe en plus un parametre qui defini d'une maniere ou d'une autre le type est que tu cast ton pointeur en fonction de ce parametre (dans un switch), ca marche bien (certes c'est galere). Je ne vois pas en quoi je propose une solution qui n'est pas applicable ?

Oui tout à fait je me suis très mal exprimé je n'ai pas relu ce que j'ai écris , 1000 excuses.
Je voulais dire "Car comme le suggère" , désolé

[Be!!e F3e G0re]

L'interet par rapport au variant de mat.M est double :

*d'une part en terme d'occupation memoire, mon sVariant occupe 1 int + 1 double, ou plus exactement un enum + le plus gros des types de l'union, alors que la solution initiale occupe la somme de tous les types proposés...

*d'autre part cette solution integre l'aiguilleur du switch.

Cette solution n'est pas une chimere qui sort tout droit de mon esprit tortueux, mais c'est celle retenue par Motif pour les evenements ( a quelque chose près)...

après, faut il un switch ?
Mon esprit de contradiction dirait non... ....pas obligatoirement.

Certes le switch n'est pas une mauvaise solution, mais on peut aussi faire des fonctions pour chaque cas, puis construire un tableau de fonctions (appelons le funcTab) de sorte que funcTab[i] pointe sur la fonction qui traite le cas où type vaut i et le switch devient :

Code :

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

(funcTab[titi.type])(titi);

et on a reconstruit quelque chose qui ressemble ( de loin certes) au polymorphisme...

C'est une solution, qui, si elle est elegante, ne manquera pas de destabiliser nombre de relcteur du code, donc si on la chosit il faudra documenter le code de facon a etre sur d'etre compris...

c'est ce que j'ai spécifié (et codé) pour mon IHM embarquée
mais utiliser un tableau de pointeurs de fonctions ou un switch c'est pareil, ce que je veux dire c'est que tu réécris le code pour chaque type
(maintenant le tableau de pointeurs de fonctions est plus élégant, ça c'est sûr)
et ce sera inévitable, à moins de truander en créant une interface, en dérivant des classes puis en bidouillant, ce qui sera pas terrible quand même

au passage: le 'problème' du tableau de pointeurs de fonctions à pour inconvénient une liste d'arguments fixée (bon t'as toujours la solution qui est celle du 'main' : argv[] ...)

(et ça ressemble même de près à du polymorphisme, c'est du polymorphisme à la 'C', sans compilo qui masque tout )

[Gandalf]

Oui/Non

Je suis un peu gene par cette notion de dupliquer le code...

c'est clair tu ne peut pas faire de template comme en C++...
mais tu peut faire des macros, qui ne sont pas typée, et donc en leur presentant les choses "comme il faut" ca marche ... ...sauf que c'est quasiement indebuggable, contrairement aux Template.

ensuite on parle ici d'un cas abstrait, ou on ne sait rien des types effectivement traités...

mais on peut imaginer que soit ces types sont siffisement differents pour que il n'y ait pas de duplication de code (donc plus de Problème)

soit que ce code a dupliquer puisse se trouver dans des fonctions plus basses ou plus hautes que le switch (ou le tableau de pnoiteurs de fct)

Plus basses pour des fonctions qui utiliseraient des convertion par exemple considerer les int comme des doubles...

Plus hautes pour les fonctions n'etant pas marquées par le type effectif que l'on pourrait alors representer à nouveau comme du void *

Pour la question de savoir si ca ressemble à du polymorphisme ou pas, je laisse cela à l'appreciation de chacun. Certes le mécanisme est similaire, mais le polymorphisme C++ est plus sur puisque justement c'est le compilo qui le gere...

[Gogoye]

Tu peux me montrer Gandalfr comment tu declares ton tableau de fonctions ?

Ca doit etre un truc dans le genre :

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
 
int func1(){
...
}
int func2(){
...
}
int func3(){
...
}
 
int main(){
void tabFunc[] = {func1, func2, func3};
...
}

non ? Mais je ne suis pas sur de la syntaxe exactem et du void....

[Gandalf]

en fait tableau de fonction c'est un raccourci, c'est en fait un tableau de pointeurs de fonctions...

le plus simple c'est de definir le pointeur de fonction, puis le tableau :

Code :

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

1
2
3
4
 
typedef short (*TreatementFunctionPtr)(struct sVariant*);
 
TreatementFunctionPtr funcTab[] = {func1, func2, ... };

[gl]

après, faut il un switch ?
Mon esprit de contradiction dirait non... ....pas obligatoirement.

Certes le switch n'est pas une mauvaise solution, mais on peut aussi faire des fonctions pour chaque cas, puis construire un tableau de fonctions (appelons le funcTab) de sorte que funcTab[i] pointe sur la fonction qui traite le cas où type vaut i et le switch devient :

Code :

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

(funcTab[titi.type])(titi);

et on a reconstruit quelque chose qui ressemble ( de loin certes) au polymorphisme...

C'est une solution, qui, si elle est elegante, ne manquera pas de destabiliser nombre de relcteur du code, donc si on la chosit il faudra documenter le code de facon a etre sur d'etre compris...

Personelement je prefere le switch aux pointeurs de fonction car bien que j'admette volontiers que la solution par pointeur de fonction est plus elegante, la perte de lisibilite et les probleme de maintenance qu'elle engendre (ainsi que la plus grande complexite, tout au moins par un debutant peu familiarise avec les pointeurs de fonction) sont trop handicapants par rapport aux gains apportes.

[Gandalf]

gl > je comprend ton point de vue...

Je suis tout a fait d'accord sur le coté deconcertant de la chose surtout pour un débutant, ce point est clair et ne peut etre contredit. J'avais d'ailleurs - dès la proposition de la solution - indiqué la necessité de documenter la chose.

pour la maintenance et la lisibilité permet-moi de ne pas etre d'accord avec toi, je m'explique. Tant que le nombre de switch est faible (disons jusqu'a une dizaine environ) tu as absolument raison. Par contre quand le nombre de switch augmente, la solution du tableau de pointeur de fonction est - à mon avis - plus pertinante, plus efficace, tant en performance qu'en lisibilité et donc en maintenance.

Lorsque la complexité du probleme augmente, utiliser des tableaux plutot que des switch imbriqués me semble également préférable.

[gl]

Lorsque la complexité du probleme augmente, utiliser des tableaux plutot que des switch imbriqués me semble également préférable.

Tout a fait d'accord avec toi. Je me placait dans le contexte du probleme initial ou a priori un seul switch (avec je pense guere plus de 4-5 case) suffit.