c'est quand même parce qu'un compilateur C bien configuré
Admettons. Et pour le cast vers et depuis du void*, tu rétorques quoi? (casts qui sont obligatoires dès lors que l'on veut interagir avec une lib dynamique au runtime, et non au démarrage de l'appli, pour rappel, à moins qu'il existe autre chose que dlsym?)
Franchement, j'aimerai beaucoup qu'il y ait plus sécurité au niveau des casts en C. Parce que dans les langages qui ont des capacités de plus haut niveau, on subit cette faiblesse quand on doit utiliser une lib codée en C, pour une raison X ou Y (j'ai pris l'exemple de dlfcn.h ici, mais ce n'est qu'un exemple, hein, ça pourrait être une lib maison qu'il est obligé d'utiliser, peu importe.).
mais reinterpret_cast ou static_cast ne sont pas non plus la panacée.
Comme je l'ai dis. D'ailleurs le reinterpret_cast est l'égal du transtypage du C, à un très gros avantage près: il est super long à taper (sauf avec une auto-complete potable, mais celle de vim étant ce qu'elle est...)/lire, et du coup, ça décourage :)
[^] # Re: C++
Posté par freem . En réponse au journal CPP Con sur Youtube. Évalué à 3.
Admettons. Et pour le cast vers et depuis du void*, tu rétorques quoi? (casts qui sont obligatoires dès lors que l'on veut interagir avec une lib dynamique au runtime, et non au démarrage de l'appli, pour rappel, à moins qu'il existe autre chose que dlsym?)
Franchement, j'aimerai beaucoup qu'il y ait plus sécurité au niveau des casts en C. Parce que dans les langages qui ont des capacités de plus haut niveau, on subit cette faiblesse quand on doit utiliser une lib codée en C, pour une raison X ou Y (j'ai pris l'exemple de dlfcn.h ici, mais ce n'est qu'un exemple, hein, ça pourrait être une lib maison qu'il est obligé d'utiliser, peu importe.).
Comme je l'ai dis. D'ailleurs le reinterpret_cast est l'égal du transtypage du C, à un très gros avantage près: il est super long à taper (sauf avec une auto-complete potable, mais celle de vim étant ce qu'elle est...)/lire, et du coup, ça décourage :)