Ce n'est pas le compilateur qui est trop intelligent, c'est l'utilisateur qui est trop bête.
Ou bien tout simplement c'est la spécification du langage qui laisse une place trop importante aux comportements indéfinis.
Ici, il prend la seule décision rationnelle en fonction de ce qu'il sait
Ça veut dire quoi décision rationnelle ? Par construction un comportement indéfini c'est ... Indéfini. Si le compilateur avait décidé de remplacer l'appel par un bout de code qui affiche "Bonjour" ça aurait été tout autant valide vis-à-vis de la spécification.
ce n'est pas le compilateur qui a écrit cette fonction
Mais c'est le compilateur qui décide de ré-écrire le code source. Il se trouve qu'il ré-écrit un code qui n'a pas de sémantique en un code qui en a une, et c'est bien ici que se trouve la "surprise". On peut dire que c'est la faute de la personne qui programme, mais si on évite tous les comportements indéfinis en C/C++ ... on est mal parti. Le reproche est bien sur le langage: à tout vouloir déléguer à la discrétion du compilateur, un programme qui devrait (selon moi) ne pas compiler se retrouve à avoir une sémantique éloignée de celle imaginée par l'utilisateur.
Pour conclure, il est assez facile de se retrouver dans cette situation: il suffit qu'au cours d'une modification on supprime sans y faire attention une définition préalable de Do.... Normalement c'est pour ce genre d'erreurs qu'un système de type et un compilateur en général sont utiles.
[^] # Re: Utilisateur trop bête
Posté par Aluminium95 . En réponse au journal Compilateur trop intelligent. Évalué à 10.
Ou bien tout simplement c'est la spécification du langage qui laisse une place trop importante aux comportements indéfinis.
Ça veut dire quoi décision rationnelle ? Par construction un comportement indéfini c'est ... Indéfini. Si le compilateur avait décidé de remplacer l'appel par un bout de code qui affiche "Bonjour" ça aurait été tout autant valide vis-à-vis de la spécification.
Mais c'est le compilateur qui décide de ré-écrire le code source. Il se trouve qu'il ré-écrit un code qui n'a pas de sémantique en un code qui en a une, et c'est bien ici que se trouve la "surprise". On peut dire que c'est la faute de la personne qui programme, mais si on évite tous les comportements indéfinis en C/C++ ... on est mal parti. Le reproche est bien sur le langage: à tout vouloir déléguer à la discrétion du compilateur, un programme qui devrait (selon moi) ne pas compiler se retrouve à avoir une sémantique éloignée de celle imaginée par l'utilisateur.
Pour conclure, il est assez facile de se retrouver dans cette situation: il suffit qu'au cours d'une modification on supprime sans y faire attention une définition préalable de
Do.... Normalement c'est pour ce genre d'erreurs qu'un système de type et un compilateur en général sont utiles.