Partage
  • Partager sur Facebook
  • Partager sur Twitter

static_cast

    7 mai 2022 à 12:25:17

    Bonjour à tous,

    Je cherche un tableau récapitulant les règles et conventions lorsqu'il y a conversion d'un type trop grand en un type plus petit, d'un signed en unsigned, d'un int en float et réciproquement, d'un bool en autre chose et réciproquement, etc, etc...

    Ces comportements sont-ils normés ? Sont-ce bien les mêmes sur tous les compilateurs, OS, machines ?

    -
    Edité par Umbre37 7 mai 2022 à 12:27:16

    • Partager sur Facebook
    • Partager sur Twitter
      7 mai 2022 à 14:01:41

      Ce site résume tous les règles de conversion de manière exhaustive ! Jette-y un coup d'œil : https://www.learncpp.com/  (check les parties 8.1 -> 8.5)

      Si tu cherches à connaître les règles du static_cast particulièrement, rends toi directement à la partie 8.5.

      Si ma mémoire ne me trompe pas, il doit y avoir un tableau récapitulatif à la fin de l'un de ces 5 chapitres.

      -
      Edité par sones 7 mai 2022 à 14:02:52

      • Partager sur Facebook
      • Partager sur Twitter
        7 mai 2022 à 14:47:13

        Quand je regarde learncpp, il n'explique en aucun cas les règles de conversion de static_cast.

        Si on veut une explication complète, on regarde la norme (bonne chance...) ou la description de static_cast sur cppreference qui amène entre autres sur la page des conversions implicites et standards qui explique les conversions entier <-> flottant.

        • Partager sur Facebook
        • Partager sur Twitter
          7 mai 2022 à 17:33:05

          Umbre37 a écrit:

          conversion d'un type trop grand en un type plus petit, d'un signed en unsigned, d'un int en float et réciproquement, d'un bool en autre chose et réciproquement, etc, etc...

          Tu t'attends a quel comportement si la valeur n'est pas dans la plage du type qui reçoit cette valeur ? Ca sert a quoi d'apprendre des règles complexes de conversion quand il suffit de coder proprement pour s'en passer ?

          Apprendre un langage, c'est pas forcément apprendre 100% des détails syntaxiques qui servent à rien dans 99,99% des cas (sauf si tu as envie d'écrire un compilateur C++).

          • Partager sur Facebook
          • Partager sur Twitter
            8 mai 2022 à 0:30:24

            Merci pour vos réponses.

            @jo_link_noir

            Merci beaucoup, c'était la page que je cherchais, je ne l'avais pas vue sur cppreference.

            @gbdivers

            D'abord par curiosité, je me pose la question depuis longtemps. En plus, parfois on sort des limites, suivant la manière dont c'est traité ce peut être un pb ou non.

            Et même, si j'apprends que

            std::uint32_t a{std::numeric_limits<std::uint32_t>::max()};

            est équivalent à

            std::uint32_t a(-1);

            Je ne vais pas me priver pour faire des tests vites faits chez moi... (oui je sais je suis feignant).

            Bonne nuit à tous.

            -
            Edité par Umbre37 8 mai 2022 à 0:31:57

            • Partager sur Facebook
            • Partager sur Twitter
              8 mai 2022 à 1:30:21

              Faire des tests chez toi, c'est pas un problème. Mais en pratique, ca sert à quoi de retire cette équivalence ? Pourquoi retenir 2 syntaxes alors que tu peux juste en retenir qu'une seule (voire ne pas la retenir et juste savoir où la retrouver sur cppreference.com) ?

              Si ton but est d'être un expert en syntaxe, parce que tu aimes ça (coucou jo...) ou parce que tu veux écrire un compilateur, libre à toi. Ce que je dis, c'est que pour faire du dev, c'est inutile (et donc de la surcharge mentale, qui pourrait être utilisée pour d'autres choses plus utiles pour faire du dev).

              • Partager sur Facebook
              • Partager sur Twitter
                8 mai 2022 à 7:05:50

                @gbdivers

                Sans être passionné de syntaxe, j'aime bien comprendre et approfondir un peu. Mais je voulais juste dire qu'étant feignant je préfère parfois écrire  

                std::uint32_t a(-1);

                parce que c'est plus court, et que cela m'économise même un include. Je voulais juste être certain que ce ne soit pas UB.

                Quant à faire un compilateur, ce n'est pas pour demain, ni après demain.

                -
                Edité par Umbre37 8 mai 2022 à 7:12:04

                • Partager sur Facebook
                • Partager sur Twitter
                  8 mai 2022 à 10:08:02

                  Oui les unsigned sont garantis de wrapper. Sinon si c’est juste un problème que c’est trop long à taper on peut se faire des constantes du genre U32_MAX égal à  std::numeric_limits<std::uint32_t>::max()

                  Umbre37 a écrit:

                  Quant à faire un compilateur, ce n'est pas pour demain, ni après demain.

                  Peut-être pour après après demain alors ? :p (je serais pas contre un compilateur plus rapide)

                  • Partager sur Facebook
                  • Partager sur Twitter
                    8 mai 2022 à 12:47:04

                    @JadeSalina

                    Combien de personnes bossent à plein temps pour développer gcc ? Je me demande bien... peut-être des dizaines ou même des centaines ?

                    • Partager sur Facebook
                    • Partager sur Twitter
                      8 mai 2022 à 14:07:01

                      Umbre37 a écrit:

                      @JadeSalina

                      Combien de personnes bossent à plein temps pour développer gcc ? Je me demande bien... peut-être des dizaines ou même des centaines ?

                      C’est surtout pour la maintenance et parce que c’est mondialement utilisé, mais pas forcément pour la difficulté de la tâche en elle même, on ne parle pas d’envoyer un rover sur mars. Bon ok pour du C++ c’est chaud parce que le langage est excessivement compliqué mais d’autres personnes ont déjà créé des langages plus simples tous seuls, y’a même un tuto sur http://craftinginterpreters.com/ (ok c’est plutôt pour faire un interpréteur mais ça donne quand même la base)

                      • Partager sur Facebook
                      • Partager sur Twitter
                        8 mai 2022 à 17:08:07

                        @Jade Salina

                        Merci pour le lien, c'est très sympa comme site.

                        Une question me turlupine. Qui paye pour le travail du comité c++, les compilateurs clang, gcc, puisque tout cela est accessible gratuitement ? Même question pour les autres langages... À quel moment ceux qui les développent, écrivent des interpréteurs, bibliothèques, etc, gagnent de l'argent ?

                        -
                        Edité par Umbre37 8 mai 2022 à 17:08:36

                        • Partager sur Facebook
                        • Partager sur Twitter
                          8 mai 2022 à 20:02:41

                          > Une question me turlupine. Qui paye pour le travail du comité c++

                          Ceux qui envoient des gens dans le comite de normalisation. Il faut payer pour faire partie du comité et plus l'entreprise que tu représentes est grande, plus il faut payer. En dessous de je ne sais plus combien de personne, c'est gratuit et il faut au moins un AE pour la France. C++ est normalisé ISO, je ne sais plus qui s'occupe des ça en France, mais il faut forcément une entreprise pour participer.

                          Il faut savoir que les normes ISO sont payantes (et chère de mémoire), mais on a quand même accès au draft (j'imagine que c'est exceptionnel). Le draft est normalement strictement identique.

                          > Même question pour les autres langages...

                          La plupart des langages n'ont pas normalisation ISO et font donc comme ils veulent. La plupart finissent par faire une fondation ou une association (Python, Rust, C#, etc) qui s'occupe de normaliser le langage, créer le compilateur, la bibliothèque standard, recevoir les dons et faire des événements.

                          > À quel moment ceux qui les développent, écrivent des interpréteurs, bibliothèques, etc, gagnent de l'argent ?

                          Dans le cadre de C++, beaucoup de propositions viennent directement des entreprises: Google, Microsoft, Bloomberg, Facebook, etc qui font une implémentation et essaye ensuite de l'avoir dans le standard. On retrouve pas mal de conflit d’intérêt quand plusieurs groupes veulent la même chose, mais de manière différente (c'était le cas des coroutines, c'est le cas de la réflexion et plein d'autres choses). Normalement, il faut déjà au moins 1 implémentation fonctionnel sur un compilateur majeur (msvc, gcc ou clang) pour prouver la faisabilité et l'essayer. Dans le cas contraire, c'est assez difficile de vendre sa proposition. Les personnes qui le font sont donc naturellement payées par leur entreprise.

                          Mais tous le monde peut faire une proposition: toi, moi, le chat des voisins. Il y a un format à respecter dans lequel on explique le besoin et la solution. Quand ça concerne un ajout de la bibliothèque standard, on peut "facilement" coder le truc, quand c'est dans le langage, il faut contribuer à gcc ou clang.

                          Au niveau de l'acceptation d'un papier, cela se fait à l'unanimité. Si ne serait-ce qu'une personne est contre, le papier est refusé. Il y a des séances de plusieurs jours où le comité se regroupe pour parler des propositions et voter (accepter, refuser, à compléter, etc). Les auteurs des propositions peuvent aussi les présenter sur place (aucune idée si seul ceux du comité le fond ou si tout le monde peut le faire). Ça prend du temps et ton entreprise te paye. Certains font cela gratuitement, mais j'imagine que le comité peut financer le voyage dans certains cas (c'est ce qui se passe avec les associations et fondations).

                          Le cas de C++ est assez spécial puisqu'il n'y a pas d'implémentation officielle, il n'y a qu'une norme. Dans les autres langages, les fondations derrière payent des gens pour faire une implémentation officielle, alors que dans le cas de C++ plusieurs groupes le fond de manière plus ou moins indépendante (Microsoft, Intel, Nvidia, projet GNU ou Free Software Foundation (?), LLVM Developer Group, etc). Mais encore une fois, les gens sont libres de le faire gratuitement. Par exemple, je le fais en remontant des bugs qui ne sont jamais corrigés... :p.

                          -
                          Edité par jo_link_noir 8 mai 2022 à 20:06:29

                          • Partager sur Facebook
                          • Partager sur Twitter
                            8 mai 2022 à 21:52:55

                            Umbre37 a écrit:

                            Quant à faire un compilateur, ce n'est pas pour demain, ni après demain.

                            C'est en réalité pas très compliqué. De nombreux étudiants font cet exo chaque année, sur des langages simples (brainufck de ce que je vois le plus souvent).

                            Umbre37 a écrit:

                            parce que c'est plus court

                            L'argument du "plus court" est souvent invoqué par les débutants (par exemple pour les noms de classes/fonctions/variables), mais en réalité, c'est un argument osef quand on a une vue d'ensemble. A la fin de ta semaine, quel temps a tu concrètement gagné avec cette syntaxe plutôt que la version longue ?

                            Et cet argument "plus court" s'accompagne en général par une perte d'expressivité (si tu veux une valeur max, c'est plus expressive d'écrire explicitement dans le code "max" que "-1") et de maintenabilité (si tu changes le type pour un signed ou un template, le code court n'est plus valide. L'autre si). Et en termes d'apprentissage, je trouve que c'est préférable de suivre les bonnes pratiques (le code court ne passe pas la code review chez moi).

                            Umbre37 a écrit:

                            Combien de personnes bossent à plein temps pour développer gcc ? Je me demande bien... peut-être des dizaines ou même des centaines ?

                            https://gcc.gnu.org/onlinedocs/gcc/Contributors.html 

                            Mais ce n'est pas forcément un bon indicateur, tout ce monde ne travaille pas a temps pleins sur GCC. D'autres indicateurs : https://www.openhub.net/p/gcc 

                            • 8,7 millions de lignes de code
                            • près de 200 000 commits
                            • par plus de 2200 devs
                            • un équivalent de 2700 années d'effort !

                            Umbre37 a écrit:

                            Qui paye pour le travail du comité c++, les compilateurs clang, gcc, puisque tout cela est accessible gratuitement ? Même question pour les autres langages... À quel moment ceux qui les développent, écrivent des interpréteurs, bibliothèques, etc, gagnent de l'argent ?

                            En complément de la réponse de jo, il faut savoir que le "comité de normalisation du C++" (le groupe WG21 de l'ISO) ne sont ceux qui font la majorité du boulot. Leur boulot (pour simplifier) est juste de voter les propositions des normes C++. La majorité du boulot est fait par pleins de monde et coordonnée par la fondation du standard C++ (Standard C++ Foundation, c'est elle en particulier qui gère le site isoccp et organise les CppCon).

                            Et pour l'argent, les gros projets open sources ont forcément un business model derrière. Soit parce que les entreprises utilisent les outils pour ses propres projets qu'elles vendent (par exemple mon entreprise contribue au C++ et a Qt, parce qu'on vend des outils basés dessus), soit parce que des clients paient pour la maintenance de ces outils (c'est la cas des entreprises de services comme RedHat, qui vend des versions de Linux et donc a un interet a corriger les bugs) ou pour des raisons de marketing (je pense par exemple à Intel et Nvidia qui ont interet a ce que Linux supporte le mieux possible leur matériel, Microsoft qui a un intérêt à ce que Linux soit compatible avec Windows Server, a Amazon pour mettre de la pub dans Ubuntu et pour que Linux support les Amazon Web Services, etc).

                            jo_link_noir a écrit:

                            Par exemple, je le fais en remontant des bugs qui ne sont jamais corrigés... :p.

                            Avec tout ce qu'on a dit sur le financement du dev des projets open source, c'est logique en fait : l'orientation du dev est donnée en fonction des clients qui paient les devs qui font le boulot. Tous les bugs que mon entreprise a signalé à Qt ont été corrigé dans la release suivante. Parce qu'on paie les licences pro de Qt et donc les devs de la Qt Company pour qu'ils bossent sur ces bugs.

                            Mais il faut bien comprendre que pour des projets aussi gros que GCC, la simple correction d'un bug demande : 1. de comprendre l'organisation du projet. 2. réussir à compiler le projet. 3. suivre une démarche complexe pour proposer un patch. Bref, des dizaines d'heures de boulot juste pour corriger un bug mineur.

                            Un exemple concret, je participais a la traduction de Qt et Qt Creator en français quand j'étais sur developpez.com. Rien que pour un truc aussi "simple" (on faisait tout le travail d'intégration, les gens avaient juste a ouvrir un fichier et écrire les traductions, on s'occupait de tout le reste), c'était des centaines d'heures de boulot, très difficile d'obtenir de l'aide bénévole et on avait du mal à suivre les releases de Qt. Et on a arrêté parce que c'était trop de boulot.

                            • Partager sur Facebook
                            • Partager sur Twitter
                              9 mai 2022 à 9:32:56

                              @jo_link_noir

                              Merci pour cette réponse très instructive, je découvre un univers.

                              >Par exemple, je le fais en remontant des bugs qui ne sont jamais corrigés... :p.

                              Je suis étonné ! Peux-tu donner un exemple de bug (pas trop compliqué à comprendre) dans un compilateur majeur ?

                              @gbdivers

                              >C'est en réalité pas très compliqué. De nombreux étudiants font cet exo chaque année, sur des langages simples (brainufck de ce que je vois le plus souvent).

                              Cela implique probablement d'étudier de l'assembleur non ? Qui dépend en plus du processeur cible il me semble... Et encore, le travail ne serait pas fini. Pour compiler l'assembleur, il faudrait connaitre les détails techniques de mon matériel non ?

                              >L'argument du "plus court" est souvent invoqué par les débutants

                              Je me permets souvent ce genre de raccourcis en phase de test, pour du code transitoire (c'est surement pas bien, mais ne suis qu'un amateur qui fait de petites choses à la maison).

                              Merci pour le complément sur l'univers du c++, c'est intéressant de comprendre la façon dont ces organisations fonctionnent.

                              Bonne journée à tous :)

                              -
                              Edité par Umbre37 9 mai 2022 à 9:34:00

                              • Partager sur Facebook
                              • Partager sur Twitter
                                9 mai 2022 à 16:23:29

                                Umbre37 a écrit:

                                Peux-tu donner un exemple de bug (pas trop compliqué à comprendre) dans un compilateur majeur ?

                                Tu peux regarder la liste des bugs reportés : https://gcc.gnu.org/bugzilla/describecomponents.cgi?product=gcc 

                                Certains datent de plusieurs années.

                                Il faut être conscient que n'importe quel logiciel peut avoir des centaines ou milliers de bugs reportés et pas corrigé. C'est rare d'avoir 0 bug (sauf dans les domaines critiques peut être... et même là, je ne ferais pas trop d'illusion). Il y a toujours un compromis à faire entre corriger des bugs (dont certains sont complètement osef pour 99,999% des utilisateurs) et ajouter des fonctionnalités.

                                Umbre37 a écrit:

                                Cela implique probablement d'étudier de l'assembleur non ? Qui dépend en plus du processeur cible il me semble... Et encore, le travail ne serait pas fini. Pour compiler l'assembleur, il faudrait connaitre les détails techniques de mon matériel non ?

                                Vers de l'assembleur ou un langage bas niveau. Et c'est pas très compliqué l'assembleur. Le but n'est pas d'avoir un compilateur 100% fonctionnel qui va concurrencer GCC ou Clang, juste de faire l'exo.

                                Umbre37 a écrit:

                                pour du code transitoire (c'est surement pas bien, mais ne suis qu'un amateur qui fait de petites choses à la maison).

                                En phase d'apprentissage, je conseille au contraire d'être plus stricte, pour prendre dès le départ des bonnes habitudes. Mais libre a toi.

                                • Partager sur Facebook
                                • Partager sur Twitter
                                  9 mai 2022 à 18:35:42

                                  > Je suis étonné ! Peux-tu donner un exemple de bug (pas trop compliqué à comprendre) dans un compilateur majeur ?

                                  En réalité, la plupart des bugs des reportés sont simples à comprendre. Mais le pourquoi l'est en général beaucoup moins. En vraiment trivial et pour lesquels je pensais que la correction allait venir vite, il y a ces 2 bugs sur le diagnostic des messages: 94610 et 92327 (qui m'ont fait perdre beaucoup de temps). Surtout que pour le premier, le compilateur affiche le type pour certain cas. À un moment donné j'ai fini par regarder comment faire et jeté l'éponge au bout de 40 min. Vraiment pas facile de rentrer dans le code et je n'avais pas envie de passer une semaine dessus.

                                  En réalité, il y a quand même eu 1 bug corrigé sur requires que j'ai remonté fin de l'année dernière: 103105 \o/. Mais c'est "normal" d'avoir des bugs sur les nouvelles fonctionnalités et la probabilité qu'ils soient corrigés est aussi plus grande.

                                  J'ai mis des liens vers gcc, mais c'est pareil pour clang.

                                  • Partager sur Facebook
                                  • Partager sur Twitter
                                    9 mai 2022 à 19:41:50

                                    @jo_link_noir

                                    Merci pour les liens. Effectivement, l'ensemble est tellement complexe que des erreurs sont inévitables, je ne suis pas attentif à ce point aux messages d'erreur, en général ils sont suffisants pour me permettre de corriger le problème.

                                    @gbdivers

                                    Merci pour ta réponse. Je ne sais pas ce que tu appelles un langage "bas niveau", mais c'est sûr que je peux utiliser un compilateur c++ déjà fonctionnel pour compiler un langage fait maison... Ça revient juste à "traduire" ma syntaxe inventée en c++, c'est juste du traitement de chaines de caractères.

                                    • Partager sur Facebook
                                    • Partager sur Twitter
                                      9 mai 2022 à 19:57:11

                                      Le C souvent. Mais c'est suffisant pour apprendre les techniques utilisées dans un compilateur. Par exemple https://zestedesavoir.com/forums/sujet/1011/creer-un-compilateurinterpreteur-brainfuck/

                                      Et en réalité, quand tu utilises un compilateur comme clang, c'est ce qu'il se passe : le compilateur compile dans un langage intermédiaire bas niveau (LLVM-IR, qui est commun a tous les langages compilés par LLVM) et une seconde étapes compile ce langage intermédiaire en fonction de la cible. https://www.aosabook.org/en/llvm.html 

                                      Ou alors, on peut citer aussi les langages JVM, qui sont des langages "compilés" en Java (bytecode) : Scala, Kotlin, Closure.

                                      (Je laisse les autres sur la question "compilateur vs transpilateur")

                                      • Partager sur Facebook
                                      • Partager sur Twitter

                                      static_cast

                                      × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
                                      • Editeur
                                      • Markdown