Discussion :

[lianoos]

Bonjour tout le monde,

Dernièrement, j'ai appris qu'il était préférable de laisser les accolades pour un if ne contenant qu'une seule instruction. Donc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if (toto)
{
     instruction;
}

préférable que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if (toto)
     instruction;

Est-ce que quelqu'un peut me le confirmer ?
Merci beaucoup d'avance :-)

[Fiquet]

Je ne sais pas si il y a une "règle" commune, mais je pense que c'est une question de choix. Personnellement si je n'ai qu'une instruction simple je ne mets pas les accolades. Si ton code est bien indenté et clair tu verras tout de suite en cas de modification qu'il faudra rajouter les accolades. Je ne trouve pas plus clair de les rajouter pour rien.

[lianoos]

oui, mais je ne parle pas d'un point de vue de lisibilité, mais de performance...

[superspag]

ça ne change absolument rien en terme de performance

[xxiemeciel]

Salut,

Normalement non, le compilateur va generer exactement le meme code

de meme que d'utiliser

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Condition?choix1:choix2;

ne change pas les performances. Pour t'en persuader compare le code assembleur generer par le compilateur dans chacun des cas.

XXiemeciel

[swirtel]

C'est surtout demandé de l'utiliser pour éviter des bugs.

[BigNic]

de meme que d'utiliser

Code:

Condition?choix1:choix2;


ne change pas les performances. Pour t'en persuader compare le code assembleur generer par le compilateur dans chacun des cas.

ben sur solaris 2.8 en forte 6 U2 en debug sans optim

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
if(y==z)
{
    t=p;
}
else
{
   t=q;
}

n'est pas équivalent à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
t= y==z?p:q;

j'en été le premier surpris, d'ailleurs j'ai vérifé car c'est pas moi qui m'en est apperçu mais un mec de mon équipe.

en faisant des tests (assez sommaire) de perf l'opérateur ternaire (?) va 21% plus vite.

[xxiemeciel]

probablement parce que le code cond?a:b ne peut pas etre debuggé (tu ne peux pas mettre de breakpoint sur a ou sur b) donc en debug le passage sur cette ligne sera plus rapide.

ceci dit lorsque l'on parle de performance c'est le plus souvent en version release sinon ca ne rime pas a grand chose.

XXiemeciel

[reggae]

Personellement je préfère ne pas mettre les accolades...
Par contre pour la lisibilité, ne pas oublier la tabulation:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
if(test==true) //à noter que c'est la même chose que if(test)
  std::cout"exemple!":
else
//blabla

[swirtel]

Honnêtement, même si le C/C++ donne la possibilité d'outrepasser les accolades, il vaut mieux les mettre afin de délimiter le bloc de code qui sera exécuté en fonction des conditions.

C'est plus lisible, plus compréhensible.

Concernant les tabulations, Linus Torvalds préconise une tabulation de 8 caractères :p moi j'en préconise 4 :p

[reggae]

Ouais... 8)
Je vais suivre les conseils de la Free Foundation désolé pour ta technique qui n'est pas mauvaise non plus ...

[BigNic]

probablement parce que le code cond?a:b ne peut pas etre debuggé (tu ne peux pas mettre de breakpoint sur a ou sur b) donc en debug le passage sur cette ligne sera plus rapide.

ceci dit lorsque l'on parle de performance c'est le plus souvent en version release sinon ca ne rime pas a grand chose.

XXiemeciel

Dans ma boite les perfs sont un sujet assez important, pourtant on livre tout en debug. Cela peut paraitre effarant, mais on a fait des tests et pour un même serveur en solaris 2.8 compile en forte 6 U2 entre une release et une debug on a seulent 10% de gain en temps de traitement sur une reqête isolée et 30% en condition de stress. En prenant en compte que en version release on pert la possibilité d'analyser les cores quand l'appli crash, on a décidé de resté en debug.

[lianoos]

Merci pour toutes vos réponses !!

Finalement pour être sûre , j'ai suivi le conseil de xx1emeciel : j'ai comparé le code assembleur pour le if avec ou sans {} et avec opérateur ternaire.

Dans les 3 cas, le code assembleur est STRICTEMENT identique !!

Encore merci ;-)

[Jan Rendek]

Il y a des cas, néanmoins ou l'opérateur ternaire est indispensable

[xxiemeciel]

Il y a des cas, néanmoins ou l'opérateur ternaire est indispensable

Ah bon ? peux tu etre plus explicite car la je vois pas trop.

XXiemeciel

[Gandalf]

Il y a des cas, néanmoins ou l'opérateur ternaire est indispensable

Utile certainement.
indispensable, je ne pense pas.

[Jan Rendek]

Juste pour la petite bête, je veux bien développer.
L'opérateur ternaire est une expression et non pas une suite d'instructions. De ce fait, il peut
être utilisé par exemple sur la liste d'initialisation d'un constructeur, pour initialiser de manière conditionnelle un membre constant par exemple.
Un exemple monté de toute pièce, et sans aucune autre valeur que d'illustration:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
class Matrix
{
public:
  Matrix(int x, int y);
 
protected:
  const bool isSquare_;
};
 
Matrix::Matrix(int x, int y)
  : isSquare_( (x==y) ? true : false )
{
  ... 
}

Ca n'arrive pas tous les jours, c'est certain.

[BigNic]

Merci pour toutes vos réponses !!

Finalement pour être sûre , j'ai suivi le conseil de xx1emeciel : j'ai comparé le code assembleur pour le if avec ou sans {} et avec opérateur ternaire.

Dans les 3 cas, le code assembleur est STRICTEMENT identique !!

Encore merci ;-)

Le but de ma remarques n'était pas de te faire douter , juste de préciser que dans certaines conditions (mode debug, sans optim) ce n'est pas équivalent.