Pourquoi quelqu'un l'utiliserait-il ?
if(a==1){;}
Il n'y a pas de déclaration, seulement un point-virgule, et il n'y a pas d'erreur. À quoi sert ce point-virgule ?
Pourquoi quelqu'un l'utiliserait-il ?
if(a==1){;}
Il n'y a pas de déclaration, seulement un point-virgule, et il n'y a pas d'erreur. À quoi sert ce point-virgule ?
Il s'agit d'une déclaration vide de sens. Un point-virgule seul n'effectue aucune opération.
Dans ce contexte, cela signifie que si le if
est vraie, ne faites rien.
Sans un else
ce code n'est pas d'une grande utilité. Si c'est le cas, c'est une question de style de savoir si la condition doit être inversée et ne contenir qu'un élément non vide if
portion.
Dans ce cas, il s'agit d'une condition simple, il est donc préférable de l'inverser, mais si la condition est plus compliquée, il peut être plus clair de l'écrire de cette façon. Par exemple, ceci :
if ((a==1) && (b==2) && (c==3) && (d==4)) {
;
} else {
// do something useful
}
Cela pourrait être plus clair que cela :
if (!((a==1) && (b==2) && (c==3) && (d==4))) {
// do something useful
}
Ou encore ceci :
if ((a!=1) || (b!=2) || (c!=3) || (d!=4)) {
// do something useful
}
Un meilleur exemple tiré des commentaires (merci Ben) :
if (not_found) {
;
} else {
// do something
}
Versus :
if (!not_found) {
// do something
}
Le choix de la méthode dépend en grande partie de la nature exacte de la comparaison, du nombre de termes, de l'imbrication des termes et même des noms des variables/fonctions impliquées.
Un autre exemple d'utilisation est celui d'un ensemble de if..else
pour vérifier une plage de valeurs et vous voulez documenter dans le code que rien ne doit se produire pour une plage particulière :
if (a < 0) {
process_negative(a);
} else if (a >=0 && a < 10) {
process_under_10(a);
} else if (a >=10 && a < 20) {
; // do nothing
} else if (a >=20 && a < 30) {
process_20s(a);
} else if (a >= 30) {
process_30s_and_up(a);
}
Si le vide if
a été oublié, le lecteur pourrait se demander si quelque chose aurait dû se produire à cet endroit et si le développeur l'a oublié. En incluant l'élément vide if
Il dit au lecteur "oui, j'ai tenu compte de cette situation et rien ne devrait se produire dans ce cas".
Certaines normes de codage exigent que tous les résultats possibles soient explicitement pris en compte dans le code. Ainsi, un code qui adhère à une telle norme pourrait ressembler à quelque chose comme ceci.
Je ne suis pas d'accord avec la might be cleaner than this
. Je sais que c'est une question d'opinion, mais pour moi en tout cas, il est beaucoup plus facile de lire le code sous la forme suivante if none of these, do this
au lieu de if this and this and this and this do nothing else do this
Toutes ces options sont terribles. Si la condition est si complexe, elle devrait être extraite vers une fonction bien nommée.
Il s'agit de déclaration nulle .
A partir de 6.8.3 Expression et déclarations nulles :
Une instruction null (composée uniquement d'un point-virgule) n'effectue aucune aucune opération.
Dans cet exemple particulier if(a==1){;}
, il ne fait rien d'utile (sauf peut-être un peu plus évident) car c'est la même chose que if(a==1){}
o if(a==1);
.
Il n'y a aucune raison de le faire. C'est une déclaration vide de sens. Il est possible que le développeur ait voulu faire quelque chose si a
n'était pas 1
Dans ce cas, le code serait à peu près le suivant (même si l'élément ;
peut encore être omis) :
if(a==1)
{
;
}
else
{
//useful code...
}
Mais dans ce cas, il aurait été facile de l'écrire comme suit if(a != 1)
.
Notez cependant que s'il s'agit de C++ (les balises ne sont pas encore claires), il est alors possible que l'élément operator==
de type a
a été surchargé et certains effets secondaires ont pu être observés. Cela signifierait que le code est insensé.
Dans ce cas, oui. Mais parfois, la condition inverse (pour le code utile) est plus facile à écrire/lire. L'auteur peut avoir fait cela pour améliorer la lisibilité (à son avis en tout cas).
Mais la ;
L'omble n'est pas nécessaire, n'est-ce pas ? Vous pouvez simplement laisser le if
vide et ajoutez un else
bloc
@SomethingSomething Correct, bien que certaines personnes pensent que cela rend le texte plus lisible.
C'est ce qu'on appelle une déclaration nulle. Il s'agit d'une sorte de déclaration d'expression où l'expression est manquée.
Elle est parfois utilisée dans les instructions if-else, comme vous l'avez montré, lorsqu'il est facile d'écrire la condition if plutôt que sa négation (ou que la condition if est plus claire), mais que le code doit être exécuté lorsque la condition if est évaluée à faux.
Par exemple
if ( some_condition )
{
; // do nothing
}
else
{
// here there is some code
}
En général, l'instruction null est utilisée uniquement pour montrer que, par exemple, le corps d'une fonction, d'un constructeur de classe ou d'une boucle for est vide. Par exemple
struct A
{
A( int x ) : x( x )
{
;
}
//...
};
Ou
char * copy_string( char *dsn, const char *src )
{
char *p = dsn;
while ( ( *dsn++ = *src++ ) ) ;
^^^
return p;
}
Ici, l'instruction null est nécessaire pour la boucle while. Vous pouvez également le réécrire comme suit
while ( ( *dsn++ = *src++ ) ) {}
L'instruction null est parfois nécessaire, en particulier dans les rares cas où l'instruction goto est utilisée. Par exemple, en C, les déclarations ne sont pas des énoncés. Si vous voulez passer le contrôle du programme à un point situé avant une déclaration, vous pouvez placer une étiquette avant la déclaration. Cependant, en C, une étiquette ne peut être placée qu'avant une déclaration. Dans ce cas, vous pouvez placer une instruction null avec une étiquette avant la déclaration. Par exemple
Repeat:;
^^^
int a[n];
//....
n++;
goto Repeat;
Faites attention à la mention "null" après l'étiquette. Si vous la supprimez, le compilateur C émettra une erreur.
Cette astuce est également utilisée pour faire passer le contrôle du programme à la fin d'une instruction composée. Par exemple
{
// some code
goto Done;
//...
Done:;
}
Bien que vous ne deviez pas utiliser l'instruction goto, vous devez connaître ces cas :)
Comme beaucoup l'ont dit, cela ne sert à rien.
Pourquoi est-il là ? Voici une possibilité
J'en ai assez que les mauvais codeurs de mon équipe ne vérifient pas les valeurs de retour des fonctions.
Ainsi, puisque nous développons sous Linux avec le compilateur GCC, j'ajoute __attribute__((warn_unused_result))
à la déclaration de toutes mes fonctions typées. Voir aussi cette question pour l'équivalent d'un MS VC.
Si l'utilisateur ne vérifie pas la valeur de retour, le compilateur génère un avertissement.
Les cow-boys, bien sûr, ont joué avec le système et le code if (foo() != SUCCESS) ;
ce qui satisfait le compilateur (bien qu'il ne satisfasse pas à la norme moi :-).
L'OP a posé une question sur l'utilité du point-virgule, et non sur celle de la virgule. if
clause.
Pourquoi s'en prendre à moi ? :-) Sérieusement, toutes les autres réponses utilisent if
. Regardez le site de nwellnhof qui se trouve juste en dessous de celui-ci ... often used in long if/else chains
et autres. Vlad est en dessous de ` utilisé dans des instructions if-else` , etc, etc, etc Je comprends que l'on puisse utiliser un sémique comme une instruction indépendante. i++; /*here it comes*/ ; /* what was that for? */ j++;
mais le PO ne l'a pas formulé de cette façon, j'ai donc cherché à l'expliquer dans le contexte de la question (comme tous les autres) tout en enseignant un pragma très peu utilisé.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
33 votes
Il ne sert à rien. Ce n'est qu'une déclaration vide de sens.
5 votes
S'agit-il de C ou de C++ ?
2 votes
Je n'ai jamais essayé, mais une telle déclaration vide ne serait-elle pas utile à des fins de débogage ? comme l'ajout de points d'arrêt ?
2 votes
Il existe certains cas d'utilisation, par exemple
while (x.compare_exchange_weak(xexp,xexp+2.0)) ;
0 votes
Dans ce cas, il s'agit soit d'un comportement non signé, soit d'un "no-op", en fonction de ce que l'on appelle un "no-op".
a
est. Voir ma réponse (qui souffre malheureusement d'un manque total d'attention).26 votes
@Bathsheba comportement non signé ? C'est ce que font les fans lorsqu'ils font la queue pour obtenir un autographe ?
0 votes
Associé à un else, il peut rendre les conditions plus faciles à lire if(has_car && has_licence);else{...} plutôt que if(!has_car || !has_licence){...}.
1 votes
@Quentin Je crois que c'était censé être un "comportement non défini".
1 votes
@MalcolmMcLean
if(!(hasCar && hasLicence))
me semble toujours plus clair...1 votes
J'ai vu ce genre de choses apparaître lorsqu'il y avait une norme de codage inflexible de "chaque if doit avoir un else". (Dans les cas où l'on n'a tout simplement pas besoin d'un "if", il est préférable d'utiliser un "else".
else
, alors soit leif
oelse
doit être un no-op .2 votes
Non, parce qu'il ne génère pas de code assembleur, donc il n'y a pas d'instruction que l'on puisse interrompre (sous Windows,
asm(int 3);
serait une bonne idée - vous n'avez pas besoin de définir un point d'arrêt, mais le débogueur s'arrête toujours à cet endroit - et il ne fait rien lorsqu'il est exécuté en dehors d'un débogueur.0 votes
@Mawg Ne serait-ce pas
asm("int 3");
? Ou peut-êtreasm((int)3);
si vous essayez de lui transmettre le numéro (mais il s'agirait déjà d'unint
afaik...).2 votes
Non, le
int
Le déclenchement d'une procédure d'appel d'offres est l'un des moyens utilisés par l'Union européenne.interrupt
- voir fr.wikipedia.org/wiki/INT_%28x86_instruction%29#INT_32 votes
Il est préférable pour la portabilité d'utiliser un élément intrinsèque plutôt que d'utiliser l'assemblage en ligne pour les points d'arrêt.
__debugbreak()
sur MSVC. @mawg0 votes
Très bien - si vous utilisez MSVC :-) +1 sinon, il suffit de l'intégrer. Quoi qu'il en soit, c'est un bon truc, qui ne reçoit pas assez de publicité. Je l'ajoute aux branches d'erreur et je n'ai pas besoin de l'enlever pour la publication. Je peux le laisser là quand je débogue, effacer tous les points d'arrêt, en mettre de nouveaux, et toujours m'arrêter sur n'importe quelle branche d'erreur marquée comme telle.
3 votes
Il pourrait éventuellement supprimer l'avertissement du compilateur concernant la variable
a
n'est pas utilisé. Mais il est plus probable qu'il s'agisse de ce que Stephen Jay Gould appelait un tympan : un morceau de code (il parlait de notre code génétique) qui avait une utilité dans son contexte d'origine, mais qui n'est plus qu'un résidu après que les autres morceaux ont été retirés.0 votes
Partiellement lié : stackoverflow.com/q/154136/5399734
1 votes
Je lance le dernier vote de clôture, puisque 4 personnes ont déjà convenu qu'il s'agissait probablement d'un doublon. Je me suis dit que c'était aussi bien de le protéger. Quoi qu'il en soit, il fallait faire quelque chose. plus qu'il n'en faut réponses.
0 votes
@NadeemKhan L'une des réponses fournies ci-dessous a-t-elle répondu à votre question ? Si oui, vous devriez accepter l'un d'entre eux .