Parenthèse
Le sens exact du cast C dépend du contexte en C++. La simple présence d'un type non défini, mais juste déclaré (dans l'expression) peut aussi changer son sens.
C'est pour ça qu'il vaut mieux l'éviter, parce que si le static_cast ou le dynamic_cast ne passent pas, ben au pire il fera le reinterpret_cast, là ou il eut fallu avertir le programmeur qu'il à fait une connerie, parce que celui-ci voulait utiliser un static_cast en fait (pour imager).
Quant à reinterpret_cast<>, comme son nom l'indique, c'est pour interpréter autrement une séquence d'octets. Je suis d'ailleurs surpris que tu dises que ce soit lui à utiliser sur un dlopen car la norme préconise static_cast<> vers et depuis du void*.
Pour le static_cast du dlopen… bah, en fait, je me suis planté, je pensais à dlsym, puisque dlopen renvoie un pointeur vers on-ne-sait-quoi, qui doit donc rester void*.
Le retour de dlsym (qui lui renvoie le pointeur vers fonction) à lui bien besoin d'être casté pour être exploitable, en revanche, merci pour m'avoir rapporté mon erreur et permis de corriger mes propres propos.
C'est donc pour dlsym et son retour qu'il faut utiliser le reinterpret_cast
PS: Passer au C++ moderne (RAII, lib standard) limite grandement les risques autour de la mémoire. Il faut juste se débarrasser de sa façon de programmer C, et plutôt se rapprocher de ce que l'Ada nous apprend (vu comme il est compliqué (comme dans, il faut vraiment le faire exprès et le vouloir) d'aller bidouiller la mémoire avec lui—dans mes souvenirs)
C'est ce que je voulais mettre en exergue par mon post, C++ est relativement sûr. Toutefois, j'ai beau adorer RAII, certaines erreurs (qui sont de ma part, je ne le nie pas) sont parfois complexes à détecter. Allez, rien que le fait qu'on ne puisse utiliser de références dans les templates, ça force à l'utilisation de smart pointers pour les collections, et aux galères qui viennent avec. unique_ptr n'est pas franchement si agréable que ça à utiliser.
D'ailleurs, j'espère que le prochain C++ intégrera une lib comme celle fournie par boost::pointer_container (pas sûr du nom exact) qui permet de gérer des collections polymorphes sans se casser la tête, bien qu'il reste quelques failles mineures qui font qu'on utilise malgré tout encore des pointeurs (puisqu'on veut parfois une référence sur un objet, mais sans le copier, et que cette lib ne permet "que" de rentrer des objets entiers, les clonant si nécessaire, et nettoyant la mémoire à la destruction.) ou permettra directement l'usage des références par les templates. M'est avis que ça m'enlèverai une sacrée épine des pieds.
[^] # Re: Popularité
Posté par freem . En réponse à la dépêche Publication de la nouvelle norme Ada 2012. Évalué à 3.
C'est pour ça qu'il vaut mieux l'éviter, parce que si le static_cast ou le dynamic_cast ne passent pas, ben au pire il fera le reinterpret_cast, là ou il eut fallu avertir le programmeur qu'il à fait une connerie, parce que celui-ci voulait utiliser un static_cast en fait (pour imager).
Pour le static_cast du dlopen… bah, en fait, je me suis planté, je pensais à dlsym, puisque dlopen renvoie un pointeur vers on-ne-sait-quoi, qui doit donc rester void*.
Le retour de dlsym (qui lui renvoie le pointeur vers fonction) à lui bien besoin d'être casté pour être exploitable, en revanche, merci pour m'avoir rapporté mon erreur et permis de corriger mes propres propos.
C'est donc pour dlsym et son retour qu'il faut utiliser le reinterpret_cast
C'est ce que je voulais mettre en exergue par mon post, C++ est relativement sûr. Toutefois, j'ai beau adorer RAII, certaines erreurs (qui sont de ma part, je ne le nie pas) sont parfois complexes à détecter. Allez, rien que le fait qu'on ne puisse utiliser de références dans les templates, ça force à l'utilisation de smart pointers pour les collections, et aux galères qui viennent avec. unique_ptr n'est pas franchement si agréable que ça à utiliser.
D'ailleurs, j'espère que le prochain C++ intégrera une lib comme celle fournie par boost::pointer_container (pas sûr du nom exact) qui permet de gérer des collections polymorphes sans se casser la tête, bien qu'il reste quelques failles mineures qui font qu'on utilise malgré tout encore des pointeurs (puisqu'on veut parfois une référence sur un objet, mais sans le copier, et que cette lib ne permet "que" de rentrer des objets entiers, les clonant si nécessaire, et nettoyant la mémoire à la destruction.) ou permettra directement l'usage des références par les templates. M'est avis que ça m'enlèverai une sacrée épine des pieds.