Ma machine principale ayant rendu son dernier souffle, je me suis vu dans l'obligation de la remplacer (barebone ryzen 5, 1 To ssd m.2, 8 go ram, win 10 pro). Heureusement, j'avais des backups de pratiquement tout.
Et donc je souhaite installer un compilateur C (64 bits). Mais lequel ? Bien que je n'ai pas besoin d'ide, je prendrais bien celle de ms rien que pour son debugger qui a l'air vraiment bien (ça me rapelle TCC v2.0 qui à l'époque était une révoluton sur pc) mais je n'aime pas le côté "intrusif" de ms. Je ne connais pas clang, et il y a plusieurs versions de gcc.
Merci de me donner votre avis (et éventuellement des liens).
Edgar.
PS 1: jusqu'à ce jour, j'ai toujours compilé en ligne de commande (avec un make si nécesaire)
PS 2: pourrions-nous éviter les habituelles "anicroches" entre pro et anti ms ? Merci
- Edité par edgarjacobs 23 février 2023 à 2:37:08
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Salut Edgar, Tu es plus expérimenté que moi. J'ai presque honte de te suggérer quelque chose . D'autant plus que mon système est assez tordu (Windows + Cygwin) Je l'ai téléchargé sur Cygwin et j'ai joué avec les path Moi non plus, je ne travaille pas avec un IDE. Je suis directement sur cmd. Je n'ai pas de problème avec gdb
gcc (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders) 10.2.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Le Tout est souvent plus grand que la somme de ses parties.
Sur https://www.winlibs.com il y a des compilateurs Mingw à jour. Pour l' instant j' utilise Mingw 12.2.0 en version UCRT (il y a sur la page du lien que j'ai donné une explication entre les versions MSVCRT et UCRT des compilateurs Mingw).
Je dirais celui que le système te donne en « standard »
Sur les BSD c'est clang
Sur Linux c'est plutôt gcc ou clang (mais je recommande vivement clang pour tous les outils annexes clang-tidy, clang-format et sanitizers et parce que c'est pas GPLv3)
Sur Windows tu as l'embarras du choix : MSYS2avec gcc ou clang ou Visual Studio.
MSYS2 : te permet d'avoir un gestionnaire de paquet pour installer convenablement des bibliothèque et d'utiliser des outils unix (make, pkg-config, etc). Plutôt confortable si tu es à l'aise avec les outils Unix.
Visual Studio : complet avec un IDE mais ne supporte pas tous les standard du C.
Les compilateurs alternatifs comme cproc, tcc sont intéressant mais ne sont pas 100% fonctionnel malheureusement.
Edit : j'ai vu ms, puis win 10 pro dans le message par après. Je garde les autres réponses pour ceux qui tombent sur le sujet.
- Edité par markand 23 février 2023 à 9:31:52
git is great because Linus did it, mercurial is better because he didn't.
En effet, comme le dit Michel : «Pourquoi choisir ?», du moins pourquoi choisir avant ? Tu peux en installer plusieurs, les tester, etc.
Mais il ne faut pas oublier que C n'est pas uniquement réduit à un compilateur comme tu le remarque toi-même. Il y a les front-end, GCC et Clang sont les deux acteurs majeurs sur les plateformes modernes, qui, en plus d'avoir une vision différente de l'architecture d'une chaîne de compilation, utilisent différents outils. Par exemple chaque front-end utilise un linker différent (ld en général pour gcc, llld pour clang), proposent tous deux de bons debugers (gdb, lldb) tous deux utilisables par d'autres front-end graphiques pour une session de débogage plus aisée, etc. Mais il ne faut pas oublier non plus les différentes libc qui sont disponibles. Il y a la classique gnulibc mais musl est une alternative intéressante (parmi d'autres). Ne connaissant que trop peu windows, je ne pourrais pas t'aider plus que de te donner des pistes pour trouver des informations pour décider ; pour autant qu'une décision doive être prise
J'en profite également pour parler un peu de Zig. Zig est un nouveau langage de programmation qu'il est intéressant de découvrir. L'originalité est que le compilateur zig est également un compilateur C (llvm en back-end je crois). Tu peux également bénéficier de son build manager. Le projet est sympa et original par son approche, il est cependant encore en béta.
Un point important, choisir un compilateur qui se conforme à des normes raisonnablement récentes. On est en 2023, C17/18 ça ne parait pas farfelu.
Je dis ça parce que pendant longtemps, Microsoft ne voulait pas décoller de C89 (*). Or, malgré quelques égarements, les évolutions du standard vont plutôt vers une clarification du langage et une standardisation des bibliothèques (**).
(*) probablement parce que leurs produits, et le code qu'ils vendaient, reposait sur des trucs pas trop cleans.
Un point important, choisir un compilateur qui se conforme à des normes raisonnablement récentes. On est en 2023, C17/18 ça ne parait pas farfelu.
Je dis ça parce que pendant longtemps, Microsoft ne voulait pas décoller de C89 (*). Or, malgré quelques égarements, les évolutions du standard vont plutôt vers une clarification du langage et une standardisation des bibliothèques (**)
Hélas ce n'est pas que limité à Microsoft. Apple aussi, bien qu'ils utilisent LLVM et clang, leur bibliothèque C maison manque de beaucoup de chose du C11 (bye bye uchar.h, threads.h etc) et supérieur. Ils n'implémentent pas non plus certaines normes plus récente de POSIX (bye bye timer_create sur macOS).
C'est triste de voir que le C n'a pas autant l'attention qu'il mérite sur la totalité des plateformes.
- Edité par markand 23 février 2023 à 11:24:56
git is great because Linus did it, mercurial is better because he didn't.
> C'est triste de voir que le C n'a pas autant l'attention qu'il mérite sur la totalité des plateformes.
Comment dire ?
On va supposer que les gens qui développent des compilateurs (et la norme) ont des comportements à peu près rationnels, en ce qui concerne leurs intérêts.
Donc si ils ne bossent pas trop dessus, c'est que pour eux ça n'en vaut pas vraiment la peine (retour sur investissement...). Et que ce raisonnement n'implique pas que le langage C soit considéré comme absolument parfait dans l'état où il est (litote).
> C'est triste de voir que le C n'a pas autant l'attention qu'il mérite sur la totalité des plateformes.
Comment dire ?
On va supposer que les gens qui développent des compilateurs (et la norme) ont des comportements à peu près rationnels, en ce qui concerne leurs intérêts.
Donc si ils ne bossent pas trop dessus, c'est que pour eux ça n'en vaut pas vraiment la peine (retour sur investissement...). Et que ce raisonnement n'implique pas que le langage C soit considéré comme absolument parfait dans l'état où il est (litote).
C'est sûr, d'autant plus que les plateformes comme macOS et Windows viennent avec leur propres alternatives la plupart du temps. Là où c'est dommage c'est qu'Apple par exemple, prend LLVM comme infrastructure de compilateur donc ils ont déjà beaucoup moins d'effort à faire pour être conforme. La seule chose qu'il leur reste c'est d'étendre la libc pour qu'elle soit compatible avec la norme et POSIX.
Peut-être que la LLVM libc corrigera ce problème un jour.
Pour MS c'est plus compliqué car eux décident d'implémenter leur propre compilateur (cl) bien qu'il soit possible d'utiliser clang (jamais testé pour ma part via Visual Studio).
- Edité par markand 23 février 2023 à 13:15:53
git is great because Linus did it, mercurial is better because he didn't.
Pour ma part, j'ai toujours travaillé sous IDE, visual ou Qt (mingw). Visual à mes préférences même s'il ne respecte pas tous les standards. Développement rapide, facilité à dégager les alertes de compilation, debuggage facile avec les espions. Prends simplement un IDE ou compilo qui te permets de coder rapidement, si tu prends un IDE, prends celui qui te permets de débugger facilement et où les réglages sont faciles.
Merci à tous pour vos réponses. L'idée d'installer et tester différents compilateur ne m'était pas venue à l'esprit, quitte à désinstaller ceux que ne me plaisent pas.
@michelbillaud: oui, il est évident que je prendrai la dernière mouture du compilateur, c'est mon clavier qui a mal écrit: pas version, mais build
- Edité par edgarjacobs 24 février 2023 à 1:12:23
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
J'ai beaucoup de compilateurs installés dont plusieurs version de gcc. Je ne les utilises pas vraiment tous.
Pour passer facilement de l'un a l'autre j'utilise le "vilain" IDE qui est Code::Blocks, pourquoi ? car il est très facile d'y configurer un compilateur. Et sans rien mettre dans le PATH (ce qui facilite la cohabitation). Bon, j'utilise aussi Visual Studio.
De toute façon, si tu es sous Windows 10, tu es déjà chez Microsoft. Donc mettre Visual C++ (qui je pense est le meilleur choix sous Windows) ne sera pas plus (ni moins) intrusif du fait que tu es déjà chez Microsoft.
(Après, comme il a été dit, au pire installe en plusieurs pour tester)
Et puis il faut arrêter d'être parano... Si Microsoft collecte je ne sais quoi ? Quid de Facebook, Alexa, Google, Apple, c'est pas moins intrusif... Et puis notre petite vie ne les intéresse pas tellement.... Juste faire des statistiques pour savoir quelle éventuelle pub nous envoyer.
Intrusif n'est peut-être pas le bon terme. Je pense au fait que le compilateur génère une erreur sur scanf(), car ms voudrait bien que l'on utilise son scanf_s(), qui pour moi n'est pas plus sécurisé qu'un scanf(): il suffit de donner une mauvaise longueur pour une chaine de caractères, et scanf_s() ne fera pas mieux que scanf()
- Edité par edgarjacobs 28 février 2023 à 23:43:35
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Intrusif n'est peut-être pas le bon terme. Je pense au fait que le compilateur génère une erreur sur scanf(), car ms voudrait bien que l'on utilise son scanf_s(), qui pour moi n'est pas plus sécurisé qu'un scanf(): il suffit de donner une mauvaise longueur pour une chaine de caractères, et scanf_s() ne fera pas mieux que scanf()
Euh non, puisque justement scanf_s attend 2 paramètres pour les chaines, il attend l'adresse de la chaine puis la taille. Il a justement été fait pour éviter les overflow. Evidemment il faut lui donner la bonne taille ! C'est la responsabilité du programmeur. (et non plus de l'utilisateur qui pouvait rentrer n'importe quoi).
Alors j'entends bien que ça fait chier que scanf soit deprecated (même si avec un #define on le remet en place), et ça fait chier que tout le monde ne se soit pas mis d'accord pour valider scanf_s (ou un autre) dans la norme, que Microsoft fasse cavalier seul sur le coup.
Mais toutes les fonctions en _s qui ont été faites permettent justement de sécuriser beaucoup de choses.
[...] Alors j'entends bien que ça fait chier que scanf soit deprecated (même si avec un #define on le remet en place), et ça fait chier que tout le monde ne se soit pas mis d'accord pour valider scanf_s (ou un autre) dans la norme, que Microsoft fasse cavalier seul sur le coup.
Mais toutes les fonctions en _s qui ont été faites permettent justement de sécuriser beaucoup de choses.
Attention, scanf n'est pas mis deprecated (au sens au gets par exemple l'a été), c'est une fonction que la libc doit proposer par défaut car l'annexe K de la norme n'est pas obligatoirement implémentable.
Moui, quand tu sais que la calculette Windows a déjà de la télémétrie je préfère pas imaginer pas un monstre tel qu'est VS.
Je pense qu'il y a de quoi être légitimement parano.
Alors je n'avais jamais entendu parler de ça. Si je comprends bien c'était une faille de sécurité sur la calculatrice que Microcoft a corrigé ?
Il il y a des failles. C'est pour ça qu'il y a des mises à jour aussi... Il y a aussi des failles dans tous les OS, dans les navigateurs web, et c'est pour ça que c'est régulièrement corrigé.
Maintenant, je voudrais dire encore quelque chose sur le sujet. Imaginons une volonté explicite de Microsoft de laisser des failles ouvertes pour voler des données des gens...
De grands groupes industriels qui pèsent des milliards (Dassault, Siemens, PTC, Autodesk) pour ne citer que les plus gros sortent leurs logiciels de conception (Catia, Unigraphics, Creo, Inventor) principalement sous Windows. Avec ceux ci sont développés des trucs extrêmement confidentiels comme des prototypes de nouvelles choses qui coûtent des milliards, parfois des trucs militaires, spatiaux, etc....
Je te laisse juste imaginer si un jour on dit à ces gens la que leurs données confidentielles se barrent chez Microsoft et que c'est volontaire. Juste imaginer....
Alors oui il y a des bugs, des failles à corriger comme partout, des couacs, des soucis à gauche à droite. Il y a même eu des Windows vraiment pas stables (mais c'était pas tellement un soucis de sécurité mais de stabilité)
Par contre, tout ce qui est complot sur le sujet, que Microsoft ferait des trucs en loose, ça fait 20 ans que j'entends les mêmes ritournelles.
Euh non, puisque justement scanf_s attend 2 paramètres pour les chaines, il attend l'adresse de la chaine puis la taille. Il a justement été fait pour éviter les overflow. Evidemment il faut lui donner la bonne taille ! C'est la responsabilité du programmeur. (et non plus de l'utilisateur qui pouvait rentrer n'importe quoi). Alors j'entends bien que ça fait chier que scanf soit deprecated (même si avec un #define on le remet en place), et ça fait chier que tout le monde ne se soit pas mis d'accord pour valider scanf_s (ou un autre) dans la norme, que Microsoft fasse cavalier seul sur le coup.
Comme l'a dit White Crow, scanf n'est pas "deprecated" par la norme du C. C'est Microsoft qui décrète, pour son compilateur, que scanf est "deprecated" car non "sécurisé".
L'annexe K a été introduite pour faire plaisir à Microsoft, sous une forme optionnelle. Citez moi un compilateur autre que le leur qui implémente scanf_s dans sa libc.
C'est la responsabilité du programmeur dans les deux cas, et non de l'utilisateur, de donner la bonne taille.
char st[50] = { '\0' };
int c;
printf("Type up to 49 characters\n");
if (scanf("%49[^\n]", st) == 1) {
printf("I gathered: [%s]\n", st);
while ((c = getchar()) != '\n' && c != EOF)
/* discard rest of stdin buffer */ ;
/* now do something with st */
}
Il faut juste comprendre comment utiliser scanf(), qui n'est pas la plus simple des fonctions de la bibliothèque du C.
La présence ou absence de télémétrie dans les logiciels de Microsoft n'est pas un bogue, ni vraiment une faille. C'est le fonctionnement du logiciel décidé par l'éditeur, qui décide que telle application est susceptible d'envoyer des informations à Microsoft sur l'usage du logiciel qu'ils mettent à disposition.
Il existe en effet un moyen de mettre la taille directement dans un scanf normal.
Cependant, d'autres fonctions printf_s, strcat_s, strcmp_s sont intéressantes, car elles, ne permettent pas au programmeur d'empêcher de cracher si la chaine vient de l'utilisateur. scanf_s permettra d'être conforme à cette logique.
Je vous rejoins sur le fait que Microsoft n'aurait pas du prendre cette décision seul. Mais il corrige (à la demande probablement de beaucoup de client dont la sécurité est importante) des fonctions standard sécurisées. Il est dommage que les autres n'aient pas emboîté le pas.
Que fait la faille qui n'en est pas une sur la calculette Windows du coup ? Quelles informations sont envoyées à Microsoft depuis la calculatrice ?
Un programmeur C ne devait pas se retrouver dans une situation où il traite une chaîne sans avoir au préalable fait en sorte que la zone mémoire où elle réside a été correctement dimensionnée.
il corrige (à la demande probablement de beaucoup de client dont la sécurité est importante) des fonctions standard sécurisées
Ils ne corrigent rien du tout, puisqu'il n'y a rien à corriger dans les fonctions standard de la libc.
Ils ont le droit de décider de tenter d'assainir le code qu'ils produisent en tant qu'éditeur en utilisant ces fonctions, pour limiter les erreurs de programmation par leurs équipes, si c'est leur façon interne de traiter le problème pour les programmes C que Microsoft produit en tant qu'éditeur.
Ce qui est discutable, c'est de décider d'imposer leur façon de faire et vision au monde entier, en mettant à disposition un compilateur qui, dans son fonctionnement par défaut, ne compile pas du code standard C et impose l'usage de fonctions qu'ils sont les seuls à avoir inclus dans leur compilateur.
Pour la calculette, je n'en avais pas connaissance (c'est markand qui l'a signalé). Il semble que ce soit quand Microsoft a décidé de mettre le code de ce programme en OpenSource (licence MIT) que l'existence de fonctionnalités adressant des informations à Microsoft sur l'usage du programme a été révélée au public (activées par défaut sur les builds destinés à leur store, si je comprends bien).
× 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.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Le Tout est souvent plus grand que la somme de ses parties.
Mon site web de jeux SDL2 entre autres : https://www.ant01.fr
git is great because Linus did it, mercurial is better because he didn't.
git is great because Linus did it, mercurial is better because he didn't.
git is great because Linus did it, mercurial is better because he didn't.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
git is great because Linus did it, mercurial is better because he didn't.
On écrit "j'ai tort", pas "tord" qui est le verbe "tordre" à la 3ème personne de l'indicatif présent
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html