eviter un warning sur un cast

Bonjour à tous,

dans le but de fournir un code le plus propre possible, je fais la chasse aux warnings. Et il y en a un que je ne sais pas comment supprimer.

J'ai une fonction callback qui ressemble à cela:

Code:

---

1 2 3 4 5

void __stdcall MaCallback( unsigned long context, void* pData) { MaClasse* pMonObjet = reinterpret_cast<MaClasse*>(context); // ensuite je fais des traitements sur pMonObjet }

---

Dans cette callback, je récupère le contexte. En fait, ce contexte est un pointeur sur une classe qui va être modifée dans cette callback.

Voici le warning que j'obtiens (je travaille avec Visual8):

Citation:

---

warning C4312: 'reinterpret_cast' : conversion from 'unsigned long' to 'MaClasse *' of greater size

---

Avez-vous une idée pour se débarrasser de ce warning?

ps: je ne peux pas modifier la signature de ma callback, elle fait partie d'une sdk "externe" à mon projet.

question : avant de chasser le warning , est ce que ton code marche ?

j'aurais tendance a dire que ton code converti un entier (que je suppose en 4 octets) vers un pointeur (que je suppose en 8 --> machine 64bits ?). Dans ce cas, la conversion telle qu elle semble carrement dangereuse (quand on utilise un context on devrait au pire donner un pointer et pas un entier de taille inconnu):sm:

Tu devrais verifier a affichant sur la sortie standard les sizeof( ... )

tu peux aussi voir sizeof( long long) .

derniere question : es tu sur que ce n est pas pData qu il faut caster ???

Citation:

---

Envoyé par smashy

question : avant de chasser le warning , est ce que ton code marche ?

---

Oui ça fonctionne trés bien.

Citation:

---

Envoyé par smashy

j'aurais tendance a dire que ton code converti un entier (que je suppose en 4 octets) vers un pointeur (que je suppose en 8 --> machine 64bits ?). Dans ce cas, la conversion telle qu elle semble carrement dangereuse (quand on utilise un context on devrait au pire donner un pointer et pas un entier de taille inconnu):sm:

---

Oui mais ça je n'y suis pour rien: je ne peux pas modifier la signature de la callback et je ne vois pas d'autres moyen pour lui passer l'objet que je souhaite modifer.

Citation:

---

Envoyé par smashy

Tu devrais verifier a affichant sur la sortie standard les sizeof( ... )

---

Il y a un problème de taille, j'ai bien compris, mais je sais pertinemment ce que je met dans ce paramètre 'context'; c'est d'ailleurs la raison pour laquelle j'utilise un reinterpret_cast.

Citation:

---

Envoyé par smashy

derniere question : es tu sur que ce n est pas pData qu il faut caster ???

---

Oui.
Le pData contient des données binaires trés spécifiques, et je n'ai aucun contrôle sur ce contenu.

Le pramètre context devrait sûrement être de type ULONG_PTR et non unsigned long.
Ainsi, tu n'aurais pas ce warning de portabilité 64 bits.

desole, mais je ne comprends alors pas du tout pourquoi le code ne plante meme pas 8O

Si j ai bien compris, tu enregistres a un moment la callback etn fournissant un pointer sur MaClasse . L api doit conserver ce pointer sous forme de unsigned long et appeler la callback avec ledit parametre (closure).

Je ne comprends deja pas comment l information ne se perd pas au moment de l enregistrement ... alors au moment de l appel ...

Si tu n as meme pas acces a pData , tu ne peux pas non plus faire une structure de pointeur ...

reste la mechante donnee statique :evilred: ( std::map<unsigned long,MaClass *> ) mais c est juste trashouille

smashy: Sur la plupart des plate-formes 32 bits, un long possède une taille suffisante pour contenir un pointeur.
C'est ainsi qu'était utilisé SetWindowLong() sous Windows.

Depuis, les plate-formes 64 bits commencent à se répandre, et cette garantie n'est plus valide. Alors, on utilise des types que l'implémenteur (voire même le standard) garantit comme étant de taille suffisante pour un pointeur: Ici, ULONG_PTR, ou bien sûr intptr_t qui fait désormais partie du standard C99...

peut etre, modifier ma classe telle que

Code:

---

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

class MaClass {   static unsigned long count = 0;   static map<unsigned long,MaClass *> mmm;   int mykey;   MaClass(){   mykey = registerThis(); }   int registerThis(){   mmm[count] = this;   return count++; }   static MaClass * getRegistered(unsigned long l){   return mmm[l] ; /* attention cree une entree systematiquement don a approfondir */ } }

---

Pas de map : C'est complètement exagéré et non-nécessaire.

Citation:

---

Envoyé par Médinoc

smashy: Sur la plupart des plate-formes 32 bits, un long possède une taille suffisante pour contenir un pointeur.

---

Plupart : certes ... donc ca marche mais c est uniquement car c est la mode.
(d ailleurs si le compilateur indique que la taille n est pas suffisante alors ... ben elle n est pas sense etre suffisante)

On peux aussi imaginer que suite a des considerations d alignements memoire, la taille memoire utilisee par la fermeture, et par la mise sur la pile du context est suffisante pour contenir le pointeur mais bon ca ne resta pas tres secure de toute facon.

Note: peu etre est il bon de faire un teste sur un debugger pour trouver les acces a la memoire non initialisee (equivalent de valgrind sous windows a priori)

Citation:

---

Envoyé par Médinoc

Pas de map : C'est complètement exagéré et non-nécessaire.

---

C est certes peut etre un peu exagere, mais si comme ca a l air d etre le cas, le unsigned long ne peut pas contenir de pointeur de maniere sure et maitrisee alors c est peut etre une proposition a consideree

Citation:

---

Envoyé par Médinoc

Ici, ULONG_PTR, ou bien sûr intptr_t qui fait désormais partie du standard C99...

---

Certes, mais ...

Citation:

---

je ne peux pas modifier la signature de ma callback, elle fait partie d'une sdk "externe" à mon projet.

---

... donc il semble qu il faille de toute facon composer avec "unsigned long" et pas ULONG_PTR

Citation:

---

Envoyé par smashy

(d ailleurs si le compilateur indique que la taille n est pas suffisante alors ... ben elle n est pas sense etre suffisante)

---

Perdu. Ce warning indique qu'elle ne serait pas suffisante sur une plate-forme 64 bits. Donc, soit l'API utilisée accepte un ULONG_PTR comme paramètre de callback, soit elle-même n'est pas compatible 64 bits et ce n'est alors pas la peine d'aller plus loin dans cette direction.

Note: Le SDK de Windows définit le type ULONG_PTR ainsi:

• typedef __w64 unsigned long ULONG_PTR; sur une plate-forme 32 bits.
• typedef unsigned __int64 ULONG_PTR; sur une plate-forme 64 bits.

Sachant que le préfixe __w64 signifie "ce type fait 32 bits sur une plate-forme 32 bits, mais fera 64 bits sur une plate-forme 64 bits. Les types comme intptr_t et size_t possède ce préfixe, et les pointeurs font comme s'ils l'avaient.
Résultat, on obtient un warning de portabilité 64 bits si l'on tente d'affecter un type "avec __w64" (ou un pointeur) à un type "sans __w64", sans cast explicite pour la taille.

Citation:

---

Envoyé par Médinoc

. Ce warning indique qu'elle ne serait pas suffisante sur une plate-forme 64 bits.

---

Perso, avec un tel warning j'aurais pas ete capable de decrypter par "attention ne marchera pas sur 64 bits !".

J'aurai decrypte comme "attention , pas sense marche sur la plate-forme courante"

C'est pour cela que ces warnings disparaissent si l'on supprime l'option "warnings de portabilité 64 bits" (/wp64) dans un projet VS 2005.

• La méthode "soigner la maladie à la source" pour virer le warning, c'est de remplacer les unsigned long concernés par des ULONG_PTR.
• La méthode "prend cette aspirine et on verra plus tard", c'est de supprimer l'option /wp64 du projet.
• La méthode "casser le thermomètre" pour le virer, c'est de static_caster en ULONG_PTR avant de reinterpret_caster en pointeur.

(méthodes classées de la meilleure à la pire).

Okay!! Merci Médinoc :D
Je n'avais pas compris que c'était un warning dû à la portabilité sur 64bits. Du coup, j'ai supprimé l'option de compilation (detect 64 bits portalibity issues) et je n'ai plus mon warning.
De toutes façon, l'API en question c'est twain_32, et comme son nom l'indique... elle n'est pas portable sur 64 bits. :p

Si tu as posté avant que j'édite mon dernier post, tu as donc choisi la solution "aspirine". Ce n'est pas la pire, et dans ton cas, c'est celle que j'aurais conseillée.

Magistral ! Merci pour le cours

Haaaa les joies de TWAIN ;)
Il n'existe pas de version 64 bits de TWAIN, et le TWAIN de base était du 16/32 bits. C'est quand même vachement vieux (et lent).

Il y a nécessité à utiliser TWAIN ?
Parceque sinon, WIA est un meilleur choix pour les plateformes actuelles, à mon avis...

Citation:

---

Envoyé par nicroman

Il y a nécessité à utiliser TWAIN ?

---

Non, je l'ai choisi parce que j'aime bien me prendre la tête pour rien :aie:
;)
Plus sérieusement, je n'ai pas le choix, je dois faire un pilote twain. Mais si j'ai un peu de temps, je vais jeter un coup d'oeil du côté de WIA lorsque mon driver fonctionnera. Quels sont les avantages à utiliser WIA?