Les erreurs sémantiques peuvent-elles être détectées par le compilateur ou non? Sinon, quand les erreurs sont-elles détectées?
Autant que je connaisse des erreurs sémantiques, ce sont ces erreurs résultant des expressions impliquant des opérateurs avec un nombre incorrect / type d'opérandes. p>
par exemple: p>
n3=n1*n2;//n1 is integer, n2 is a string, n3 is an integer
11 Réponses :
"Erreur sémantique" est un autre terme pour "Erreur logique", où vous écrivez littéralement le mauvais code. Par exemple, l'écriture L'erreur que vous avez décrite dans votre exemple est une erreur de sécurité de type et les compilateurs peuvent attraper cela au cours de leur phase de dactylographie (si la langue est fortement typée) p> n3 = n1 * n2 code> Quand vous vouliez vraiment diviser - le compilateur n'a aucun moyen de dire que votre algorithme aurait dû diviser au lieu de se multiplier; vous l'avez dit de multiplier, donc ça fait. P>
Cela dépend un peu sur la façon dont vous utilisez les mots, et je pense que la plupart des compilateurs seraient en désaccord avec cette réponse. Un compilateur est généralement considéré comme composé de plusieurs "phases". L'une est une analyse syntaxique, généralement appelée "analyseur", qui peut attraper des erreurs grammaticales. Cet exemple n'est pas une erreur grammaticale. Une autre phase est une analyse sémantique, qui gère principalement des types de données et peut prendre des erreurs de type tels que celui-ci. Par conséquent, ce type d'erreur est souvent appelé une erreur sémantique.
@THOMAS qui explique où l'OP l'entendit; Le terme est apparemment utilisé différemment, comme Wikipedia définit it la façon dont j'ai dit
Les erreurs sémantiques sont toutes celles-ci, où votre code fait quelque chose que vous n'avez pas intenu. p>
Ces erreurs peuvent être capturées par test ou analyse. P>
Analyse signifie que vous ou un outil examine votre code et essayer de trouver des problèmes. Cela implique d'utiliser des critiques de code et des analyseurs statiques. P>
Test est lorsque vous donnez à votre programme des entrées qui devraient produire une sortie donnée si le programme est sémantiquement correct. Donc, si la sortie réelle ne correspond pas à la sortie attendue, le programme est sémantiquement incorrect. P>
Mettez simplement simplement, c'est vous le développeur ou le testeur qui est censé attraper des erreurs sémantiques. P>
En réalité, multiplier une chaîne et un entier est une erreur syntaxique car la multiplication des types incompatibles (telles qu'une chaîne et un entier) n'est pas définie dans c. P>
Une erreur sémantique est une erreur qui se produit lorsque votre programme compile, mais ne fait pas ce que vous voulez. p>
Cette citation parle de choses comme faire un Mais pour la sémantique de la langue (ne pas être autorisé à ajouter une chaîne et un entier), oui c'est le compilateur qui gère cela. P> x <= 1 code> où vous auriez vraiment dû faire x <1 code>. P>.
C'est une erreur syntaxique, quels compilateurs peuvent en effet détecter et signaler. p>
Une erreur sémantique ressemble plus à quelque chose qui compile bien (jusqu'aux types mêmes), mais n'est pas ce que vous voulez que ce soit. Les erreurs sémantiques font partie de votre algorithme de plus que votre syntaxe réelle. P>
Si ce n'est pas le compilateur, qui détecte ces erreurs? P> blockQuote>
Parfois, NO-One: le compilateur n'a pas à insérer des contrôles de temps d'exécution pouvant aider à remarquer l'erreur lorsqu'elle se produit et que l'exécution se poursuit. P>
Parfois, l'environnement d'exécution: le programme accède à une adresse non valide en raison d'une erreur et est en dehors de l'espace d'adressage que le processus peut accéder légalement. P>
Vous pouvez utiliser compléter le compilateur avec un analyseur statique pour détecter une partie ou toutes les erreurs d'un programme, mais celles-ci peuvent également avoir faux positifs em>: ils peuvent émettre un avertissement pour un morceau de code cela fonctionne sans erreurs. P>
Je pense que l'écrivain qui a écrit le livre défini "sémantique" différemment. Pour la plupart des compilateurs, il y a une étape impliquant un peu de Vérifications sémantiques . p>
L'analyse sémantique est la phase dans laquelle le compilateur ajoute des informations sémantiques à l'arborescence d'analyse et construit la table des symboles. Cette phase effectue des vérifications sémantiques telles que la vérification de type (vérification des erreurs de type) ou une liaison d'objet (association de références variables et fonction avec leurs définitions), ou une affectation définitive (nécessitant toutes les variables locales à être initialisées avant utilisation), rejetant des programmes incorrects ou émettrices mises en garde. L'analyse sémantique nécessite généralement un arbre d'analyse complet, ce qui signifie que cette phase suit logiquement la phase d'analyse et précède logiquement la phase de génération de code, bien qu'elle soit souvent possible de plier plusieurs phases en une passer sur le code dans une implémentation du compilateur. P > blockQuote>
effectivement (comme il n'y a pas de logiquement (sémantiquement) La déclaration fait très peu de sens, il est donc probablement une erreur de codage. Pour répondre à votre question: vous êtes responsable de la détection et de la correction de ces types d'erreurs. P> String code> type C Mais seulement char * code>) Vous pouvez très bien multiplier n1 code> avec n2 code>. L'opération est légale et bien définie, c'est pourquoi le compilateur ne délivrera pas une erreur. P>
GCC refuse de compiler "123" * 3 code>.
Les littéraux et les chaînes de chaîne sont présentés en mémoire en tant que chiffres (octets / m mots ou en short de haut niveau, entiers). C est un niveau de programmation de bas niveau, dans lequel toutes les choses sont approchées de la machine / de l'assembleur. Donc, la multiplication du nombre sur la chaîne littéral (si elle est une matrice, elle sera incorrecte) est correcte, car ce littéral à chaîne sera réellement (après la compilation). P>
le mot "sémantique" est ambigu et vous avez rencontré deux significations légèrement différentes dans ces contextes différents. em> p>
La première signification (votre code) est liée à la manière dont un compilateur interprète le code que vous tapez. Mais il existe différents degrés d'interprétation pour cela - la syntaxe est un seul niveau, où l'interprétation est simplement en train de décider que Ils ont également décidé que le compilateur a limité ce qu'il peut (et devrait!) Interpréter. Par exemple, il peut décider que le casting à un (parfois les gens décident qu'ils peuvent, cependant. En Python, Le deuxième sens fait référence à une portée beaucoup plus large. Si le résultat de cette opération est censé être envoyé à un périphérique de périphérique pouvant prendre des valeurs de 0x000 à 0xFFF, et vous multipliez 0x7FF par 0x010, il est clair que vous avez fait une erreur sémantique. Les concepteurs de l'appareil périphérique doivent décider si, ou comment, pour faire face à cela. En tant que programmeur, vous pouvez également décider de mettre dans certains chèques de santé mentale. Mais le compilateur n'a aucune idée de ces Strong> Sémantics Sémantics forts> Sémantics, ou sur la manière de les appliquer (filtrer l'utilisateur de l'utilisateur? Renvoie une erreur? Tronquer? Envelopper?), Ce qui dit la deuxième citation. p> N1 * N2 code> signifie que vous souhaitez effectuer une multiplication. Mais il y a aussi un niveau d'interprétation plus élevé ici - si n1 code> est un entier et n2 code> est un point flottant, quel est le résultat? Et si je le jetais, il devrait-il être arrondi, tronqué, etc.? Ce sont des questions «sémantiques» plutôt que des syntaxiques, mais une personne, quelque part, a décidé que oui, le compilateur peut répondre à ceux-ci pour la plupart des gens. P>
int code> est une troncature, pas arrondir, mais il ne peut pas décider de ce que vous voulez vraiment lorsque vous essayez de multiplier un tableau par un nombre. P>
[1] * 3 == [1,1,1] code>.) p>.)
Il y a essentiellement trois types d'erreurs. P>
1) Erreurs de syntaxe. Ce sont un code invalide que le compilateur ne comprenne pas, par ex. Votre exemple de multiplication d'une chaîne avec un entier en C. Le compilateur sera em> les détecter, car il ne peut pas les compiler. P>
2) Erreurs sémantiques. Ce sont un code valide que le compilateur comprend, mais ils ne font pas ce que vous, le programmeur, destiné. Ceux-ci peuvent utiliser la mauvaise variable, la mauvaise opération ou les opérations dans le mauvais ordre. Il n'y a aucun moyen pour le compilateur de les détecter. P>
Il y a une troisième classe, qui peut être la plus chère: p>
3) des erreurs de conception. Le code est correct et sans bug et fait exactement ce que vous avez voulu. Mais vos intentions sont fausses, par ex. Basé sur des hypothèses erronées, des modèles incorrects, ou vous avez utilisé les mauvaises formulaires, mal compris le client, ouc. p>
Vraiment, il y a trois types d'erreurs et non quatre ou cinq? Comment étonnamment comme "l'argument trilemme" de Josh McDowell. Sauce faible. Considérez: des erreurs d'exécution, telles que CTRL-C ou SIGPWR. Oui, n'attendez pas que chaque erreur d'exécution pourrait être regroupée sous «Sémantique» ou sous «Design», mais les erreurs de temps d'exécution elles-mêmes, seules la raison de la classification consiste à soutenir votre réponse trop affirmée. Il y a aussi des erreurs de documentation.
Votre exemple n'est pas une erreur sémantique - c'est une erreur de syntaxe. Même si String * int est valide (cela pourrait signifier la chaîne de répétition N fois), les types ne sont pas compatibles.
@Bevan, les termes peuvent parfois être utilisés de différentes manières et «une erreur sémantique» semblent être l'une de celles-ci. Je voudrais certainement appeler cela une erreur sémantique et je n'appellerais certainement pas une erreur de syntaxe. (Voir mon commentaire à la réponse de Michael ci-dessous.)
@THOMAS - Je vois (et concéder) votre point. J'utilisais le terme "sémantique" dans l'esprit de la citation de l'OP de Stephen Prata.
Il y a tellement de mauvaises réponses à cette question.