Bogue de compilation avec le paramètre template = void* - page 10

Nouveau commentaire
 
Ilya Malev:
Quant à "les programmeurs normaux se souviennent des priorités des opérations C++ comme d'une table de multiplication",
Personne n'a exprimé une telle thèse. J'utilise moi-même l'onglet dans la documentation
 
fxsaber:

Exactement ! Pas du tout un pro, de tels avertissements m'ont aidé 100 fois.

Je ne suis pas un pro non plus, mais j'ai été gêné par ces avertissements plus d'une fois, car parmi des dizaines (et parfois des centaines) d'avertissements superflus, les plus importants et nécessaires ont été perdus.

Et il n'est pas clair quel type d'avertissements vous pouvez avoir si vous mettez des parenthèses partout ? Et si c'était à propos d'autres affaires, il n'y a pas besoin de mélanger les choses.

 
A100:

Afin que ce concept puisse être mis en œuvre dans le compilateur. Personne n'interdit de mettre des parenthèses supplémentaires. La question porte sur les avertissements inutiles

Eh bien, dans le studio, cela est configuré par un niveau.

Et en fait, personne ne vous empêchera de supprimer ces avertissements en modifiant le code de manière à ce que le compilateur l'apprécie.

 
TheXpert:

Eh bien, dans le studio, c'est réglé par un niveau.

Et personne ne vous empêche de supprimer ces avertissements en modifiant le code de manière à ce que le compilateur l'accepte.

C'est un obstacle, car il y a alors des parenthèses supplémentaires. Mais personne n'empêche les amoureux de cette cause de mettre des parenthèses supplémentaires et, surtout, tout le monde en serait satisfait.

Je doute que ce soit configurable en studio - parce qu'il n'y a pas d'avertissements redondants sur des parenthèses prétendument oubliées (du moins par défaut) et donc il n'y a pas de sujet à configurer

 
A100:

Ça ne me dérange pas. Il suffit de laisser ces avertissements dans l'ancien MQL4.

C'est ainsi qu'ils restent pour la plupart.

void OnStart()
 {
  int a=0,b=0,c=0,d=0,e=0,f=0;
  a=b|d/e^f|a^b&d^e%f|c;
 }

Dans µl4, il jure sur tout, dans µl5 seulement sur les opérations << et >> ce qui est assez logique, car leur logique de surcharge sera le plus souvent très différente de la logique, sur la base de laquelle elles ont été priorisées. Ces avertissements m'ont souvent aidé, ou du moins ne m'ont pas trop ennuyé. Eh bien, et les opérations logiques définissant la logique des codes && et ||, qui devraient de toute façon être délimités par des parenthèses...

 
A100:

Je ne suis pas non plus un pro, mais j'ai été dérangé par ces avertissements plus d'une fois parce que parmi des dizaines (et parfois des centaines) d'avertissements superflus, j'ai perdu des avertissements vraiment importants et nécessaires.

Et il n'est pas clair quels avertissements vous pouvez avoir si vous mettez des crochets partout ? Et si c'était à propos d'autres affaires, vous n'avez pas besoin de tout mettre dans le même sac.

En général, cela se produit lorsque vous devez rapidement résoudre un problème. Par exemple, j'ai fait une erreur dans une condition où j'ai écrit && à un endroit et j'aurais dû le remplacer par ||. Je l'ai corrigé et j'ai appuyé sur F7. J'ai immédiatement reçu un avertissement. Je regarde avec précision et je vois que le résultat avec les changements actuels n'est pas celui que j'attendais. Je l'édite - c'est bon. C'est-à-dire que le compilateur m'a beaucoup aidé avec son message.


Mais si vous avez beaucoup d'avertissements, écrivez votre code plus soigneusement. Ou bien ne les éditez-vous pas par principe, en prouvant à la machine qu'elle a tort ?

 
A100:

Il vous empêche de le faire car il crée des parenthèses inutiles. Mais mettre des crochets supplémentaires pour les amoureux de ce métier ne dérange personne, et surtout, tout le monde serait d'accord avec cela

Je doute que ce soit configurable dans le studio - parce qu'il n'y a pas d'avertissement supplémentaire concernant les parenthèses prétendument oubliées (du moins par défaut), donc il n'y a pas de sujet de configuration.

Tout à fait d'accord. Puisque vous vous dites programmeur, ayez la gentillesse d'apprendre les priorités des opérations, ou au moins de vous rappeler qu'elles existent. On m'a demandé d'ajouter un robot récemment, mais on m'a demandé d'ajouter init() et start() et quand je leur ai demandé quand ils l'avaient écrit, on m'a répondu que cela faisait une semaine. Il existe donc des "codeurs", mais cela ne vaut pas la peine de leur laisser des avertissements supplémentaires.

 
Vladimir Simakov:

Je suis tout à fait d'accord. Puisque vous vous dites programmeur, soyez gentil et apprenez les priorités de fonctionnement, au moins rappelez-vous qu'elles existent. On m'a demandé de terminer l'écriture d'un robot récemment, mais il y a init() et start() et quand je leur ai demandé quand ils l'avaient écrit, ils m'ont répondu que cela faisait une semaine. Il y a donc encore des "codeurs", mais pour ces personnes, il n'est pas utile de laisser des avertissements inutiles.

La connaissance des priorités n'a rien à voir avec les avertissements. J'écris du code tranquillement et ne me considère pas comme un programmeur.

 
A100:

Je doute qu'il soit installé dans le studio.

Il est disponible dans les propriétés du projet. Nous avions une règle d'or sur l'un de nos projets : corriger tous les avertissements sur les versions de lancement, y compris les paranoïaques W4.

https://docs.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level?view=vs-2017

Il me semble que plus il y a d'avertissements, mieux c'est, à condition qu'ils soient justifiés et qu'ils puissent être désactivés.

 
fxsaber:

Si vous avez un grand nombre d'avertissements, écrivez le code plus soigneusement. Ou bien ne les corrigez-vous pas par principe, prouvant ainsi que la machine a tort ?

J'utilise principalement du code compatible C++ (et souvent même un seul fichier). Le C++ ne les a pas, et les parenthèses inutiles, comme on l'a déjà remarqué ici, rendent la compréhension difficile.

1...34567891011121314151617...20
Nouveau commentaire