Discussion :

[Mac LAK]

Non Mac LAK, ce n'est pas l'usage que je remets en cause, c'est cette ligne :

Le copier/coller, c'est le mal : la preuve avec cette ligne...

Le paramètre d'origine était un entier 64 bits, j'ai oublié de virer le "&" en adaptant la fonction...

Merci, la bonne ligne est :

Code :

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

unsigned char* b = (unsigned char*)(toSwap) ;

[nicolas.sitbon]

Merci, la bonne ligne est :

Code :

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

unsigned char* b = (unsigned char*)(toSwap) ;

Tu utilises un void*pour la généricité mais tu castes un void*? je ne comprend pas la logique...

[Philou67430]

Ces cast sont optionnels pour le compilateur, car implicites, comme le montre ton code nicolas.sitbon.

[Mac LAK]

Tu utilises un void*pour la généricité mais tu castes un void*? je ne comprend pas la logique...

L'habitude : je n'affecte jamais un pointeur vers un autre type que void* sans le caster explicitement, du moins dans MON code. Et encore, ça m'arrive aussi de caster vers du void* !

Ce que fait l'utilisateur est son problème : j'expose un paramètre "void*" pour montrer que je ne gère pas le type de la donnée, et que seule sa taille et son adresse m'intéressent. S'il veut "profiter" du fait qu'il n'est pas nécessaire de caster, aucun souci, mais en attendant je fais des casts explicites dans mon code histoire que le dev suivant ne s'étonne pas, par exemple, de voir un "struct machin*" casté vers un "int*" ou autre type fortement différent... Il n'est hélas pas rare qu'un cast implicite masque une erreur !

Bref, la généricité, c'est pas totalement le but... La raison du "void*", c'est d'abord de dire "Le type n'a aucune importance".

Pour illustrer :

Code :

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

1
2
3
4
5
6
char* ptr1 ;
void* ptr2 ;
 
ptr2 = ptr1 ;        // OK, c'est vers du void*, c'est générique, on laisse sans cast.
ptr2 = (void*)ptr1 ; // Solution préférée : ça montre que je VEUX perdre l'information de type.
ptr1 = (char*)ptr2 ; // Cast explicite, histoire de montrer que ce n'est PAS une erreur ou une confusion, et qu'à priori je sais ce que je fais.

Cela parait un peu étrange, je le reconnais, quand il s'agit de casts entre pointeurs impliquant un void*. C'est juste la généralisation du principe qui m'évite d'affecter un "int" à un "char" en trouvant ça tout à fait normal et/ou en rajoutant des "#pragma warning(disable: 4244)"...

[Médinoc]

Personnellement, j'ai la logique contraire: Si un cast explicite (surtout un cast C-style) peut être évité, alors évitons-le, réduisant la probabilité d'un cast explicite malheureux.

[Philou67430]

La règle qui consiste à dire qu'il faut caster tous les pointeurs n'est pas, à mes yeux, une règle à conseiller, car elle a tendance à banaliser l'usage du cast, qui devrait rester quelque chose d'exceptionnel.
En castant trop, on peut faire disparaitre des warnings qui pourraient être de vraies erreurs de programmation.

Limiter au maximum le recours au cast me semblerait plutôt être la règle de base.

Edit : croisement avec medinoc, avec qui je suis entièrement d'accord.

[Mac LAK]

Personnellement, j'ai la logique contraire: Si un cast explicite (surtout un cast C-style) peut être évité, alors évitons-le, réduisant la probabilité d'un cast explicite malheureux.

Là, c'est un peu particulier : c'est une fonction de traitement "abstraite", je trouve donc normal d'avoir un cast explicite afin de transformer l'entrée en un paramètre de travail. Normalement, tu ne devrais en effet jamais avoir besoin de casts, et je te rassure, c'est le cas le plus souvent dans mon code. Mais quand je DOIS passer d'un type à un autre, c'est "cast explicite de rigueur" pour ma part.

De plus, il est souvent impossible de faire autrement : soit tu fais un cast et ça marche, soit t'as un warning à la compilation... Et j'ai déjà eu un peu trop de bugs pénibles à trouver avec les casts implicites, notamment lors de changement de compilateurs et/ou de portage 16->32 bits (et oui, la norme, c'est joli, mais c'est loin d'être toujours respecté à 100%, surtout sur les vieux compilos...).

Faut pas oublier, là, c'est du C, pas du C++ : pas de surcharge d'opérateur, pas de polymorphisme, le cast reste souvent le seul outil disponible (avec le truc hideux qu'est l'union "fourre-tout", mais c'est trop laid pour être utilisé).

[nicolas.sitbon]

soit tu fais un cast et ça marche, soit t'as un warning à la compilation...

pas de warning si l'une des opérandes est un void*.

[Mac LAK]

pas de warning si l'une des opérandes est un void*.

T'en as un en affectant un int à un char.

Après, comme je l'ai précisé, y'a une nette différence entre utiliser cette généricité du void* en appelant une routine en mode "boite noire", et écrire la routine en question... Dans la routine, un cast montre aussi que l'on sait (à priori) ce que l'on fait en modifiant le type de la donnée.

[Philou67430]

Dans la routine, un cast montre aussi que l'on sait (à priori) ce que l'on fait en modifiant le type de la donnée.

Non, pour moi, il impose seulement au compilateur de se taire devant nos ordres... pas que ces ordres soient justifiés.
Ne pas caster quand ce n'est pas nécessaire permet de lever les erreurs de typage... Ensuite seulement, le programmeur peut prendre la décision de transtyper

[Mac LAK]

Ne pas caster quand ce n'est pas nécessaire permet de lever les erreurs de typage... Ensuite seulement, le programmeur peut prendre la décision de transtyper

Mouais, tu ne peux pas non plus toujours caster n'importe quoi en n'importe quoi via un seul cast, ce qui limite les erreurs de typage réellement débiles.

Enfin, ça reste un point de vue, pour ma part je préfère caster explicitement (en accord avec la conception des modules bien entendu, pas juste "pour faire compiler") quand je le fais sciemment.

[Philou67430]

Pour moi, ce n'est pas une préférence, c'est un choix argumenté.
Il ne faut pas oublier qu'en règle général, on n'est pas seul sur un projet : une mauvaise habitude prise par l'un peut vite devenir une mauvaise habitude pour les autres. Il existe toujours plus de risque d'erreur à l'exécution en castant là où ce n'est pas nécessaire qu'en ne castant pas là où ce serait nécessaire.

[Mac LAK]

Il existe toujours plus de risque d'erreur à l'exécution en castant là où ce n'est pas nécessaire qu'en ne castant pas là où ce serait nécessaire.

C'est surtout un problème dans le code de haut niveau, c'est plutôt le cas inverse dans les routines. Là, c'est justement une routine...

[Nikolas]

Ça tombe bien, je comprends rien aux cast.

Mais je comprends rien, non plus, à cette utilisation du void ; la FAQ ne va pas si loin, y a même pas inline ni register d'expliqué, dans cette FAQ...


Ça me gêne d'utiliser un code que je ne comprends pas entièrement mais par contre, il marche parfaitement comme je le souhaitais (sans déclarer dans for).

Merci nicolas.sitbon !

[nicolas.sitbon]

(sans déclarer dans for).

Compile en C99, on est en 2009, ça fait 10 ans que la norme existe, faut s'y mettre un peu.

[Philou67430]

Désolé Mac LAK, mais je ne vois pas de rapport entre le niveau d'une fonction, et le besoin de transtyper (et j'ai bien parlé d'erreur à l'exécution).
Pour moi, quelque soit le niveau d'abstraction, un besoin de transtypage est le reflet d'une erreur de conception/modélisation (qu'il soit bien clair que l'on a tout à fait le droit de faire des erreurs, du moment qu'on les justifie : donc que l'on explique dans le code pourquoi on réalise ce transtypage).

[nicolas.sitbon]

donc que l'on explique dans le code pourquoi on réalise ce transtypage).

Dans ce cas précis, il n'y a aucune raison. Les cas en C ou le transtypage est requis sont rare et bien connu, je reste convaincu, que moins il y a de ligne de code, moins il y a de bug, et même un simple transtypage peut engendrer des erreurs, qui plus est, difficiles à trouver.

[Philou67430]

Je voulais naturellement parler des transtypages qui sont nécessaires, pas ceux qui sont autorisés et implicitement acceptés (donc par exemple, de transtyper un pointeur de unsigned long en un pointeur de caractère).

[Mac LAK]

Désolé Mac LAK, mais je ne vois pas de rapport entre le niveau d'une fonction, et le besoin de transtyper (et j'ai bien parlé d'erreur à l'exécution).
Pour moi, quelque soit le niveau d'abstraction, un besoin de transtypage est le reflet d'une erreur de conception/modélisation (qu'il soit bien clair que l'on a tout à fait le droit de faire des erreurs, du moment qu'on les justifie : donc que l'on explique dans le code pourquoi on réalise ce transtypage).

Facile, pourtant... Regarde donc les prototypes de fonctions comme "fwrite", "send", "recv", etc. Le buffer est passé sous forme de "void*" pour être tranquille et y passer n'importe quoi, même si quelque part en interne le type est casté vers un autre type quelconque. Et tu t'en moque, la tripaille interne n'est pas de ton ressort en l'occurrence. Par contre, celui qui fait / maintiens la tripaille en question est bien obligé de gérer un type de temps en temps, et effectuera donc un cast. Dans le cas de ma fonction, j'ai besoin d'un accès octet par octet => cast. Et je laisse un void* en prototype pour simplifier la vie de l'utilisateur.

Maintenant, regarde par exemple la boucle de réception (ou les fonctions d'émission) de la libpcap, qui n'utilisent QUE des "u_char*" comme type pour les buffers de données... Super, quand on veut recevoir / émettre des structures connues à l'avance, non ? Tu évites le transtypage comment ? Et là, c'est encore pire, c'est l'utilisateur qui doit caster !!

Pour moi, l'erreur de conception, c'est plutôt de faire un cast implicite sans le mentionner... C'est quoi ? Une erreur ? Un oubli ? Une faille de conception ? Il faudrait encore plus le commenter qu'un cast explicite !

[nicolas.sitbon]

Pour moi, l'erreur de conception, c'est plutôt de faire un cast implicite sans le mentionner... C'est quoi ? Une erreur ? Un oubli ? Une faille de conception ? Il faudrait encore plus le commenter qu'un cast explicite !

Si tu veux être en accord avec ce que tu dis là, tu vas devoir commenter aussi toutes les promotions entières implicites, on se rend bien compte que ça pas de sens ce que tu dis là.
le fait de caster ici:

Code :

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

unsigned char * tab = (unsigned char *) to_swap;

n'apporte strictement rien, puisque tout le monde sait à quoi sert un pointeur générique.