compilateur respectant la norme ansi c

Je m’en doutais.

Salut,

Hmm… Ce serait dommage d’étouffer dans l’oeuf ce sujet aussi rapidement.

Pour ma part, je vois au moins deux raisons supplémentaires :

• la participation à un projet existant ;
• la disponibilité d’une pléthore de bibliothèques éprouvées (si les autres langages ont des bindings vers du code C, c’est pas pour faire joli) ainsi que l’emploie aisé et direct des bibliothèques fournies pas le système d’exploitation hôte (oui, le C++ peut aussi le faire, mais pas forcément aussi simplement).

En effet (à quelques exceptions près, comme tu l’as précisé), mais au prix d’une complexité grandissante au fur et à mesure des ajouts et normalisations.

Je pense qu’il y a un point très important qu’il ne faut pas oublier au sujet des normes C99 et C11 : globalement, elles n’apportent rien d’essentiel (comprendre : écrire un code en C89 aujourd’hui n’amène aucune difficulté particulière qui serait surmontée exclusivement en s’appuyant sur une nouvelle norme, à l’exception peut-être de l’absence d’un type entier « 64 bits » explicite). Il y a indéniabelement des ajouts intéressants au sein de ces dernières, mais dire que la norme C89 n’a plus d’intérêt ou qu’elle est obsolète, c’est alors dire la même chose du C (ce qui peut se soutenir, mais ce n’est pas la question), la norme C89 constituant le fondement des deux autres.

Juste une note : aucun système d’exploitation n’est conforme à l’ANSI C. Ils ne sont déjà pas conformes à l’ISO C, d’une part parce qu’ils utilisent pléthore d’extension et d’autre part parce qu’ils font des trucs explicitement mentionnés comme étant des undefined behaviors dans la norme.

Je pense qu’il y a un point très important qu’il ne faut pas oublier au sujet des normes C99 et C11 : globalement, elles n’apportent rien d’essentiel (comprendre : écrire un code en C89 aujourd’hui n’amène aucune difficulté particulière qui serait surmontée exclusivement en s’appuyant sur une nouvelle norme, à l’exception peut-être de l’absence d’un type entier « 64 bits » explicite). Il y a indéniabelement des ajouts intéressants au sein de ces dernières, mais dire que la norme C89 n’a plus d’intérêt ou qu’elle est obsolète, c’est alors dire la même chose du C (ce qui peut se soutenir, mais ce n’est pas la question), la norme C89 constituant le fondement des deux autres.

c’est exacte. malgret tout, il y a certains personnes ici qui cherche à me contre dire. croyez vous vraiment que je cherche à complixifier le cimple ou je ne sais quoi ? la véritée, ce qui semble cimple ne l’est en réalité pas. ce que je cherche moi, c’est avant tout un compilateur stricte. je n’ai nullement besoin que les développeur d’un compilateur me dissent on respecte l’ansi c, et qu’apprès on m’autorise. à définir des tableaux à taille variable.

Juste une note : aucun système d’exploitation n’est conforme à l’ANSI C. Ils ne sont déjà pas conformes à l’ISO C, d’une part parce qu’ils utilisent pléthore d’extension et d’autre part parce qu’ils font des trucs explicitement mentionnés comme étant des undefined behaviors dans la norme.

finalement, il n’est pas ci inintéressant mon sujet.

On se calme ici, inutile de s’énerver. Même quand quelqu’un présente un avis contraire, merci de le respecter calmement. Ceci est un forum, non un service client.

désolé, je me suis juste un peu laissé emporter.

ce que je cherche moi, c’est avant tout un compilateur stricte.

Confère ma première réponse, alors…

Bon congé dominical à toi.

Je n’ai jamais dit que le sujet était inintéressant. Seulement, il y a beaucoup de légendes autour du langage C et quand tu bosses tous les jours avec ce langage, ça peut devenir lassant de les voir apparaître à tous les coins de rue surtout quand elles sont annoncées d’un ton péremptoire. Des choses comme :

• le C est le langage le plus performant -> si le développeur écrit des algos qui le permettent, et surtout s’il a te temps de le faire.
• le C c’est la base de tout -> C est basé sur pleins de choses avant lui.
• on écrit les OS en C parce que c’est mieux -> on a juste commencé avec C et ce serait con de repartir from scratch aujourd’hui.
• et pour l’embarqué -> c’est surtout une question de support et de prévisibilité.
• le C permet de comprendre la machine -> entre nous et la machine, il y a 18 millions de lignes de noyau et la bibliothèque C, et la compilation.
• avec C on a un max de contrôle donc on peut écrire du code bien plus précis -> oui, et la moindre imprécision sera invisible et potentiellement fatale (coucou OpenSSL).

Bref, C c’est plus souvent choisi par contrainte que l’inverse.

• la participation à un projet existant ;

Oui, mais sur ce point, il n’est pas réellement nécessaire de s’auto-contraindre à du C ANSI (ni sur l’autre d’ailleurs). Sur les questions de projet existant, il est très rare qu’on soit vraiment forcé à des normes anciennes, c’est plutôt pour les domaines ultra-critiques que c’est le cas (et puis là, généralement, on n’a de toute façon même pas accès à la moitié de ce qui est dans l’ANSI C).

Et pour la création de nouveaux projets, c’est même l’inverse : on contraint à respecter scrupuleusement une norme ancienne, ce qui pourrait rebuter des développeurs qui seraient tentés de participer au projet.

Le C++ fait tout ce que fait le C, exactement de la même façon, et il fait plus. C’est tout.

En effet (à quelques exceptions près, comme tu l’as précisé), mais au prix d’une complexité grandissante au fur et à mesure des ajouts et normalisations.

Sur ce point je suis obligé de m’insurger : quantité ne signifie pas complexité. Les normes récentes simplifient énormément le développement, notamment la gestion des ressources. Faire du code correct en C++ avant que les pointeurs intelligents soient introduits dans la norme était bien plus complexe parce que les exceptions existaient déjà.

Il est bien plus facile de débuter et d’évoluer dans C++ aujourd’hui que ça ne pouvait l’être il y a 10/15 ans.

Euh le modèle mémoire quand même, ça aide un peu à comprendre ce qui se passe dans un code. Puis pour les questions de performances, le mot "restrict" c’est pas des blagues. Et sans parler de choses complètement indispensable, les déclarations au plus près, ça aide les analyses du compilateur et celle de l’humain quand il lit le code. Finalement, il y a quand même les corrections dans la sémantique de la norme, et les éléments complètement cassés qui ont été virés (coucou gets).

Confère ma première réponse, alors…

j’en ai déjà pris note.

Bref, C c’est plus souvent choisi par contrainte que l’inverse.

pour qu’une contrainte existe, il faut deux cas possibles:

• il faut que cette chose soit la seule existante. dans ce cas, pas le chois. il faut faire avec. cette possibilité est réfutée car, entre ada, c++ et bien d’autres, c n’est pas le seule langage existant.
• qu’elle soit la plus appropriée. dans ce cas, c gagne à tous les coups. il est bas niveau, multitâches, et son temps d’exécution est excellent.

Ah, mais nous sommes bien d’accord, je répondais dans ce cadre à Stranger qui parlait plus généralement du C.

Le développement s’en trouve effectivement simplifié (et en un sens, heureusement), mais cela sous tend une grande complexité. Il est par exemple nettement plus complexe d’expliquer ce que sont cin et cout et ce qu’ils font que d’expliquer ce qu’est une structure FILE et à quoi elle sert.

Ce que tu cites constitue certes des ajouts intéressants (quoique la suppression de gets est juste un pur détail), mais, comme je le disais : ils ne sont pas indispensables ou essentiels en vue de résoudre un problème particulier. Je me répète, mais programmer en C89 aujourd’hui ne diminue en rien les possibilités offertes par le langage. Je ne prétend pas qu’il faut programmer en C89 (je ne le fais pour ma part pas), juste que choisir cette norme n’aura pas particulièrement d’impact par rapport au choix d’une autre.

Pour qu’une contrainte existe, il faut qu’il n’y ait pas de choix, c’est tout. Et oui, même si j’aimerais qu’il en soit autrement parce que j’apprécie le C, le choix de celui-ci pour la réalisation d’un projet résulte rarement d’une affinité avec lui.

C est très souvent le seul langage existant sur les plateformes un peu exotiques de l’embarqué. Donc c’est relativement commun que l’on soit dans ce cas en fait.

(1) En quoi C++ et Rust ne permettent pas d’aller à aussi bas niveau que C exactement ? Ils peuvent aller à aussi bas niveau sans soucis. En revanche, ils permettent de s’abstraire de ce bas-niveau lorsqu’il n’est pas nécessaire, là où C t’en empêche.

(2) Qu’est ce que t’entends par multi-tâches ?

• on peut faire plein de choses avec ? c’est le cas de plein de langages, tous ceux qui sont tagués "general-purpose", la liste est longue.
• on peut faire du multi-threading ? Ce n’est pas standard ANSI, ni ISO C99 et même ISO C11 indique que le support du multi-threading est optionnel. En revanche, C++(11), Rust ont ce qu’il faut pour le MT en natif, Ada propose aussi un modèle de concurrence.

(3) Pas plus que C++, ou Rust, ou pas mal d’autres langages selon le temps de développement nécessaire. Sans parler du fait qu’il sera plus dur de montrer que le code C est correct.

Avoir un code C++ à tous les coups au moins aussi rapide qu’un code C, c’est facile sur le papier : j’écris le morceau de code en C, j’écris le morceau de code en C++, je regarde lequel est le plus rapide et je le mets dans mon programme C++. Après il est assez commun que les templates C++ permettent justement de poutrer les performances d’un programme C : ils permettent bien plus d’optimisations.

Il est par exemple nettement plus complexe d’expliquer ce que sont cin et cout et ce qu’ils font que d’expliquer ce qu’est une structure FILE et à quoi elle sert.Source:Taurre

Oui et non. Ce sont des détails d’implémentation pour le coup. La norme C ne fixe pas ce que doit exactement être le type FILE, c’est complètement abstrait par la bibliothèque standard que l’on utilise pour être caricatural : un développeur aurait tout à fait le droit de binder le fonctionnement de FILE sur une bibliothèque qui traduit ça en std::ofstream, tant qu’il respecte les contraintes de la norme.

C est très souvent le seul langage existant sur les plateformes un peu exotiques de l’embarqué. Donc c’est relativement commun que l’on soit dans ce cas en fait.

non seulement ada à plusieurs implémentation dans ce domaine, mais c’est aussi l’usage premier pour le quel il a été conçut.

(1) En quoi C++ et Rust ne permettent pas d’aller à aussi bas niveau que C exactement ? Ils peuvent aller à aussi bas niveau sans soucis. En revanche, ils permettent de s’abstraire de ce bas-niveau lorsqu’il n’est pas nécessaire, là où C t’en empêche.

rien que le fait qu’ils autorisent la programmation objet. ce la fait d’eux des langages plus haut niveau que le c.

rien que le fait qu’ils autorisent la programmation objet. ce la fait d’eux des langages plus haut niveau que le c.

Techniquement le C permet de faire de la POO. Ce n’est pas l’orientation native du langage, mais on peut concevoir une application en POO avec du C pur (Linux, U-boot, GTK+ et GLib en sont des exemples). Je l’ai déjà fait dans le cadre de mon travail.

Bien évidemment que le C permet de l’objet. L’objet ce n’est pas juste this et class.

Et les avantages du Rust sont encore plus grands. Les compilateurs C et C++ sont souvent contraints de ne pas faire certaines optimisations importantes à cause d’un potentiel aliasing (deux pointeurs a priori différents qui pointent vers la même zone mémoire), alors que le modèle d’ownership du Rust permet de garantir que deux pointeurs différents ne peuvent pas pointer vers la même zone mémoire à moins qu’ils soient en lecture seule (ce qui n’est pas problématique).

oui, mais la modularité et une force, pas une permission. utiliser des bibliothèque ne sort pas du cadre natif. à condition bien sûr que ces bibliothèques respectent elle aussi les normes. tout bon langage qui se respecte autorise ce genre de chose. en revanche, le c n’a pas de syntaxe objet nativement, contrairement à son descendant ce qui le rend plus rapide.

Ce que tu dis est tellement faux qu’on ne peut même pas le réfuter.

Donc selon toi, ajouter un élément de syntaxe rend un langage plus lent? Dans ce cas, je te conseille d’aller faire de brainfuck. Vu le peu de features, il doit être au moins 100 fois plus rapide que le C.

le c n’a pas de syntaxe objet nativement, contrairement à son descendant ce qui le rend plus rapide.

Tu peux faire du C++ correct sans appeler les mots clés liés à la POO du langage. Et techniquement, une classe, ce n’est qu’une structure avec des pointeurs de fonctions dedans. D’ailleurs, en C++, le mot clé struct est équivalent à class, la différence étant dans le fait que les membres sont privés par défaut pour l’un, publics pour l’autre.

Cela n’a aucune incidence sur les performances à l’exécution, cela revient au même en terme de code généré. La complexité est gérée par le compilateur à la compilation. Et c’est globalement assez transparent.

Même pas nécessairement d’ailleurs. A moins d’utiliser "virtual" ce dont on a rarement besoin finalement, il y aura aucun pointeur de fonction, c’est juste exactement une structure à la C avec des fonctions.

Les classes ne coûtent absolument rien en l’absence de virtual (@tutorials x : et si tu veux contredire ce point, pose un exemple clair avec son équivalent en C et la raison pour laquelle la version est plus rapide), il n’y a aucune raison que ce soit le cas de toute façon : c’est une structure et ses fonctions . Le polymorphisme d’inclusion (virtual) peut coûter un peu, à condition d’en avoir besoin, et si on a un tel besoin la version C impliquerait l’utilisation d’une union taguée avec un enum ce que les compilateurs n’aiment pas non plus quand ils veulent optmiser. Le polymorphisme à l’aide de templates, non seulement il ne coûte rien à l’exécution, mais il permet même largement plus d’optimisations. Raison pour laquelle qsort du langage C est très généralement vachement plus lente que std::sort de C++.

n’importe quoi. pour vous un compilateur prend moins de temps à interpréter des structures complexes, des objets de class, qu’une séquence d’instructions.