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 ?
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++).
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.
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).
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 ? (je serais pas contre un compilateur plus rapide)
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)
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 ?
> 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.
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 ?
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.
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.
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.
> 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.
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.
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")
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.