en C ++ on peut écrire n'importe laquelle des affirmations suivantes: ou quelque chose comme Ce dernier peut être utilisé pour supprimer Un avertissement de compilateur "Une variable est initialisée mais non référencée" (C4189 en VC ++) si une macro développée dans une chaîne vide dans une configuration est ultérieure utilisée ultérieurement avec la variable . Comme ceci: Quel est le sens de ces déclarations? Comment peuvent-ils être utilisés à l'exception de la suppression de l'avertissement du compilateur?
9 Réponses :
Bien que légal, je pense que ces déclarations sont déroutantes et devraient être évitées, même pour supprimer des avertissements. Pour moi, il est plus raisonnable de supprimer l'avertissement en utilisant quelque chose comme ceci:
Ce sont des expressions qui seront évaluées, en supposant que le compilateur ne les optimiste pas. En ce qui concerne "signification", je ne suis pas sûr de ce que vous voulez "dire" par ça!
Ils n'ont pas d'utilisation pratique au-delà de la suppression d'avertissement du compilateur et, en général, le compilateur éliminera toute déclaration de valeur constante qui n'a aucun effet secondaire.
Ce type de déclarations est une expansion logique de la façon dont les autres pièces de la langue fonctionnent. Envisagez d'avoir une fonction qui renvoie une valeur, par exemple Maintenant, alors que cela ne ressemble pas exactement à ce que Un autre exemple du même problème est que puisque vous pouvez faire Être capable d'écrire de telles valeurs car des déclarations sont simplement un moyen logique de construire la langue, mais pour les cas que vous présentez, cela pourrait même être une bonne idée de donner un avertissement de compilateur pour cela.
sauf si vous l'utilisez pour supprimer les avertissements du compilateur;) int foo () , que aussi a des effets secondaires. Parfois, vous voulez seulement que ces effets secondaires se produisent, alors vous écrivez foo (); comme une déclaration.
10; , l'appel de la fonction évaluera à un int t plus ou ultérieur, et rien n'arrive à cela, tout comme avec 10; < / code>.
a = b = 10; , cela signifie b = 10 doit évaluer à 10 < / code>, vous ne pouvez donc pas faire d'affectation sans générer une valeur qui doit être supprimée.
Bien que habituellement, vous voudrez écrire (vide) FOO (); Pour montrer que vous êtes explicitement / intentionnellement jeté la valeur de retour de FOO ().
@Dan: C'est une théorie, oui. Je peux compter le nombre de fois que j'ai vu "(vide) printf (...." sur les doigts d'une main. (Je compte sur mes doigts en binaire, donc ce n'est pas aussi mauvais que ça sonne .) Vous avez peut-être travaillé sur des projets qui font cela; je n'ai pas.
Une telle déclaration ne fait rien et sera probablement optimisée par tout compilateur décent.
Il peut être utile de se débarrasser de la variable AVERTISSEMENT , mais avec certains compilateurs, vous pouvez obtenir une déclaration n'a aucun effet avertissement.
Auquel cas vous supprimez avec le résultat "(vide);" au lieu.
in c et c ++, une déclaration qui est juste une expression est évaluée.
Le fait que l'expression pourrait être inutile est inoffensif et avec l'optimiseur allumé ne peut entraîner aucun code généré du tout. Cependant, comme vous l'avez observé, cela compte généralement comme utiliser d'une variable.
Notez que les déclarations contenant uniquement une expression sont assez courantes. Un appel de fonction simple est un, par exemple. Dans En outre, une affectation variable printf ("bonjour, monde. \ N"); , la valeur de retour de printf () est ignorée mais la fonction est toujours appelée et son effet prévu (sortie de texte ) se passe-t-il.
x = 3; est également une instruction composée d'une expression simple, car l'attribution est un opérateur et renvoie une valeur en plus de son effet secondaire de la modification de la lvalue.
Ces déclarations (appelées déclarations d'expression dans la grammaire C ++) sont valides car elles sont des expressions.
Les expressions sont toutes des constructions qui calculent une sorte de valeur, telle que
Je pense que pour garder la grammaire simple, ils ont décidé de ne pas différencier entre ces expressions qui ont un effet secondaire (telle que l'appel de la fonction ou l'affectation) et ceux qui ne le font pas.
Dans certains environnements intégrés, l'accès à un registre en lecture seule aura des effets secondaires, par ex. Effacer-le.
écrire int temp = iv; Pour effacer cela provoque un avertissement, car la température n'est pas utilisée, auquel cas j'écris IV;
Je suis d'accord avec la réponse de Magnus. Il y a une chose qui me puzzle: pourquoi utilisez-vous ce non-sens pour vous débarrasser des avertissements du compilateur? À mon humble avis, il est bien pire de ne pas avoir un avertissement dans une telle situation. Le résultat code> n'est toujours pas utilisé - vous venez de "balayer la saleté sous le tapis". Cette approche "solitaire variable" a l'air de manquer quelque chose ( ai-je supprimé accidentellement quelque chose? Em>). Pourquoi n'utilisez-vous pas P> (void)obtainResult();
Je pourrais avoir besoin de pouvoir avoir la valeur de cette variable dans le débogueur. Il suffit de l'excluant et ne quitte que l'appel de la fonction n'est pas une option dans ce cas.