[quote]Une première chose est la verbosité des déclarations. Finalement, les histoires de "@safe pure nothrow" ne sont que des commandes d'optimisation, que l'on utilise principalement pour aider les compilos. Je ne suis pas certain que ça soit au programmeur de gérer ça. La raison principale est que, selon mon expérience, ça nuit à l'évolution et à la flexibilité du programme. Je ne connais pas assez D, mais en C++, on se tape des arbres super-complexes de const à gérer ; modifier le status "const" d'une variable est quasiment impossible dans un programme complexe, le compilo hurle avec des milliers de messages d'erreur, et on finit par saloper le design avec des mutable, et/ou par dupliquer toutes les méthodes avec une version const et une version non-const strictement identiques. Je pense que les langages doivent aussi être conçus pour les gens qui ne sont pas des experts en programmation, y compris en évitant au maximum de faire faire le boulot du compilo aux programmeurs.[/quote]
Tout dépend des contraintes et de l'exigence que tu as sur ton projet. Si tu t'en fou de savoir qu'une fonction ne lance jamais d'exception, tu te balances donc de savoir si ton programme sera stable. Si en C++, et visiblement en D, on indique la capacité à lancer des exceptions (et lesquelles), c'est pour garantir un contrat. C'est très important pour une fonction utilisée dans un destructeur, par exemple. Et ça, le compilateur ne peut pas le deviner tout seul lors de la compilation de la fonction.
Je suis d'accord que la gestion des capacités const et non-const est parfois galère. Mais il ne faut pas oublier que, si une fonction membre const modifie l'objet sur lequel elle est appelée, il y a peut-être un problème de design.
Enfin, si tu as deux fonctions au contenu identique, et que la seule différence est ça constness, c'est que tu ne connais pas cette méthode :
[^] # Re: Y'a-t-il encore besoin de nouveaux langages "bas niveau"?
Posté par LupusMic (site web personnel, Mastodon) . En réponse à la dépêche Le langage D. Évalué à 1.
[quote]Une première chose est la verbosité des déclarations. Finalement, les histoires de "@safe pure nothrow" ne sont que des commandes d'optimisation, que l'on utilise principalement pour aider les compilos. Je ne suis pas certain que ça soit au programmeur de gérer ça. La raison principale est que, selon mon expérience, ça nuit à l'évolution et à la flexibilité du programme. Je ne connais pas assez D, mais en C++, on se tape des arbres super-complexes de const à gérer ; modifier le status "const" d'une variable est quasiment impossible dans un programme complexe, le compilo hurle avec des milliers de messages d'erreur, et on finit par saloper le design avec des mutable, et/ou par dupliquer toutes les méthodes avec une version const et une version non-const strictement identiques. Je pense que les langages doivent aussi être conçus pour les gens qui ne sont pas des experts en programmation, y compris en évitant au maximum de faire faire le boulot du compilo aux programmeurs.[/quote]
Tout dépend des contraintes et de l'exigence que tu as sur ton projet. Si tu t'en fou de savoir qu'une fonction ne lance jamais d'exception, tu te balances donc de savoir si ton programme sera stable. Si en C++, et visiblement en D, on indique la capacité à lancer des exceptions (et lesquelles), c'est pour garantir un contrat. C'est très important pour une fonction utilisée dans un destructeur, par exemple. Et ça, le compilateur ne peut pas le deviner tout seul lors de la compilation de la fonction.
Je suis d'accord que la gestion des capacités const et non-const est parfois galère. Mais il ne faut pas oublier que, si une fonction membre const modifie l'objet sur lequel elle est appelée, il y a peut-être un problème de design.
Enfin, si tu as deux fonctions au contenu identique, et que la seule différence est ça constness, c'est que tu ne connais pas cette méthode :
Comment ça la seconde fonction est illisible :D