Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    février 2017
    Messages
    775
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 775
    Points : 26 887
    Points
    26 887

    Par défaut GCC doit émettre des warnings pour des usages de l’opérateur xor comme 2^16, 2^32 qui prêtent à confusion

    GCC doit émettre des warnings pour des usages de l’opérateur xor comme 2^16, 2^32, 2^64 qui prêtent à confusion
    D’après des utilisateurs

    Dans bon nombre de langages de programmation dont le C et le C++, l’opérateur ^ ne fait pas référence à celui d’exponentiation, mais au OU exclusif. Il vient alors qu’après évaluation, une expression comme 2^16 donne non pas 65 536, mais 18. Des exemples d’utilisation de cet opérateur foisonnent sur la toile et certains peuvent prêter à confusion pour qui lit (ou écrit) du code.

    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    tp->tv_sec  = attributes[0] / 10^9;
    tp->tv_nsec = attributes[0] % 10^9;
     
    range->pmin[TREND_FCT] = -10^10;
    range->pmax[TREND_MEAN] = 10^10;
     
    #define IRQ_CHINT5_LEVEL        (12 ^ 7)
    #define IRQ_CHINT4_LEVEL        (11 ^ 7)
    #define IRQ_CHINT3_LEVEL        (10 ^ 7)
    #define IRQ_CHINT2_LEVEL        (9 ^ 7)
    #define IRQ_CHINT1_LEVEL        (8 ^ 7)


    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    read_bytes(&f, (char *) &(val),
                       ( (n < (2 ^ 8))  ? 1 :
                         ( (n < (2 ^ 16)) ? 2 :
                           ( (n < (2 ^ 24)) ? 3 :
                             4 ) ) ) );

    « GCC n’émet pas d’avertissement pour : short maxshort = 2^16;, int maxint = 2^32; long maxlong = 2^64; Il faut que ce soit le cas en C et en C++. Je ne vois pas de raison valable d'écrire 2^16 quand vous voulez dire 18 ou 10^9 quand vous voulez dire 3, donc c'est probablement un bogue », a lancé Jonathan Wakely sur la liste de diffusion de bugs de GCC. « Mon Dieu que de faussetés en une seule ligne de code », a réagi un internaute sur un tweet d’un des participants aux échanges sur la liste de diffusion dédiée à GCC. En fait, l’un des problèmes avec cette ligne de code est qu’étant donné que l’expression 2^32 est évaluée en considérant l’opérateur ^ comme un OU exclusif, il vient que la boucle n’aura pas le nombre d’itérations auquel le rédacteur du code s’attend.

    Nom : regher.png
Affichages : 2077
Taille : 23,0 Ko

    Si des tiers ont beaucoup plus remonté les cas d’ambiguïté qui se posent avec ce qui s’apparente de prime abord à des exponentiations de base 2, il faut dire que le problème reste le même avec les autres bases. Cet état de choses complexifie la détermination de l’angle sous lequel l’avertissement à générer sous GCC doit être orienté.

    « Je pense que les avertissements doivent porter sur les cas où les deux opérandes sont des nombres entiers. Seulement, peut-on traiter tous les entiers sur un pied d’égalité ? Est-ce que 0x11 ^ 0b0011 est faux ? En tout cas, ça ne l’est pas de façon aussi évidente que 2^8 et 2^32. Est-ce que ces erreurs n'arrivent qu'aux puissances de 2 et 10 ? Est-ce que ça vaut la peine d'avertir à propos de 3^4 ? Après d'autres recherches, je ne suis même pas sûr que 10^ soit assez commun pour m'inquiéter. Peut-être que le compilateur ne devrait générer un avertissement que pour les cas qui s’apparentent à une exponentiation de base 2. Amener GCC à générer un avertissement pour ces situations que l’on pourrait considéré comme une exponentiation dans laquelle la base et l’exposant sont égaux semble également faire sens. Cela pourrait permettre de mettre la main sur des cas comme 10^10, mais pas sur 10^10 », a ajouté Jonathan Wakely.

    Les discussions battent leur plein sur la liste de diffusion GCC. Quelque soit le consensus sur lequel elles vont déboucher, il ne faut pas perdre de vue qu’il s’agit seulement d’étendre les capacités du compilateur générer des avertissements pour des cas de figure précis. En général, les compilateurs sont dotés d’options d’activation ou de désactivation des avertissements, ce qui fait que l’utilisateur n’est pas dans l’obligation de subir un en particulier.

    Source : liste de diffusion GCC

    Et vous ?

    Qu’en pensez-vous ?
    Êtes-vous en accord avec la nécessité que GCC génère ce warning ? Si oui, quels sont d’après vous les axes les plus pertinents ?
    En tombant sur une ligne de code C comme for (int i = 0 ; i < = ( 2^32)1 ; i++) {} avez-vous au premier regard le sentiment qu’il y a une erreur qui s’est glissée ?

    Voir aussi :

    La version 9.1 du compilateur GCC est disponible et prend en charge le C++17, plusieurs autres fonctionnalités sont ajoutées

    GCC 9 sera la première version stable du compilateur à supporter le langage D, un nouveau front-end allonge la liste

    GCC 8.1 est disponible, la nouvelle version majeure du compilateur libre vient avec un support expérimental de C++2a et d'autres fonctionnalités

    GCC 8.2 est disponible. Cette mise à jour du compilateur libre corrige une centaine de bogues

    GCC : la version 7.3 du compilateur libre est disponible avec des correctifs pour la vulnérabilité Spectre pour les dispositifs x86 et powerpc
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre émérite
    Inscrit en
    juin 2009
    Messages
    910
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 910
    Points : 2 717
    Points
    2 717

    Par défaut

    Qu’en pensez-vous ?
    Êtes-vous en accord avec la nécessité que GCC génère ce warning ? Si oui, quels sont d’après vous les axes les plus pertinents ?
    J'en pense qu'il y a des erreurs plus courantes à améliorer dans gcc avant celle là que je n'ai jamais rencontré encore.
    Je pense en particulier au fait de déclarer une fonction avec un type de retour, mais sans le mot clef return. Ceci ne génère qu'un warning et pas une erreur de compilation, c'est parfaitement stupide...
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    int superFonction(int& superArgument)
    {
        superArgument++,
    }
     
    int main(int argc, char ** argv)
    {
        int i = 0;
        printf("be amazed: %d", superFonction(i));
     
        return 0;
    }
    Cela va afficher ce qu'il y avait en mémoire dans l'emplacement mémoire prévue pour la variable retournée dans la fonction. Emplacement non initialisé (sauf en débug) qui va donc générer des cas incohérents en release...

    Je ne comprend pas pourquoi cela existe encore, on a un mot clef clair quand on ne veut pas de return dans notre fonction : void. Ils devraient l'utiliser

    En tombant sur une ligne de code C comme for (int i = 0 ; i < = ( 2^32)1 ; i++) {} avez-vous au premier regard le sentiment qu’il y a une erreur qui s’est glissée ?
    Je ne suis jamais tombé sur ce cas, peut être que je ne code pas assez bas niveau pour m'amuser avec les masques de bits.
    En tout cas, comme je n'ai pas l'habitude de voir de '^', je me serai posé la question. Sans remettre en cause le code, je serai allé vérifié ça sur le net ou en local sur un projet type hello world.

  3. #3
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    957
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 957
    Points : 4 100
    Points
    4 100

    Par défaut

    Citation Envoyé par AoCannaille Voir le message
    Je pense en particulier au fait de déclarer une fonction avec un type de retour, mais sans le mot clef return. Ceci ne génère qu'un warning et pas une erreur de compilation, c'est parfaitement stupide...
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    int superFonction(int& superArgument)
    {
        superArgument++,
    }
     
    int main(int argc, char ** argv)
    {
        int i = 0;
        printf("be amazed: %d", superFonction(i));
     
        return 0;
    }
    Dans GCC 8.2.0, il y a bien un avertissement.

    Code testé sur Coliru :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    #include <stdio.h> // définit printf
     
    int superFonction(int& superArgument)
    {
        superArgument++; // un point-virgule, pas une virgule
    }
     
    int main(int argc, char ** argv)
    {
        printf("GCC version: %s\n\n", __VERSION__);
        int i = 0;
        printf("be amazed: %d", superFonction(i));
        return 0;
    }
    Commande :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    g++ main.cpp && ./a.out
    Résultat :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    main.cpp: In function 'int superFonction(int&)':
    main.cpp:6:1: warning: no return statement in function returning non-void [-Wreturn-type]
     }
     ^
    GCC version: 8.2.0
     
    be amazed: -1674877908

  4. #4
    Membre extrêmement actif
    Femme Profil pro
    None
    Inscrit en
    août 2012
    Messages
    306
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France

    Informations professionnelles :
    Activité : None

    Informations forums :
    Inscription : août 2012
    Messages : 306
    Points : 585
    Points
    585

    Par défaut

    Et l'opérateur | est utilisé pour le "ou binaire" alors qu'en ligne de commande il sert de "pipe" pour chaîner les instructions... Il y a aussi le "%" qui est utilisé pour faire un modulo au lieu de calculer un pourcentage.... Il va lancer une alerte sur tous les opérateurs qui ne correspondent pas l'usage auquel il s'attend ?
    Quand on connait le langage, ça ne prête absolument pas à confusion, sinon c'est qu'on connait pas le langage et en particulier ses opérateurs de base...

  5. #5
    Membre émérite
    Inscrit en
    juin 2009
    Messages
    910
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 910
    Points : 2 717
    Points
    2 717

    Par défaut

    Citation Envoyé par Pyramidev Voir le message
    Dans GCC 8.2.0, il y a bien un avertissement.
    Tu veux dire que c'est cohérent avec ce que je dis là :
    Citation Envoyé par AoCannaille Voir le message
    [...]Ceci ne génère qu'un warning et pas une erreur de compilation, c'est parfaitement stupide...[...]
    Quelle coïncidence

  6. #6
    Membre expert
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2017
    Messages
    725
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2017
    Messages : 725
    Points : 3 277
    Points
    3 277

    Par défaut

    Citation Envoyé par Patrick Ruiz Voir le message
    Dans bon nombre de langages de programmation dont le C et le C++, l’opérateur ^ ne fait pas référence à celui d’exponentiation, mais au OU exclusif
    ...
    peuvent prêter à confusion
    ...
    Je suis d'accord, d'autant plus dans des projets qui utilisent plusieurs langages. Mais il existe déjà une solution : https://en.cppreference.com/w/cpp/la...or_alternative. Perso, j'ai quasiment banni && || ! de mes codes au profit de and or not.

  7. #7
    Expert confirmé
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    avril 2016
    Messages
    957
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : avril 2016
    Messages : 957
    Points : 4 100
    Points
    4 100

    Par défaut

    Citation Envoyé par AoCannaille Voir le message
    Tu veux dire que c'est cohérent avec ce que je dis là
    Au temps pour moi. J'avais lu trop vite ton message.

  8. #8
    Expert éminent sénior

    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2003
    Messages
    5 676
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : juin 2003
    Messages : 5 676
    Points : 10 199
    Points
    10 199
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par AoCannaille Voir le message
    Je pense en particulier au fait de déclarer une fonction avec un type de retour, mais sans le mot clef return. Ceci ne génère qu'un warning et pas une erreur de compilation, c'est parfaitement stupide...
    c'est stupide si le C impose de ne pas compiler un tel code, autrement c'est juste être conforme avec la norme. Accessoirement, il suffit de compiler avec `-Werror` pour régler le problème.

    Précisons que Jonathan Wakely est un membre émérite de la team GCC ainsi que du comité de normalisation C++, contributeur très respecté de Stack overflow : il convient de réfléchir à deux fois avant de balayer ses propos d'un revers de main

  9. #9
    Membre habitué
    Femme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    décembre 2017
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 27
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur de jeux vidéo

    Informations forums :
    Inscription : décembre 2017
    Messages : 35
    Points : 163
    Points
    163

    Par défaut

    Quand on fait du C, on part déjà du principe qu'on est dans un langage bas niveau et que l'exponentiation n'est pas une opération élémentaire. Même pour la division et le modulo, qui sont beaucoup plus courants, je connais des gens qui militent contre leur utilisation, surtout si le diviseur est une variable ou que c'est compilé pour du ARM.

    Je pense que les gens qui font cette erreur ont raté leur vocation ou n'en ont rien à foutre. Ce n'est pas le seul langage à utiliser ^ pour le XOR, ce n'est pas le seul opérateur qui a des significations différentes sur des langages différents, il y a aussi des fonctions qui ne donnent pas le même résultat partout, et même les mot-clés ne sont pas à l'abri.

  10. #10
    Membre chevronné
    Homme Profil pro
    Développeur tout-terrain
    Inscrit en
    juin 2004
    Messages
    499
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur tout-terrain
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : juin 2004
    Messages : 499
    Points : 2 221
    Points
    2 221

    Par défaut

    Franchement même si je ne fais du C et du C++ tous les jours je sais que "^" représente un XOR et pas une élévation à la puissance...
    Les développeurs qui font ce genre de confusion n'ont pas du tout révisé !!!

    Et comme le dit SimonDecoline on peut aussi utiliser "and", "or", "not", "xor", c'est plus verbeux et plus lisible du premier coup d’œil

  11. #11
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    2 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 2 792
    Points : 8 067
    Points
    8 067

    Par défaut

    Êtes-vous en accord avec la nécessité que GCC génère ce warning ? Si oui, quels sont d’après vous les axes les plus pertinents ?
    Comme d'autres intervenants je ne trouve pas que cela soit nécessaire.
    Si on fait le parallèle avec une fonction qu'on appellerai add() et qui permettrai d'ajouter un élément dans un tableau on pourrait très bien imaginer dans un langage qu'elle l'ajoute en début et dans un autre à la fin...
    Dans tout langage il faut connaître les fonctions et leur fonctionnement.
    Le xor est une fonction.

    Précisons que Jonathan Wakely est un membre émérite de la team GCC ainsi que du comité de normalisation C++, contributeur très respecté de Stack overflow : il convient de réfléchir à deux fois avant de balayer ses propos d'un revers de main
    C'est pourtant ce que je fais, sans être un membre émérite de quoi que ce soit.
    Car ma pensée me semble logique, davantage que la sienne.
    Il voit un bug là où je ne vois qu'une personne qui ne connait pas la norme du langage (j'exagère bien sûr car je me doute qu'il la connait davantage que moi).
    Le compilateur est là pour valider qu'on applique la norme. Pas pour deviner ce que l'on voulait écrire.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  12. #12
    Membre actif
    Profil pro
    Inscrit en
    juin 2009
    Messages
    71
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 71
    Points : 209
    Points
    209

    Par défaut

    Je suis contre.

    Pour peu qu'on suive ne serait-ce qu'un tuto de base sur le net pour apprendre le langage, on apprend les opérateurs, opérateurs qui ont tendance à être les même dans beaucoup de langages puisqu'ils s'inspirent les un des autres..

    Si des personnes qui n'ont pas les bases se retrouve à faire du C/C++ et qu'ils ne testent pas le bon fonctionnement de leur code (ben oui si tu test, ça se voit que ça marche pas), c'est pas la faute de GCC.

  13. #13
    Expert éminent sénior

    Homme Profil pro
    Architecte technique
    Inscrit en
    juin 2003
    Messages
    5 676
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : juin 2003
    Messages : 5 676
    Points : 10 199
    Points
    10 199
    Billets dans le blog
    3

    Par défaut

    Mon Dieu, que d'exemples de réactions typiques de la culture du mépris Avec ce type de raisonnement on serait resté à l'assembleur (von Newmann considérait que ceux qui codaient en FORTRAN plutôt qu'en assembleur étaient des imbéciles qui n'avaient rien à faire en informatique).

    Le point soulevé est pourtant simple : quel intérêt d'écrire 2^16 quand on a besoin de la valeur 18? Il ne s'agit pas de bannir l'utilisation du XOR, il s'agit d’émettre un warning dans des cas d'utilisation louches. Où est le problème ? GCC émet déjà tout un tas de warnings du genre, comme par exemple:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    void f(int x) {
        if (x < 0)
            printf("fixing negative value\n");
            x = 0;
    }
    In function 'void f(int)':
    <source>:4:5: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
    if (x < 0)
    ^~
    <source>:6:9: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
    x = 0;
    ^
    Dire "ceux qui écrivent ça sont des gros nazes qui ne devraient pas coder en C" n'est pas une réponse satisfaisante pour ceux qui sont victimes des bugs. Que faites vous, en tant que professionnels de l'informatique, pour améliorer la qualité des outils que vous utilisez afin qu'ils soient plus sûr à l'usage ? j'explique qu'il n'y a que les gens aussi brillants que moi qui devraient les utiliser et que les autres imbéciles devraient aller voir ailleurs

    Citation Envoyé par transgohan Voir le message
    Car ma pensée me semble logique, davantage que la sienne. [...] Le compilateur est là pour valider qu'on applique la norme. Pas pour deviner ce que l'on voulait écrire.
    Et bien il est temps de réaliser que ce n'est plus ce qu'on attend d'un compilateur aujourd'hui. Il suffit de regarder les évolutions de gcc de la version 4 à la dernière pour voir la transformation en terme d'analyse et de remontée d'erreurs / warnings. Et d'autres langages comme Rust poussent plus loin la logique en fusionnant carrément l'analyseur statique avec le compilateur. Evoluer ou disparaître...

    Ma remarque sur Jonathan Wakely porte sur le fait que ça fait plus de 10 ans qu'il travaille sur l'évolution du langage : soumettre une proposition de changement, argumenter de son utilité auprès des autres membres du comité, intégrer les remarques et objections, modifier le texte de la norme en conséquences, et finalement implémenter le changement dans GCC. Précisons aussi que son boulot consiste finalement à améliorer la plateforme RedHat. Et intercepter toujours plus de bugs idiots dans GCC est une réelle réponse face aux problèmes rencontrés à cause des multiples composants tiers bugués qui y sont intégrés : c'est ce qui permet de rendre la plateforme plus safe au fil du temps.

    Donc quand ce genre de personne propose un changement dans le langage, en général, il y a une certaine idée derrière qu'il faut prendre le temps de comprendre. Sinon c'est un peu comme le mec du club de boxe du coin qui, quand il entend Mike Tyson expliquer que c'est normal d'avoir quand on monte sur le ring, répond que c'est n'importe quoi, que les vrais mecs n'ont pas peur, les véritables boxeurs comme lui ne craignent pas de monter sur le ring... Oui oui c'est ça c'est bien, tu as raison mon grand...

  14. #14
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    2 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 2 792
    Points : 8 067
    Points
    8 067

    Par défaut

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    Mon Dieu, que d'exemples de réactions typiques de la culture du mépris
    [...]
    Donc quand ce genre de personne propose un changement dans le langage, en général, il y a une certaine idée derrière qu'il faut prendre le temps de comprendre.
    Quand on parle de culture du mépris...
    On a tout à fait le droit de ne pas être d'accord avec ce monsieur, et ce peu importe sa pensée.
    Cela ne fait pas de nous des abrutis...
    A bon entendeur.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

  15. #15
    Membre du Club Avatar de oneDev
    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2019
    Messages
    31
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Transports

    Informations forums :
    Inscription : mars 2019
    Messages : 31
    Points : 53
    Points
    53

    Par défaut

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    Mon Dieu, que d'exemples de réactions typiques de la culture du mépris Avec ce type de raisonnement on serait resté à l'assembleur (von Newmann considérait que ceux qui codaient en FORTRAN plutôt qu'en assembleur étaient des imbéciles qui n'avaient rien à faire en informatique).
    Merci pour ce lien, très intéressant !

  16. #16
    Membre expérimenté Avatar de onilink_
    Profil pro
    Inscrit en
    juillet 2010
    Messages
    364
    Détails du profil
    Informations personnelles :
    Âge : 27
    Localisation : France

    Informations forums :
    Inscription : juillet 2010
    Messages : 364
    Points : 1 382
    Points
    1 382

    Par défaut

    Citation Envoyé par transgohan Voir le message
    Le compilateur est là pour valider qu'on applique la norme. Pas pour deviner ce que l'on voulait écrire.
    Parfaitement d'accord.
    Par contre, rien n’empêche d'ajouter une option de warning pour les nouveaux venus, pour ce genre de chose...
    Parce que même si le but du compilo ce n'est pas de deviner ce que l'ont veut écrire, on peut quand même dire que de bons warnings aident à corriger du code beaucoup plus vite.
    Y a qu'a voir la différence entre clang et gcc sur ce point (enfin, surtout valable il y a quelques années).
    Des tutos de pixel art: https://twitter.com/OniMille

  17. #17
    Membre expert

    Profil pro
    Inscrit en
    février 2006
    Messages
    2 082
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 2 082
    Points : 3 388
    Points
    3 388

    Par défaut

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    Le point soulevé est pourtant simple : quel intérêt d'écrire 2^16 quand on a besoin de la valeur 18? Il ne s'agit pas de bannir l'utilisation du XOR, il s'agit d’émettre un warning dans des cas d'utilisation louches. Où est le problème ? GCC émet déjà tout un tas de warnings du genre, comme par exemple:
    l'intérêt? le même que quand tu écris 1<<3 à la place de 8 ou 0xdeadbeef à la place de 3735928559, parce que dans le contexte d'écriture de ces morceaux de code, tu identifies plus facilement les erreurs avec 1<<3 ou 0xdeadbeef qu'avec 8 et 3735928559.
    un code dépend toujours minimum d'un contexte, et ça, un compilateur, comme le mentionne d'autres personnes, n'a pas la conscience des ces contextes, il n'est pas dans la tête des gens.
    donc mettre un warning comme ton exemple avec un if sans accolade et un code trop indenté, pourquoi pas, autant là mettre un warning pour dire que dans certains cas "attention cet opérateur ^ à cet endroit n'est pas la mise à la puissance" me semble contre productif.

    le problème avec la multiplication de ces warnings, c'est la multiplication des faux-positifs ou pire des lignes de commandes à rallonge pour désactiver tous les warnings, et je trouve que c'est un problème pire que celui soulevé dans ce fil.
    pour ajouter à ça, les warnings c'est spécifiques au compilo, et écrire du code correct (point de vu norme) est déjà pas simple, si en plus tu dois avoir un code sans warning et multi plateforme, bonjour la cata.

    après un autre problème, quand tu cites le palmarès de ce monsieur, ça s'appelle un argument d'autorité, et vu ce qui est sortie du comité c++ comme incohérences ces dernières années (incohérences critiquées même par d'autres sommités genre Sutter ou Stroustrup, j'en parle dans d'autres fils, je vais pas me répéter ici), il serait plutôt bon de les challenger, ceux qui vont devoir subir ce qu'ils décident, c'est nous, pas eux.

  18. #18
    Membre actif
    Profil pro
    Inscrit en
    juin 2009
    Messages
    71
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 71
    Points : 209
    Points
    209

    Par défaut

    Pour l'usage de l'argument d'autorité, je ne suis pas d'accord.

    Un argument d'autorité serait "il est le champion il a raison".

    Ici ce n'est pas ce qui a été dit, c'est que vu le rôle que cette personne a joué dans la communauté, il convient de réfléchir avant de réfuter trop vite. Il est tout a fait acceptable dans un débat de cité l'expertise d'une personne sur le sujet (et pas sur un autre sujet, sinon on tombe dans l'argument d'autorité en effet), pour inviter à réfléchir.

    Ma position c'est que si un tel code existe quelque part en production, c'est qu'il n'a sans doute pas été testé correctement. Le problème viendrait donc plutôt du manque de test assez basique.

  19. #19
    Membre du Club
    Profil pro
    Inscrit en
    février 2007
    Messages
    35
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2007
    Messages : 35
    Points : 66
    Points
    66

    Par défaut

    Citation Envoyé par stardeath Voir le message
    ou pire des lignes de commandes à rallonge pour désactiver tous les warnings
    Dans le fond je suis assez d'accord avec ce que tu dis, mais cet argument m'intrigue un peu, il n'y a plus beaucoup de devs qui tapent leur ligne de commande à la main pour compiler, si ?
    Si c'est pour dire que rajouter des arguments est source d'erreur, ok, mais la fastidiosité (pas vérifier si mot existe) du truc est difficilement recevable, non ?

  20. #20
    Membre expert

    Profil pro
    Inscrit en
    février 2006
    Messages
    2 082
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2006
    Messages : 2 082
    Points : 3 388
    Points
    3 388

    Par défaut

    Citation Envoyé par Piraaate Voir le message
    Si c'est pour dire que rajouter des arguments est source d'erreur, ok, mais la fastidiosité (pas vérifier si mot existe) du truc est difficilement recevable, non ?
    pour la boutade, ça me rappelle une histoire avec Guethenoc et des moutons (cf Kaamelott).

    j'ai pas grand chose à ajouter, c'est ça ; effectivement, en général on tape qu'une seule fois la ligne de commande, l'ajout de l'argument dans le script, etc.

    pour moi si on doit ajouter des vérifications de ce genre, ça devrait être sur une étape supplémentaire décorrélée de la compilation, genre un lint (et même si c'est gcc qui fait ce lint, il faudrait un flag pour désactiver tout ça facilement)

    gardons les erreurs/warnings si ils découlent de la complexité du langage et mettons les différences de style (l'exemple des accolades du if, la ligne suivante mal indentée, utilisation de 18 à la place 16^2) dans une étape séparée.
    comme ça 2 personnes compilant avec les mêmes flags "techniques" devraient avoir le même résultat en terme de sortie de compil, et si ces 2 personnes ont des "styles" de codage différents c'est une autre histoire qui n'affecte pas le résultat.

    ps: et j'ai du mal à me faire à l'idée que si ce cas passe, on pourra avoir à l'avenir un flag pour chaque comportement de c/c++ qui diffère d'autres langages, avec par exemple :
    tab[1] <- attention en c/c++ le premier élément d'un tableau c'est 0
    n = x | 3 <- attention en c/c++ l'opérateur | est l'opérateur "ou bit à bit"
    etc. etc.

Discussions similaires

  1. Réponses: 2
    Dernier message: 01/06/2009, 20h33
  2. Réponses: 10
    Dernier message: 14/02/2007, 17h03
  3. mettre des OVERFLOW pour un DIV
    Par Argorate dans le forum Balisage (X)HTML et validation W3C
    Réponses: 3
    Dernier message: 15/08/2006, 20h13
  4. Réponses: 2
    Dernier message: 07/06/2006, 11h44
  5. Réponses: 3
    Dernier message: 05/12/2005, 02h30

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo