Conversion d'un void *objet

Bonjour,

Pour un appel callback dans un trackbar d'opencv, ça fait 3 jours que j'essaie de convertir un objet void *adresse en un objet Myclass myobjet_dst, étant entendu que le *adresse pointe vers un objet de type Myclass myobjet_src.

J'ai essayé

Code:

---

1 2 3 4 5 6

void ontrack(int param, void *adresse) {   Myclass *myobjet_dst = static_cast<Myclass*>(adresse); ...}

---

ou encore

Code:

---

1 2 3 4 5

void ontrack(int param, void *adresse) { Myclass& myobjet_dst = (Myclass&)(adresse) ...}

---

et j'en passe.
Faut-il créer un constructeur particulier pour Myclass, qui prendrait une adresse en paramètre d'entrée ?

Je sèche sur ce problème.

Merci par avance pour votre aide.

Code:

---

Myclass *myobjet_dst = reinterpret_cast<Myclass*>(adresse);

---

static_cast est pour les objets ayant une relation d'héritage entre eux, ou pour les types ayant défini des conversions implicites de la source à la cible.
reinterpret_cast est pour "forcer" le cast d'un type à un autre (avec certaines règles, cependant, cf. la doc), déconseillé si on ne sait pas ce qu'on fait.
Je ne parlerai pas du troisième qui n'a aucune utilité bien fondée :P

merci beaucoup pour ton aide et ta réponse plus que rapide.

static_cast est bien le cast officiel pour gérer les conversion depuis void* (probablement parce qu'il n'y a pas de garantie que sizeof(void*) == sizeof(T*)). Corrigé avec le C++11 on dirait.

Le reinterpret_cast a vraiment corrigé le problème ? Je serai plutôt parti sur la piste d'un problème à l'appel.

Code:

---

Myclass& myobjet_dst = *((Myclass*)(adresse))

---

Ne JA-MAIS faire de casts à la C en C++. Surtout quand des classes sont impliquées. Les chances pour que cela parte en cacahuète sont trop importantes. Un code qui marche peut planter après un refactoring. Donc oublis!

Au mieux ici si tu veux une référence.

Code:

---

1 2 3 4 5

void ontrack(int param, void *adresse) { assert(addresse); Myclass & myobjet_dst = *static_cast<Myclass*>(adresse); }

---

Citation:

---

Ne JA-MAIS faire de casts à la C en C++

---

Regarder tous les codes type Unreal Engine 4 et autre qui ne veulent pas du RTTI, on cast à la C. Drivers on cast à la C, performance on cast à la C.
Faut pas être cartésien comme ça. Faut savoir ce que l'on fait c'est tout.

Et puis ca permet de donner du galon au développeur en comprenant les avantages et inconvénient de chacun.

Citation:

---

Envoyé par Astraya

autre qui ne veulent pas du RTTI, on cast à la C.

---

Ceux qui ne veulent pas de RTTI n'utilise pas dynamic_cast. Il en reste toujours 3. De manière générale, dynamique_cast est une mauvaise idée.

Citation:

---

Envoyé par Astraya

Drivers on cast à la C.

---

Tu veux dire que dans les drivers écrit en C on utilise des casts C ? Faudrait en trouver un écrit en C++ pour vérifier.

Citation:

---

Envoyé par Astraya

performance on cast à la C.

---

Rien à voir, les casts sont compile-time.
(Au delà de ça, je doute qu' un cast soit une bonne chose pour les performances.)

Citation:

---

Envoyé par Astraya

Faut pas être cartésien comme ça. Faut savoir ce que l'on fait c'est tout.

---

Question innocente: que fait un cast C en c++ ? En sachant que c'est entre autres un mélange de static_cast, reinterpret_cast et const_cast.

Citation:

---

Envoyé par Astraya

Et puis ca permet de donner du galon au développeur en comprenant les avantages et inconvénient de chacun.

---

Autant qu'utiliser malloc à la place de new. Perso, je vois très bien les avantages des casts C++: plus safe, plus explicite,
Mais aucuns pour les casts C. À moins qu'accéder aux classes héritées de façon privée soit un avantage ?

Citation:

---

Envoyé par crazyfroggy

Code:

---

1 2 3 4 5 6

void ontrack(int param, void *adresse) {   Myclass *myobjet_dst = static_cast<Myclass*>(adresse); }

---

---

Pourtant, dans la doc de static_cast, on peut lire :

Citation:

---

10) A prvalue of type pointer to void (possibly cv-qualified) can be converted to pointer to any type. If the value of the original pointer satisfies the alignment requirement of the target type, then the resulting pointer value is unchanged, otherwise it is unspecified. Conversion of any pointer to pointer to void and back to pointer to the original (or more cv-qualified) type preserves its original value.
[...]

Code:

---

1 2 3

// 10. void* to any type void* voidp = &e; std::vector<int>* p = static_cast<std::vector<int>*>(voidp);

---

---

Chez moi, le code suivant compile :

Code:

---

1 2 3 4 5

struct Foo {}; void bar(void* adresse) { Foo* ptr = static_cast<Foo*>(adresse); }

---

Citation:

---

Envoyé par Astraya

Regarder tous les codes type Unreal Engine 4 et autre qui ne veulent pas du RTTI, on cast à la C. Drivers on cast à la C, performance on cast à la C.

---

En C++, le cast avec la syntaxe du C n'est pas plus performant !
C'est seulement :

• soit une combinaison implicite de const_cast, de static_cast et de reinterpret_cast,
• soit une conversion que ne permettent pas les xxxxx_cast ci-dessus.

Documentation :

Citation:

---

When the C-style cast expression is encountered, the compiler attempts to interpret it as the following cast expressions, in this order:
a) const_cast<new_type>(expression);
b) static_cast<new_type>(expression), with extensions: pointer or reference to a derived class is additionally allowed to be cast to pointer or reference to unambiguous base class (and vice versa) even if the base class is inaccessible (that is, this cast ignores the private inheritance specifier). Same applies to casting pointer to member to pointer to member of unambigous non-virtual base;
c) static_cast (with extensions) followed by const_cast;
d) reinterpret_cast<new_type>(expression);
e) reinterpret_cast followed by const_cast.
The first choice that satisfies the requirements of the respective cast operator is selected, even if it cannot be compiled (see example). If the cast can be interpreted in more than one way as static_cast followed by a const_cast, it cannot be compiled.
In addition, C-style cast notation is allowed to cast from, to, and between pointers to incomplete class type. If both expression and new_type are pointers to incomplete class types, it's unspecified whether static_cast or reinterpret_cast gets selected.

---

Edit : Grillé par jo_link_noir.

Et bas je comprends pourquoi je ne venait plus sur le forum :p
Donc pour vous malloc n'a rien a faire dans un programme C++....
Tout comme

Code:

---

(uint8*)::malloc(sizeof(CBuffer))

---

Un void* perd la notion de const/volatile dont un C cast ne pause aucun problème.
De plus niveau portabilité on en reparle :

boost/smart_ptr/shared_ptr.hpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#if ( defined(__GNUC__) && BOOST_WORKAROUND(__GNUC__, < 3) ) || \   ( defined(__EDG_VERSION__) && BOOST_WORKAROUND(__EDG_VERSION__, <= 238) ) || \   ( defined(__HP_aCC) && BOOST_WORKAROUND(__HP_aCC, <= 33500) )   // g++ 2.9x doesn't allow static_cast<X const *>(void *) // apparently EDG 2.38 and HP aCC A.03.35 also don't accept it   template<class D, class T> D * get_deleter(shared_ptr<T> const & p) { void const * q = p._internal_get_deleter(BOOST_SP_TYPEID(D)); return const_cast<D *>(static_cast<D const *>(q)); }   #else   template<class D, class T> D * get_deleter(shared_ptr<T> const & p) { return static_cast<D *>(p._internal_get_deleter(BOOST_SP_TYPEID(D))); } #endif

---

NB : RTTI et performance je pensais au dynamic_cast et pas au reinterpret_cast effectivement.

Là on est sur des compilateurs qui prédatent le standard de 1998. On s'en fout un peu de la compatibilité avec ces bêtes.

Un ligne importante dans les casts C: ils dégénèrent avec des déclarations anticipées. C'est de fait une excellente raison pour les bannir. Hors RTTI, static_cast et reinterpret_cast feront le même boulot et sans ambiguïté. Et dans le cas du RTTI ... n'en parlons même pas, ils ne peuvent pas se substituer à dynamic_cast. Ils en sont incapables.

http://en.cppreference.com/w/cpp/language/explicit_cast

Les cast C fonctionne très bien avec les forward déclarations.

Citation:

---

In addition, C-style cast notation is allowed to cast from, to, and between pointers to incomplete class type. If both expression and new_type are pointers to incomplete class types, it's unspecified whether static_cast or reinterpret_cast gets selected.

---

Pour toi "unspecified" veut dire "marche bien" ? :/

Ta définition est pour le moins singulière: http://www.linguee.fr/anglais-franca...specified.html

J'achète "marche à moitié". Mais "bien", certainement pas.

Citation:

---

Envoyé par Luc Hermitte

Pour toi "unspecified" veut dire "marche bien" ? :/

---

Non :mrgreen: juste que lorsque tu fais un cast à la C, apparemment, le compilateur le remplace par soit un static_cast soit un reinterpret_cast.

Mais si les 2 sont des types incomplets, alors le compilateur fait ce qu'il veut: ce n'est pas spécifié.
Dans un autre sens, si les 2 sont des types incomplets, le compilateur ne peut pas faire de magie :mrgreen:

Et là, plutôt que de la magie, c'est une erreur de compilation que j'attends.

Citation:

---

Envoyé par Astraya

Et bas je comprends pourquoi je ne venait plus sur le forum :p

---

Je te comprends, les gens sont aigris :lol:.

Citation:

---

Envoyé par Astraya

Donc pour vous malloc n'a rien a faire dans un programme C++....

---

Oui. malloc n'apporte pas les garanties qu'offre new, notamment celle d'allouer un type et non un espace mémoire: il est aisé de ne pas faire correspondre sizeof(T) avec le cast qui précède. Cela parait con, mais c'est une erreur difficile à diagnostiquer.
De plus, l'utilisation de malloc oblige d'utiliser l'opérateur new pour la construction (emplacement new). L'oublier, c'est prendre un risque.
Après, rien n'empêche d'utiliser ::operator new pour faire comme malloc: allouer un espace mémoire. Mais c'est un besoin très particulier où la mémoire n'est pas utilisé immédiatement. Les conteneurs de la SL le font à travers des allocateurs.
Pour terminer ::operator new peut prendre des paramètres, le standard propose une version sans exception par exemple. Il est aussi possible d'interdire l'utilisation de new sur certains objets.

Citation:

---

Envoyé par Astraya

Tout comme

Code:

---

(uint8*)::malloc(sizeof(CBuffer))

---

---

Clairement. Cela reprend ce que je disais juste au-dessus: le cast et la taille du type demandé peuvent ne pas correspondre. Reste que si c'est légitime, rien ne l'indique non plus.
Je trouve beaucoup plus judicieux d'utiliser new uint8_t[sizeof(CBuffer)].

Citation:

---

Envoyé par Astraya

Un void* perd la notion de const/volatile dont un C cast ne pause aucun problème.

---

void ne perd pas le qualificatif, mais le type. Passer d'un void const * en T * est un problème.

Un autre reproche du C-cast: il accepte sans broncher quasiment tous les changements qui peuvent intervenir en amont. Même quand ceux-ci invalident la suite comme l'ajout de const qui sont supprimés par le cast.

Mais ce qui m'agace par dessus tout c'est d'entendre des "jamais utiliser ca" de la part d'un développeur. Pour moi c'est du même niveau que "toujours utiliser ca" ( Le concept de la "balle en argent" mais à l'envers :) ).
Alors le "jamais" ne devrais "jamais" (:p) avoir lieu, surtout pas dans un milieu comme le développement. Ça pu la programmation de SSII ce genre de discours.

Quand je vois un void* et que je vois un (T*) derrière c'est tout à fait legit.

Voila c'est tout :) c'était mon coup de gueule contre les jamais c'est pas bien blablabla...

En attendant, tu n'as n'as toujours pas donné un seul argument contre les casts C++ (sauf un problème de compatibilité avec les compilateurs d'il y a 20 ans qu'on se fout pas mal).
Ni un seul argument en faveur du cast C.

Perso j'ai un super argument en faveur du C-cast : écrire reinterpret_cast est d'une lourdeur, c'est long, chiant, y compris avec la complétion, je suis programmeur et flemmard, j'opte pour la facilité. Je me moque que ce soit "pas lisible pour bobdu42", je comprends le code que j'écris, ainsi que tous mes collègues qui travaillent avec, et bobdu42 ne lira jamais ce code, c'est tout ce qui importe. :zekill:
Favoriser reinterpret ou static ou le C-style, y'en a aucun qui a plus de sens qu'un autre. C'est tout juste de la religion à ce niveau. Et si tu forces un cast via un C-style cast qui est impossible, et qu'un static t'aurait signalé, tu ne peux t'en prendre qu'à toi-même. Et ouais c'est une merde à débuguer et retrouver ce genre de problème, ça tombe bien c'est notre boulot.
Les interfaces en C ça existe, et passer n'importe quoi en void* n'est pas extraordinaire ni quelconque magie noire. En tous cas dans mon monde. :weird:
D'ailleurs en pratique dans la pluaprt des cas on passera juste un trivial POD qui contiendra les pointeurs vers les classes nécessaires.

dynamic, on s'en moque. Le RTTI est désactivé le plus souvent parce que c'est un gouffre à perf.

De même qu'utiliser new[] quand on veut allouer un espace et non des objets au lieu de malloc n'apporte rien. Alors pourquoi faire un new uint8[...] ? Parce que new est du C++ et malloc du C ? Ridicule. :calim2:

Dans tous les cas vous avez sévèrement dérivé du sujet d'origine :weird:

Citation:

---

Envoyé par Bousk

écrire reinterpret_cast est d'une lourdeur, c'est long, chiant, y compris avec la complétion,

---

Il me semble que c'est justement fait pour :mouarf: :mouarf:: une écriture lourde, pour les 4 casts C++, pour que les développeurs ne les utilisent pas

Tu es un "bon client" :mrgreen:

L'avantage de reinterpret_cast, c'est qu'il est facile de trouver toutes ses occurrences dans un programme en faisant une simple recherche, contrairement au C-style cast.

Citation:

---

Envoyé par Bousk

Et si tu forces un cast via un C-style cast qui est impossible, et qu'un static t'aurait signalé, tu ne peux t'en prendre qu'à toi-même. Et ouais c'est une merde à débuguer et retrouver ce genre de problème, ça tombe bien c'est notre boulot.

---

Hélas, ce n'est pas toujours celui qui fait des conneries dans un programme qui en subit les corrections. Et nettoyer la merde des autres n'est pas la partie la plus passionnante de notre boulot.

Citation:

---

Envoyé par Bousk

De même qu'utiliser new[] quand on veut allouer un espace et non des objets au lieu de malloc n'apporte rien. Alors pourquoi faire un new uint8[...] ? Parce que new est du C++ et malloc du C ? Ridicule. :calim2:

---

Parce qu'on a sous la main un wrapper RAII standard qui fait delete[], à savoir la spécialisation de unique_ptr pour les tableaux.
Pour faire la même chose avec malloc, c'est plus lourd. Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

template<class T> struct free_deleter { void operator()(T* p) { if(p) free(p); } };   int main() { std::unique_ptr<char,free_deleter<char>> foo((char*) malloc(4)); if(!foo) return -1; strcpy(foo.get(), "bar"); std::cout << foo.get() << std::endl; return 0; } // Le destructeur de foo fait un free.

---

(C'est grave si on continue de dériver ou il faut arrêter ?)

Je suis d'accord pour dire que les cast C sont rapides à écrire, a contrario, ils sont difficilement greppable. Mais les utiliser sachant que le résultat est peut-être une erreur est de mon point vu vraiment pernicieux. Pendant l'écriture ça passe plutôt bien, on sait ce qu'on fait, il n'y a pas de problème. Mais c'est le genre de truc qui pète après les refactoring alors que des erreurs du compilateur serait bien plus appréciable. Perso, je considère le débogage plus comme un échec et une plaie que mon véritable boulot, surtout quand des mécanismes du langage permettent de l'éviter.

Citation:

---

Envoyé par Bousk

De même qu'utiliser new[] quand on veut allouer un espace et non des objets au lieu de malloc n'apporte rien. Alors pourquoi faire un new uint8[...] ? Parce que new est du C++ et malloc du C ? Ridicule. :calim2:

---

Oui et non.
Oui parce que c'est natif C++ et qu'il n'y a pas besoin d'un quelconque header. Et non parce que je ne trouve pas utile d'utiliser 2 mécanismes d'allocations alors que new fonctionne toujours bien.
(Dans les faits je n'utilise pas directement l'un ou l'autre, mais un ensemble de pointeurs intelligents/fonctions de construction qui apportent beaucoup plus de sémantique et de souplesse.)

De toute façon, on pourra lister les bien fait de l'un ou de l'autre, j'ai bien l'impression que chacun campera sur sa position :).

EDIT: je n'avais pas vu la réponse de Pyramidev. Déjà la seconde page ^^.

Citation:

---

En attendant, tu n'as n'as toujours pas donné un seul argument contre les casts C++ (sauf un problème de compatibilité avec les compilateurs d'il y a 20 ans qu'on se fout pas mal).
Ni un seul argument en faveur du cast C.

---

Comme la dis bousk c'est long et chiant. Pour un résultat identique, c'est limite de la torture de lire un code avec plein de reinterpret_cast, const_cast, static_cast...
Quand je vois ca:

Code:

---

const_cast<D *>(static_cast<D const *>(q))

---

Alors que je pourrais avoir ca:

Code:

---

(D*)q

---

Bas ya pas photo perso :)

Il y a le mauvais codeur et le bon codeur. Le mauvais il cast, le bon il cast, mais c'est un bon codeur.

PS: Ca fait du bien de troller un peu :p

Pour avoir débogué une application de plusieurs centaines de milliers de lignes, qui utilisait des unions (avec plein de cochonneries à l'intérieur, et surtout des trucs de tailles diffférentes), et des C-Cast entre des types qui n'avaient rien à voir entre eux (parmi ceux dispo dans cette union), pour moi la plaie c'est le C-Cast. Il m'a fallu des semaines pour en trouver la majorité, et encore maintenant on en a qui pètent de temps en temps.
En C++ on a des cast "propres" qui nous fournissent un meilleur contrôle de ce que l'on fait, utilisons les, pas uniquement pour nous, mais aussi pour ceux qui vont maintenir le code par la suite...

Citation:

---

Envoyé par Astraya

Quand je vois ca:

Code:

---

const_cast<D *>(static_cast<D const *>(q))

---

Alors que je pourrais avoir ca:

Code:

---

(D*)q

---

Bas ya pas photo perso :)

---

J'avais pensé à ce cas théorique. Mais l'as-tu rencontré, ne serait-ce qu'une seule fois, en pratique ?
Sinon, dans quel cas risquerait-on de le rencontrer ?

Dans tout code qualifié d'erreur de conception (?)

Finalement, je viens de créer un exemple, mais il faut y aller fort :

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 27 28 29 30 31 32 33 34

///////////////////////////////////////////////////////// // Code accessible uniquement en lecture (niark niark) // /////////////////////////////////////////////////////////   class Carensac : public Bonbon { public: // Fonction non virtuelle absente de la classe Bonbon : Couleur getCouleur(); // L'auteur a oublié le const. // ... };   class PacketDeBonbons { public: virtual const Bonbon& operator[](size_t indice) const = 0; // ... // pas de fonction "void ajouter(Bonbon&)" car un bonbon n'est pas forcément un carensac. };   class PacketDeCarensacs : public PacketDeBonbons { public: const Bonbon& operator[](size_t indice) const override; // Problème : devrait retourner const Carensac&. // Mais l'auteur ne connaît pas les types de retour covariants. // ... };   /////////////////////////// // Code de l'utilisateur // ///////////////////////////   Couleur couleurDuPremierCarensac(const PacketDeCarensacs& paquet) { assert(paquet.nbElements() > 0); return const_cast<Carensac&>(static_cast<const Carensac&>(paquet[0])).getCouleur(); }

---

EDIT : oubli d'un mot-clé public.

Citation:

---

Dans tout code qualifié d'erreur de conception (?)

---

Citation:

---

'avais pensé à ce cas théorique. Mais l'as-tu rencontré, ne serait-ce qu'une seule fois, en pratique ?

---

Dans boost.
Travaillant moi même dans un milieu n'utilisant pas la stl, on peut rencontrer très souvent ce genre de chose, tout comme des mallocs.

Quand au fait de chercher tout les reinterpret_cast pour savoir ou est l'erreur c'est que de base il y a un gros souci de lisibilité du code à la base.

Citation:

---

Pour avoir débogué une application de plusieurs centaines de milliers de lignes, qui utilisait des unions (avec plein de cochonneries à l'intérieur, et surtout des trucs de tailles diffférentes), et des C-Cast entre des types qui n'avaient rien à voir entre eux (parmi ceux dispo dans cette union)

---

Le souci est peut-être le codeur et pas le cast non?... Tu peux faire le même bordel avec que des cast C++ ça n'arrange rien au souci et au fait que le code est du n'importe quoi.

Citation:

---

Envoyé par Astraya

Le souci est peut-être le codeur et pas le cast non?... Tu peux faire le même bordel avec que des cast C++ ça n'arrange rien au souci et au fait que le code est du n'importe quoi.

---

Je ne dis pas le contraire, mais je dirais que ce sont les codeurs, c'est une appli qui a 30 ans de vie, et je ne sais même pas combien de développeurs ont travaillé dessus, mais le problème était là, et il a bien fallu le résoudre.
Le fait que ce soient des C-Cast ne m'a pas permis de faire une recherche exhaustive de tous les endroits où on faisait n'importe quoi...

Franchement, quand je travaille avec COM, les casts en void**, je les fais C-Style, principalement par paresse. Mais je suis très à-cheval sur la const-correctness, et si je dois absolument caster pour virer un const, j'utilise systématiquement un const_cast, notamment parce que c'est cherchable (contrairement aux casts C-style).