Vu que Zig n'a pas de notion de destructeur, t'es obligé de mettre ton defer (et le unlock) dans le main
Oui tout à fait, mais du coup on se retrouve avec une fonction qui retourne une ressource devant être impérativement nettoyée... mais rien pour garantir que ce sera fait ! (le fameux RTFM quoi ̄\(ツ)/ ̄ )
C'est le retour du bug classique façon:
intfoo(){lock_mutex();if(a){// fait plein de truc compliquésrelease_mutex();returnx;}elseif(b){// encore d'autres trucs compliquésrelease_mutex();returny;}elseif(c){// Hop ! une PR ajoute cette nouvelle condition// toujours plus de trucs compliqués...// ... et on a oublié de release le mutex, c'est vendredi la review est un peu molle, ça part en prod, Ariane 5 explose en volreturnz;}}
La solution qu'a choisi Zig pour contrer ce problème est un puissant système de vérification à la runtime quand on compile avec le profile de test (et aussi en mode release-safe).
C'est largement mieux que C, mais ça ne vaut pas une vérification exhaustive à la compilation (comme permet le RAII): on ne détectera le problème que si on passe dedans pendant notre phase de test.
Et donc c'est typiquement le code peu utilisé (ou galère à tester) genre gestion de cas d'erreur dans un cas aux limites qui se retrouve à contenir des bugs (comprendre: les bugs les plus horribles à reproduire)
Enfin, autant ce type de checks marche pour vérifier des erreurs d'allocations genre use-after-free, autant il n'est d'aucune utilité pour de la gestion de ressource comme dans mon exemple...
c'est pourquoi je réserverai Zig pour de l'embarqué, de la programmation système ou des librairies qui ont besoin d'être très optimisées
J'ai l'impression que Zig est très séduisant pour les devs C car on garde la philosophie une très forte compatibilité avec le C (Zig se vent comme étant capable de s'intégrer dans un projet C existant) tout en fournissant un langage avec tooling et écosystème au bas mot 20ans en avance par rapport au C99... Ho wait !
[^] # Re: Mais pourquoi diantre pas de RAII ?
Posté par G.bleu (site web personnel) . En réponse à la dépêche De Zig et des zags. Évalué à 4. Dernière modification le 13 septembre 2023 à 00:08.
Oui tout à fait, mais du coup on se retrouve avec une fonction qui retourne une ressource devant être impérativement nettoyée... mais rien pour garantir que ce sera fait ! (le fameux RTFM quoi ̄\(ツ)/ ̄ )
C'est le retour du bug classique façon:
La solution qu'a choisi Zig pour contrer ce problème est un puissant système de vérification à la runtime quand on compile avec le profile de test (et aussi en mode release-safe).
C'est largement mieux que C, mais ça ne vaut pas une vérification exhaustive à la compilation (comme permet le RAII): on ne détectera le problème que si on passe dedans pendant notre phase de test.
Et donc c'est typiquement le code peu utilisé (ou galère à tester) genre gestion de cas d'erreur dans un cas aux limites qui se retrouve à contenir des bugs (comprendre: les bugs les plus horribles à reproduire)
Enfin, autant ce type de checks marche pour vérifier des erreurs d'allocations genre use-after-free, autant il n'est d'aucune utilité pour de la gestion de ressource comme dans mon exemple...
J'ai l'impression que Zig est très séduisant pour les devs C car on garde la philosophie une très forte compatibilité avec le C (Zig se vent comme étant capable de s'intégrer dans un projet C existant) tout en fournissant un langage avec tooling et écosystème au bas mot 20ans en avance par rapport au C99... Ho wait !