Note que tu peux faire quelque chose de proche avec les exceptions dans de nombreux langage, mais ce n'est pas aussi propre car l'exception n’apparaît pas dans le type de la fonction et n'est pas forcement vérifiée par le compilateur.
Accessoirement, les exceptions ont un coût à l'exécution nul, mais augmentent la taille du binaire, coûtent cher quand elles sont lancées, et, en C++, nécessitent tout un tas de glue, tout en ne pouvant pas transiter entre deux binaires correctement, sans parler du fait qu'une exception pas rattrapée semble être un comportement indéfini.
Bref, je n'aime plus les exceptions, que l'on a trop vendues comme la panacée à mon goût.
Au passage, cette histoire de taille de binaire augmenté pour de bonnes performances CPU, c'est un truc qui commence à me titiller en C++: tout est axé sur la performance de calcul, mais on n'a que peu de contrôle sur la performance mémoire je trouve (typiquement, estimer la taille d'un std::map est complexe, et nécessite une connaissance de l'implém sous-jacente). Sauf que le cache augmente moins vite que la vitesse de calcul, donc je ne suis pas sûr que l'approche "tout pour le CPU" soit idéale.
C'était les exemples de compositions.
Merci.
Oui ;) Et si on pouvait avoir des vrais enums typés (i.e: pas de faux int) ce serait mieux ;)
[^] # Re: Moi == pas doué, je suppose....
Posté par freem . En réponse au journal Haskell et le tri. Évalué à 2.
Accessoirement, les exceptions ont un coût à l'exécution nul, mais augmentent la taille du binaire, coûtent cher quand elles sont lancées, et, en C++, nécessitent tout un tas de glue, tout en ne pouvant pas transiter entre deux binaires correctement, sans parler du fait qu'une exception pas rattrapée semble être un comportement indéfini.
Bref, je n'aime plus les exceptions, que l'on a trop vendues comme la panacée à mon goût.
Au passage, cette histoire de taille de binaire augmenté pour de bonnes performances CPU, c'est un truc qui commence à me titiller en C++: tout est axé sur la performance de calcul, mais on n'a que peu de contrôle sur la performance mémoire je trouve (typiquement, estimer la taille d'un std::map est complexe, et nécessite une connaissance de l'implém sous-jacente). Sauf que le cache augmente moins vite que la vitesse de calcul, donc je ne suis pas sûr que l'approche "tout pour le CPU" soit idéale.
Merci.
Un peu comme ça:
?