Joyeux anniversaire ANSI C : cela fait déjà 30 ans que le langage de programmation C a été normalisé

Version imprimable

Voir 40 message(s) de cette discussion en une page

16/12/2019, 14h44
Stéphane le calme

2 pièce(s) jointe(s)

Joyeux anniversaire ANSI C : cela fait déjà 30 ans que le langage de programmation C a été normalisé
Joyeux anniversaire ANSI C : cela fait déjà 30 ans que le langage de programmation C a été normalisé,
petit tour d'horizon sur son évolution

ANSI C est un nom commun désignant la norme du langage de programmation C et, bien que le document dont ce nom dérive ait été remplacé à plusieurs reprises depuis longtemps, le nom est encore parfois utilisé avec la norme actuelle. L'origine de ce nom standard (qui vient évidemment de l'American National Standards Institute), ainsi que le nom ISO C (également explicitement tiré de l'acronyme de l'Organisation internationale de normalisation), sont liés aux documents résultant du processus de consensus.

Le langage de programmation C est antérieur à toute normalisation officielle d'une décennie. C a été développé aux Laboratoires Bell en 1972 par Dennis Ritchie, et bon nombre des principes et des idées qu'il a incorporés dans le langage ont été empruntés aux ancêtres précédents du langage de programmation B et B, BCPL et CPL. En 1983, l'Institut national américain de normalisation (ANSI) a formé un comité de normalisation (X3J11) du langage qui a abouti en 1989 à la norme dite ANSI C ou C89 (formellement ANSI X3.159-1989). Le langage de programmation C a donc été ratifié le 14 décembre 1989. Ce standard originel a unifié les pratiques existantes avec quelques nouveaux ajouts. Il a fallu attendre le printemps 1990 pour que cette norme soit également adoptée par l'Organisation internationale de normalisation (C90, C ISO, formellement ISO/CEI 9899:1990). ANSI C est une évolution du C K&R qui reste extrêmement compatible. Elle reprend quelques idées de C++, notamment la notion de prototype et les qualificateurs de type.

À cette époque, la norme spécifiée dans le document ANSI X3.159-1989 est devenue ANSI C, mais elle a rapidement été remplacée, car elle a été adoptée en tant que norme internationale, ISO / IEC 9899: 1990, dans le cadre des travaux de l'ISO / IEC JTC 1. Bien que ce soit l'origine du nom ISO C, la norme nationale et la norme internationale ont également été différenciées respectivement C89 et C90. Au cours des années qui ont suivi l'établissement de la norme internationale ISO / CEI 9899, plusieurs révisions et plusieurs rectificatifs ont été publiés. La quatrième édition de la norme, ISO / IEC 9899: 2018 - Technologies de l'information - Langages de programmation - C définit le langage de programmation C actuel.

Quelques fonctionnalités de C qui en font toujours un langage populaire

C est un langage de programmation impératif et généraliste. Il est qualifié de langage de bas niveau dans le sens où chaque instruction du langage est conçue pour être compilée en un nombre d'instructions machine assez prévisible en termes d'occupation mémoire et de charge de calcul. En outre, il propose un éventail de types entiers et flottants conçus pour pouvoir correspondre directement aux types de données supportés par le processeur. Enfin, il fait un usage intensif des calculs d'adresse mémoire avec la notion de pointeur6.

Hormis les types de base, C supporte les types énumérés, composés, et opaques. Il ne propose en revanche aucune opération qui traite directement des objets de plus haut niveau (fichier informatique, chaîne de caractères, liste, table de hachage…). Ces types plus évolués doivent être traités en manipulant des pointeurs et des types composés. De même, le langage ne propose pas en standard la gestion de la programmation orientée objet, ni de système de gestion d'exceptions. Il existe des fonctions standards pour gérer les entrées-sorties et les chaînes de caractères, mais contrairement à d'autres langages, aucun opérateur spécifique pour améliorer l'ergonomie. Ceci rend aisé le remplacement des fonctions standards par des fonctions spécifiquement conçues pour un programme donné.

Pièce jointe 524681

C'est un des langages les plus utilisés, car :
- il existe depuis longtemps, le début des années 1970 ;
- il est fondé sur un standard ouvert ;
- de nombreux informaticiens le connaissent ;
- il permet la minimisation de l'allocation mémoire nécessaire et la maximisation de la performance, notamment par l'utilisation de pointeurs ;
- des compilateurs et bibliothèques logicielles existent sur la plupart des architectures ;
- il a influencé de nombreux langages plus récents dont C++, Java, C# et PHP ; sa syntaxe en particulier est largement reprise ;
- il met en œuvre un nombre restreint de concepts, ce qui facilite sa maîtrise et l'écriture de compilateurs simples et rapides ;
- il ne spécifie pas rigidement le comportement du fichier exécutable produit, ce qui aide à tirer parti des capacités propres à chaque ordinateur ;
- il permet l'écriture de logiciels qui n'ont besoin d'aucun support à l'exécution (ni bibliothèque logicielle ni machine virtuelle), au comportement prévisible en temps d'exécution comme en consommation de mémoire vive, comme des noyaux de système d'exploitation et des logiciels embarqués.
Nous pouvons également souligner d'autres éléments comme :
1. Sa portabilité : il s'agit de l'utilisabilité du même fragment de code dans différents environnements. Les programmes C peuvent être écrits sur une plateforme et exécutés sur une autre avec ou sans aucune modification.
2. Sa Modularité (langage structuré) : cette caractéristique du langage C permet au programme d'être divisé en unités plus petites et exécuté individuellement à l'aide de fonctions. La programmation modulaire fait donc référence à la technique de conception logicielle qui augmente le nombre de fragments du même code. Par exemple, vous voulez trouver l'aire d'un carré, d'un rectangle et d'un triangle. Au lieu d'écrire le code dans son ensemble, vous pouvez le diviser en fonctions distinctes, une pour trouver l'aire d'un carré, d'un rectangle et d'un triangle respectivement. Il garantit moins de risques d'erreurs et le rend visuellement attrayant et plus organisé.
3. Sa simplicité et son efficacité : le style de syntaxe de la programmation C est facile à comprendre et peut être utilisé pour concevoir des applications qui étaient précédemment conçues par le langage d'assemblage.
4. Sa vitesse : comme il s'agit d'un langage basé sur un compilateur, il est relativement plus rapide que d'autres langages de programmation comme Java ou Python, qui sont basés sur un interpréteur. Un compilateur considère l'ensemble du programme comme une entrée et génère ainsi un fichier de sortie avec le code objet tandis qu'un interpréteur prend instruction par instruction en entrée puis génère une sortie, mais ne génère pas de fichier.
5. Sa popularité : c'est l'un des langages les plus utilisés dans le développement de systèmes d'exploitation et embarqués.
6. Son dynamisme : il prend en charge la fonction DMA (Dynamic Memory Allocation), qui aide à l'utilisation et à la gestion de la mémoire. Parmi toutes les fonctionnalités de C, le dynamisme est unique. À l'aide de DMA, la taille d'une structure de données peut être modifiée pendant l'exécution à l'aide de certaines fonctions prédéfinies dans la bibliothèque C telles que malloc(), calloc(), free() et realloc().
7. Le respect de la casse : il traite les caractères minuscules et majuscules différemment. Par exemple, si nous déclarons une variable «x» de type entier, cela signifierait une signification complètement différente si nous tapons «X» plutôt que «x».
Pièce jointe 524693

Ses principaux inconvénients sont :
- le peu de vérifications offertes par les compilateurs d'origine (K&R C), et l'absence de vérifications à l'exécution, ce qui fait que des erreurs qui auraient pu être automatiquement détectées lors du développement ne l’étaient qu’à l'exécution, donc au prix d’un plantage du logiciel ;
  - sous UNIX, on pouvait utiliser les utilitaires lint et cflow pour éviter de tels mécomptes ;
  - des vérifications sont ajoutées avec le temps, mais elles restent partielles ;
- son approche de la modularité restée au niveau de ce qui se faisait au début des années 1970, et largement dépassée depuis par d'autres langages :
  - il ne facilite pas la programmation orientée objet ;
  - il ne permet pas de créer des espaces de noms ;
- la gestion d'exceptions très sommaire ;
- le support très limité de la généricité, malgré l’introduction des expressions à type générique en C11 ;
- les subtilités de l'écriture de programmes portables, car le comportement exact des exécutables dépend de l'ordinateur cible ;
- le support minimaliste de l'allocation de mémoire et des chaînes de caractères, ce qui oblige les programmeurs à s'occuper de détails fastidieux et sources de bugs ; il n'y a notamment pas de ramasse-miettes standard ;
- les bogues graves qui peuvent être causés par un simple manque d'attention du développeur ; tel le dépassement de tampon qui constitue une faille de sécurité informatique exploitable par les logiciels malveillants ;
- certaines erreurs ne peuvent être détectées automatiquement qu'à l'aide d'outils supplémentaires et non standardisés, comme lint et Valgrind.
Source : blog ANSI

Et vous ?

:fleche: Développez-vous en C ?
:fleche: Dans le cadre de développements personnels ou en entreprise ?
:fleche: Quels sont les éléments qui vous intéressent le plus dans ce langage ?
:fleche: Quels sont ceux qui vous posent le plus de problèmes ?

Voir aussi :

:fleche: « Le langage J offre une meilleure approche de l'itération que le C et d'autres », d'après ses concepteurs
:fleche: Xilinx propose Vitis pour faciliter la programmation de FPGA, avec un compilateur C et des bibliothèques faciles à l'emploi
:fleche: « Pourquoi le C est mon meilleur choix pour programmer des jeux vidéo », d'après un travailleur de la filière qui s'appuie aussi sur le C++ pour ses projets commerciaux
:fleche: « Rust est le futur de la programmation système et C le nouvel assembleur », d'après un ingénieur d'Intel qui explique pourquoi il est pertinent de passer à Rust
:fleche: C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust
16/12/2019, 15h57
Bktero

Perso, je n'utilise plus de ce langage. Je fais du C++ à la place. Je ne vois que 2 bonnes raisons à continuer à utiliser du C :
- pas de possibilité de faire du C++ (pas de compilateur dispo, interdiction sur le projet)
- l'équipe a la flemme de se former

Citation:

Sa portabilité : il s'agit de l'utilisabilité du même fragment de code dans différents environnements. Les programmes C peuvent être écrits sur une plateforme et exécutés sur une autre avec ou sans aucune modification.

Ca relève un peu du troll ça aussi... Quand tu vois la quantité d'implementation defined behaviors, unspecified, et undefined behaviors (c'est pas bien on en fait tous, des fois sans faire exprès) dans la norme, faire un code vraiment portable, c'est souvent utopique.
16/12/2019, 16h36
Kannagi

2 pièce(s) jointe(s)

Le C , je l'utilise que pour mes projet personnel par exemple j'ai créer un SDK en C pour coder sur Neo Geo :
https://www.youtube.com/watch?v=zNpwGKqWFXg
(Les routines bas niveau sont en asm).

Je l'utilise aussi pour créer une lib multiplateforme 3D pour la Dreamcast/PS2/GameCube/PC :aie:
(la lib es un mélange de C/ASM)
Screen PS2 :
Pièce jointe 524733
Sreen DC:
Pièce jointe 524737
Cela permet d'avoir un code unique qui permet de viser toutes ces plateformes ! :p

Mais je ne suis plus trop fan de ce langage , à cause des ces nombreux UB et d'une gestion de la mémoire source de bug.
16/12/2019, 17h19
Astraya

Ouahh!! Et pourquoi il n'y a pas sécurité dans le vote???
70% des CVT de Microsoft sont liés au problème de gestion mémoire du C. Je ne parle pas de Linux je n'ai pas de source. C'est un langage catastrophique en matière de sécurité et donc par conséquent de robustesse.
C n'est plus aussi suivi que ça, C99 n'est même pas implémenté par Microsoft!
Bon hormis ce petit troll ;)....

C'est vieux et donc éprouvé, on trouve la réponse à toutes les questions sur le net, les compilateurs sont tweakés à mort pour avoir le code le plus optimisé possible. Mais ça n'empêche que beaucoup de choses sont horribles en C et les seuls raisons pour lesquelles c'est encore utilisés sont:
- L'histoire.
- La palanqué de librairie disponibles.
- Une ABI stable. ( Ce qui dit en passant permet à d'autres langages de l'utiliser )
- Un code performant

Sinon c'est un 0 pour :
- Sécurité.
- Le pointeur pouvant être affecté à 0 est la plus grosse erreur de design.
- Les chaînes de caractères terminant par '\0' qui est responsable de moulte bugs.
- Les macros sont un problème et non une solution.
- Le système header est un gouffre de temps de compilation et de collision de symbol.

J'ai aimé le C, puis j'ai grandi, j'ai aimé le C++ puis j'ai compris, aujourd'hui j'apprends le Rust et le reste c'est C++ ;)
16/12/2019, 17h34
SofEvans

Citation:

Envoyé par Astraya

- Le pointeur pouvant être affecté à 0 est la plus grosse erreur de design.

Je dois être assez fatigué parce que je ne comprends pas du tout ce que tu essayes de dire.
Ton lien ne renvoie que vers des langages ayant "NULL" et "undefined" à leurs disposition afin de spécifier deux état différents.
Il parle aussi de paramètres optionnels dans une fonction ...
Donc on ne parle pas vraiment de langage C, là.

Quel est le problème avec le fait que NULL "vaille" 0 (même si ce n'est, à priori, pas tout le temps vrai) en langage C ?
Cela permet de faire

if (!ptr)

ou

if (ptr && ptr->field)

Si NULL ne valait pas 0, il faudrait inverser le test logique, qui du coup serait moins logique à lire.
16/12/2019, 18h40
Astraya

Citation:

Envoyé par SofEvans

Je dois être assez fatigué parce que je ne comprends pas du tout ce que tu essayes de dire.
Ton lien ne renvoie que vers des langages ayant "NULL" et "undefined" à leurs disposition afin de spécifier deux état différents.
Il parle aussi de paramètres optionnels dans une fonction ...
Donc on ne parle pas vraiment de langage C, là.

Quel est le problème avec le fait que NULL "vaille" 0 (même si ce n'est, à priori, pas tout le temps vrai) en langage C ?
Cela permet de faire

if (!ptr)

ou

if (ptr && ptr->field)

Si NULL ne valait pas 0, il faudrait inverser le test logique, qui du coup serait moins logique à lire.

Tu peux avoir une conférence du personnage responsable de ça ici ;)
https://www.youtube.com/watch?v=ybrQvs4x0Ps

En gros, c'était une erreur reconnue par la personne (Charles Antony Richard Hoare) qui a dit que un pointeur peut être null/0 et ainsi ajouté des crashs/UB à la pelle. Tout ça parce que "c'était plus facile à implémenter". Aujourd'hui cela coûte plusieurs millions au entreprise dans le monde.
16/12/2019, 18h52
Metalman

Comme SofEvans...

Je ne comprends pas les arguments sur le pointeur NULL à 0...
En ASM et dans le processeur c'est ce qu'il se passe (il n'y a pas de valeur "magique"/exception/non-data qui détecte qu'un pointeur est alloué ou non).

J'ajouterais même : les arguments sur la sécurité sont un peu vides...
Ce n'est pas parce que les développeurs ne savent pas faire de C correctement, que le C est un langage qui ne devrait plus être utilisé. (et pas besoin de chercher les problèmes chez Microsoft pour trouver des failles bien pires chez Linux sur bash par exemple... ou descendre un poil dans les couches en dessous avec les "choix" de Intel...)

...enfin les arguments sur les headers, les chaînes de caractères... pareil : c'est creux. Ca correspond exactement au fait que c'est un langage juste au dessus de l'ASM, et donc il faut gérer soi-même beaucoup de choses. Ca tombe bien : quand on est juste au dessus du processeur, c'est exactement ce qu'il faut pouvoir faire.

Dire que le C n'est pas fait pour le codeur du dimanche, oui, ok, ça se tient.
Mais dire que le C est nul sur la gestion des pointeurs NULL, des chaînes de caractères (qui est plutôt un choix sur la philosophie "ligne à ligne" plutôt que "champ de taille fixe prédéfini"), des headers, et de la sécurité... euuuuuuuh... non.
16/12/2019, 19h13
Astraya

Je ne parle pas de l'ASM ici, mais du C qui est un langage qui permet de créer des erreurs car des choix de design ont été fait et sont aujourd'hui reconnu comme de mauvais choix par ceux qui les ont fait.
Erreur que le C++ à tenter d'enrayer avec le destructeur et le concept de RAII.

Juste dire qu'il faut de bon programmeur montre bien l'ignorance. Le meilleur codeur C au monde à créé et créer encore aujourd'hui des use after free etc... Ce n'est pas un problème de codeur, ni d'outils, mais de langage.
Aujourd'hui les développeurs cherche des alternatives car les arguments que j'ai donné sont un problème de langage et peut importe les formations, les outils, le nombre de 0 dans la paie, il y aura toujours un problème en C.

Dans ce cas j'attends les arguments : pourquoi les headers c'est super? pourquoi C apporte de la sécurité? Pourquoi les chaines de caractères avec '\0' sont un bon choix? Quid des langues non latin? Pourquoi un pointeur NULL n'est pas problème? Et comment être sur que à la compilation nous n'avons pas de crash possible?
16/12/2019, 22h26
Kitsune64

Bluffé par ton travail Kannagi. Je ne sais pas par quel chemin t'es passé, librairies utilisées? Si il y en a...pour l'export des modèles de la PS2/DC par exemple. Quel compilateur assembleur utilises tu?
Si t'as un site qui parle des techniques utilisée dans tes projets ça m'intéresse par curiosité.
16/12/2019, 22h41
Bousk

- Pour permettre des lib header-only et donc rien à installer et compiler en plus, juste une directive #include
- Pour pemettre de créer du code via le préprocesseur avec des fichiers de listing de valeurs via macro que l'on inclue et dont on modifie le comportement au besoin.
- C n'apporte pas de sécurité et fournit juste une syntaxe qui est aisément transcriptable en assembleur et code machine. Et il fait ça plutôt bien.
- Pourquoi elles seraient un mauvaix choix ? Ça permet de connaître la taille de la chaîne avec un surcoût fixe : 1 octet (pour des chaînes de char*). Sinon ta chaîne pourrait faire X octets si elle contient moins de 255 caractères ? Puis après X+1 ? Et comment/où se trouve l'octet supplémentaire ? Doit-on toujours allouer 4 octets avant la chaîne au cas où ? Pourquoi se contenter de 4 ?
- Oui la localisation est toujours un problème. Aujourd'hui on voit des chaînes de string<uint32_t> pour ça... mais est-on sûr que ça couvre enfin tous les cas ? Et pour combien de temps ?
- En quoi une valeur spécifique NULL est un problème ? Un pointeur, c'est fait pour pointer sur quelque chose. Pouvoir lui dire qu'il pointe sur rien ne me parait pas aberrant. Doit-on aussi interdire la valeur 0 pour un int ?
- Dès que tu as des inputs utilisateurs, l'impossibilité des crash est le travail du programmeur et du programme. Si l'utilisateur te donne 4 entiers puis demande que tu lui retournes le 5ème de la liste, je vois mal comment la compilation peut gérer ça.

Bonjour.

Citation:

Envoyé par SofEvans

Quel est le problème avec le fait que NULL "vaille" 0 (même si ce n'est, à priori, pas tout le temps vrai) en langage C ?

Le problème du langage C avec les pointeurs nuls est que, au niveau du typage, le langage C ne distingue pas les adresses obligatoires des adresses optionnelles : dans les deux cas, on prend un type de pointeur, qui est une adresse optionnelle. Cette faiblesse dans le typage favorise les bogues. Par exemple, admettons qu'une certaine fonction Config const* User_get_config(const User* user) retourne une configuration optionnelle, car certains utilisateurs n'ont pas encore de config. Un jour, un utilisateur distrait, habitué à ce que la plupart des fonctions qui retournent des pointeurs ne retournent pas de pointeurs non nuls, va oublier de se demander si c'est bien le cas de cette fonction. Il va alors faire comme si le pointeur retourné n'était jamais nul. Dans le meilleur des cas, l'erreur sera interceptée par un test unitaire. Dans le pire des cas, le bogue se retrouvera en production.

Dans un langage statiquement typé qui gère correctement les données optionnelles, les données optionnelles ont un type distinct des données non optionnelles et, pour extraire une donnée d'une donnée optionnelle, on peut passer par une opération de pattern matching qui évite les erreurs d'étourderie. Par exemple, en Rust, on peut faire ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 struct Config { content: i32 } struct User<'a> { config: Option<&'a Config> } impl<'a> User<'a> { fn get_config(&self) -> Option<&'a Config> { self.config } } fn main() { let my_config = Config { content: 42 }; let user_with_config = User { config: Some(&my_config) }; let user_without_config = User { config: None }; for user in [&user_with_config, &user_without_config].iter() { match user.get_config() { Some(conf) => println!("The config content of this user is {}.", conf.content), None => println!("This user does not have any config."), } } }
Résultat de l'exécution :
Code:

1 2 The config content of this user is 42. This user does not have any config.
Dans cet exemple, user.get_config() est une référence optionnelle vers un objet de type Config. On ne peut pas écrire directement user.get_config().content, car la configuration est optionnelle. À la place, on peut utiliser l'opérateur match qui fait ici une sorte de if-else sur l'existence de la config. Si la config existe, alors on va dans la branche Some(conf) => dans laquelle on a accès à la configuration via la variable conf. Si la config n'existe pas, alors on va dans la branche None => dans laquelle la variable conf n'est pas visible.

Citation:

Envoyé par Metalman

J'ajouterais même : les arguments sur la sécurité sont un peu vides...

Le fait que le langage facilite des failles de sécurité par étourderies est une faiblesse comparé à des langages qui empêchent ces étourderies ou les rendent plus difficiles à faire.

Citation:

Envoyé par Astraya

- Les chaînes de caractères terminant par '\0' qui est responsable de moulte bugs.
- Les macros sont un problème et non une solution.
- Le système header est un gouffre de temps de compilation et de collision de symbol.

Citation:

Envoyé par Metalman

...enfin les arguments sur les headers, les chaînes de caractères... pareil : c'est creux. Ca correspond exactement au fait que c'est un langage juste au dessus de l'ASM, et donc il faut gérer soi-même beaucoup de choses. Ca tombe bien : quand on est juste au dessus du processeur, c'est exactement ce qu'il faut pouvoir faire.

Les headers en langage C sont bien inutilement lents à compiler. En effet, si un fichier ".h" est inclus indirectement par n fichiers ".c", alors ce fichier ".h" sera parsé n fois. (Les headers précompilés sont une exception à la règle.)
Les collisions de noms de macros sont aussi un problème. Quand un code inclut un fichier ".h", il n'y a pas de moyen de dire "depuis ce fichier .h, j'importe tels et tels symboles, mais pas les autres", ce qui éviterait, entre autres, d'importer des macros non voulues. Le système modulaire du langage C est foireux.

Les chaînes de caractères terminées par '\0' n'auraient pas dû être le standard des chaînes de caractères. À la place, il aurait fallu avoir des couples (pointeurs vers le premier caractère, nombre d'éléments). C'est bien pratique quand on veut modéliser des sous-chaînes d'une chaîne existante sans réallouer de la mémoire, typiquement quand on fait certaines opérations de parsing. Le cas des chaînes de caractères terminées par '\0' aurait dû être secondaire.

Citation:

Envoyé par Metalman

Dire que le C n'est pas fait pour le codeur du dimanche, oui, ok, ça se tient.

Le langage C n'est pas fait pour les experts non plus, entre autres car il entrave la mise en place d'abstractions.

17/12/2019, 07h30
FatAgnus

Citation:

Envoyé par Bktero

Perso, je n'utilise plus de ce langage. Je fais du C++ à la place. Je ne vois que 2 bonnes raisons à continuer à utiliser du C :
- pas de possibilité de faire du C++ (pas de compilateur dispo, interdiction sur le projet)
- l'équipe a la flemme de se former

Et dans quelle catégorie se trouve les développeurs du noyau Linux ou de GIT ? Linus Torvalds trouve le langage C++ est un langage horrible et ne l'a pas choisi pour une des deux raisons précédentes. Le C++ est tellement bien que certains projets adoptent Orthodox C++ (un sous-ensemble minimal de C++ qui améliore le C, mais évite toutes les choses inutiles du C++ moderne).

Le choix qui manque dans le sondage est la simplicité du langage C (à l'opposé de la complexité du C++), mais aussi le fait que le langage C soit très proche du langage machine.
17/12/2019, 08h42
Invité

Citation:

Envoyé par FatAgnus

Et dans quelle catégorie se trouve les développeurs du noyau Linux ou de GIT ? Linus Torvalds trouve le langage C++ est un langage horrible et ne l'a pas choisi pour une des deux raisons précédentes.

Ben justement, pour linux et git, le choix n'a été fait que par une seule personne : Torvalds, et c'était il y a plus de 20 ans.
17/12/2019, 09h05
Bktero

Citation:

Envoyé par FatAgnus

Et dans quelle catégorie se trouve les développeurs du noyau Linux ou de GIT ? Linus Torvalds trouve le langage C++ est un langage horrible et ne l'a pas choisi pour une des deux raisons précédentes. Le C++ est tellement bien que certains projets adoptent Orthodox C++ (un sous-ensemble minimal de C++ qui améliore le C, mais évite toutes les choses inutiles du C++ moderne).

Le choix qui manque dans le sondage est la simplicité du langage C (à l'opposé de la complexité du C++), mais aussi le fait que le langage C soit très proche du langage machine.

Catégorie 1 bien sûr. Le noyaux Linux est bien antérieur (1991 d'après Wikipédia) à la 1ère normalisation de C++ (1998). On ne peut pas vraiment dire qu'à l'époque, il(s) avai(en)t le choix. Et aujourd'hui c'est interdiction sur le projet et ça se comprend car un seul langage permet de garder une uniformité. Pour Git, vu que Linus n'aime pas C++, il a choisi C (et là on entre dans "interdiction sur le projet").

Après, tu as l'inverse : GCC est depuis un bon moment codé en C++, alors qu'historiquement il était codé en C.

Citation:

Envoyé par https://gcc.gnu.org/gcc-4.8/changes.html

GCC now uses C++ as its implementation language. This means that to build GCC from sources, you will need a C++ compiler that understands C++ 2003. For more details on the rationale and specific changes, please refer to the C++ conversion page.

J'ai lu la page d'Orthodox C++. Il ya des choses pas débiles. Certaines sont mêmes des règles de codage de Google, comme le fait de ne pas utiliser les exceptions ou le RTTI. Beaucoup tombent finalement dans des règles de bonnes conduites des projets C++ modernes. D'autres me paraissent un brin foireuse ("Don't use stream (<iostream>, <stringstream>, etc.), use printf style functions instead." --> mais c'est génial pour facilement afficher des objets de types perso ça !), ou tellement évidentes ("Don't use anything from STL that allocates memory, unless you don't care about memory management." --> oh ! std::vector fait de l'allocation dynamique et je ne veux pas faire d'allocation dynamique alors je ne dois pas utiliser std::vector? Merci Captain Obvious !). Bon par contre :

Citation:

Due to lag of adoption of C++ standard by compilers, OS distributions, etc. it's usually not possible to start using new useful language features immediately.

C'est juste faux : il suffit d'aller sur https://en.cppreference.com/w/cpp/compiler_support et de voir le support massif de C++17 par les compilateurs principaux et de voir à quel point C++20 est déjà pas mal suivi.
17/12/2019, 09h16
transgohan

Citation:

Envoyé par Pyramidev

Le problème du langage C avec les pointeurs nuls est que, au niveau du typage, le langage C ne distingue pas les adresses obligatoires des adresses optionnelles : dans les deux cas, on prend un type de pointeur, qui est une adresse optionnelle. Cette faiblesse dans le typage favorise les bogues. Par exemple, admettons qu'une certaine fonction Config const* User_get_config(const User* user) retourne une configuration optionnelle, car certains utilisateurs n'ont pas encore de config. Un jour, un utilisateur distrait, habitué à ce que la plupart des fonctions qui retournent des pointeurs ne retournent pas de pointeurs non nuls, va oublier de se demander si c'est bien le cas de cette fonction. Il va alors faire comme si le pointeur retourné n'était jamais nul. Dans le meilleur des cas, l'erreur sera interceptée par un test unitaire. Dans le pire des cas, le bogue se retrouvera en production.

Donc pour résumer tu demandes à ce que le langage fasse le boulot du développeur.
Quand une fonction retourne une adresse, on teste toujours que l'adresse n'est pas nulle.

Citation:

Il va alors faire comme si le pointeur retourné n'était jamais nul.

Je répète... Ce n'est pas un problème de langage mais d'interface chaise-clavier à ce niveau là...:roll:

J'attends le jour où l'un de mes collègues considérera qu'à chaque déplacement professionnel il a un remboursement de frais sur sa fiche de paie du mois suivant.
Et que donc il ne vérifiera plus. :mouarf:
17/12/2019, 09h39
Astraya
Citation:

Envoyé par Bousk

- Pour permettre des lib header-only et donc rien à installer et compiler en plus, juste une directive #include

Headers only veux justement dire recompilation dans chaque unité de compilation. De plus le header only brise complément la One Definition Rules... Pourquoi le C++ ajoute les modules? C'est pas pour le fun...

Citation:

Envoyé par Bousk

- Pour pemettre de créer du code via le préprocesseur avec des fichiers de listing de valeurs via macro que l'on inclue et dont on modifie le comportement au besoin.

C'est justement un problème, les macros brise la One Definitino Rules encore une fois... Elle ne vérifie rien, le debug de code rempli de macro est une horreur!

Citation:

Envoyé par Bousk

- C n'apporte pas de sécurité et fournit juste une syntaxe qui est aisément transcriptable en assembleur et code machine. Et il fait ça plutôt bien.

Certes. D'autres langages apporte ceci avec de la sécurité.

Citation:

Envoyé par Bousk

- Pourquoi elles seraient un mauvaix choix ? Ça permet de connaître la taille de la chaîne avec un surcoût fixe : 1 octet (pour des chaînes de char*). Sinon ta chaîne pourrait faire X octets si elle contient moins de 255 caractères ? Puis après X+1 ? Et comment/où se trouve l'octet supplémentaire ? Doit-on toujours allouer 4 octets avant la chaîne au cas où ? Pourquoi se contenter de 4 ?

Je renvoi vers la réponse de Pyramidev. '\0' est un mauvais choix aujourd'hui. Compréhensible à l'époque ou 4 octets (32bits),2 octets (16 bits) voir 8 octets (64bits) était important vu la quantité et le prix de la RAM.
C++ règle ça avec la classe string qui est size_t + pointeur vers tableau de char. Même si ( Je trouve ça regrettable ) pour la rétrocompatibilité il continu de supporter les '\0'.

Citation:

Envoyé par Bousk

- Oui la localisation est toujours un problème. Aujourd'hui on voit des chaînes de string<uint32_t> pour ça... mais est-on sûr que ça couvre enfin tous les cas ? Et pour combien de temps ?

Pour quel encodage? UTF-8? UTF16? UTF32? UCS-2? ASCII n'est rien d'autre qu'un choix technique fait par les états-unis qui parle anglais et qui n'ont besoin que de l'ASCII pour leur alphabet. Mais le monde est plus vaste apparemment :)
https://www.joelonsoftware.com/2003/...ts-no-excuses/
Je t'invite à calculer le nombre max de code point et le nombre actuel. Je pense qu'on est plutôt large même si on part conquérir Mars et qu'on invente de nouvelles langues ;)

Citation:

Envoyé par Bousk

- En quoi une valeur spécifique NULL est un problème ? Un pointeur, c'est fait pour pointer sur quelque chose. Pouvoir lui dire qu'il pointe sur rien ne me parait pas aberrant. Doit-on aussi interdire la valeur 0 pour un int ?
Code:

1 2 3 4 5 int* p = 0; int i = *p; // .... et la? //ou bien int& ref = *p; // .... et la? Une référence est censé être toujours valide non?
Tu confonds la valeur et la fonction. Un int à pour fonction de contenir des valeurs de +2147483647 à -2147483648 et donc 0. Un pointeur à pour fonction de contenir une adresse, 0 n'est pas une adresse! Et le fait d'accepter ça est une erreur de design qui à été faite et dont j'ai mis les liens plus haut dans le fil.
C++ à ajouter std::optional, Rust à les Option<> pour essayer de corriger ce problème de design qui je le rappel est responsable de nombreux mots.

Citation:

Envoyé par Bousk

- Dès que tu as des inputs utilisateurs, l'impossibilité des crash est le travail du programmeur et du programme. Si l'utilisateur te donne 4 entiers puis demande que tu lui retournes le 5ème de la liste, je vois mal comment la compilation peut gérer ça.

Je vais pas prêché ma nouvelle paroisse mais jette un coup d’œil coté Rust, même si c'est juste pour la culture G.

Je ne dénigre pas C, je liste ces problèmes.
J'ai fais beaucoup de C mais d'avantage de C++ et j'ai vu les limites et les problèmes de ces langages. Je ne suis pas sectaires, si un langage à des problèmes il faut les accepter.
Les ignorer en se disant qu'on peut les fixer avec de bon codeur est une erreur et les grandes sociétés ( GAFA et autres ) s'en rendent comptes. Surtout au moment du bilan annuel :D
17/12/2019, 09h44
Astraya

Citation:

Envoyé par transgohan

Donc pour résumer tu demandes à ce que le langage fasse le boulot du développeur.

Et pourquoi pas?

Citation:

Envoyé par transgohan

Quand une fonction retourne une adresse, on teste toujours que l'adresse n'est pas nulle.

A oui? Je te pari que je reprends l'ensemble du code que tu as produit et je trouve le contre exemple ;)

Citation:

Envoyé par transgohan

Je répète... Ce n'est pas un problème de langage mais d'interface chaise-clavier à ce niveau là...:roll:

Vous ne devez pas vous souciez de l'argent que les bugs coûte à une société.
Arrêter de penser que vous êtes des génies qui ne faite aucune erreur sérieux, c'est n'importe quoi.
BEAUCOUP de programmeurs ont le même discours et pourtant il n'y a pas moins de bugs/crashs... J'embauche des gens dans des équipes de dev car je suis lead et je te jure que des réponses comme ça c'est un NON pour intégrer une équipe de dev...

@Pyramidev

Désolé d'être si têtu et d'avoir du mal à comprendre, mais pourquoi ce code ne serait-il pas correct ?
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 #include <stdio.h> #include <stdlib.h> typedef struct config { int content; } config_s; void Config_Constructor(config_s *self, int content) { self->content = content; } typedef struct user { config_s *config; } user_s; void User_Constructor(user_s *self, config_s *config) { self->config = config; } config_s *User_GetConfig(user_s *self) { return self->config; } #define NB_USER 2 int main(void) { config_s config; user_s userList[NB_USER]; Config_Constructor(&config, 42); User_Constructor(&userList[0], &config); User_Constructor(&userList[1], NULL); for (size_t i = 0; i < NB_USER; ++i) { config_s *userConfig = User_GetConfig(&userList[i]); if (userConfig) { printf("The config content of this user is %d.\n", userConfig->content); } else { printf("This user does not have any config.\n"); } } return (EXIT_SUCCESS); }
Résultat :

Citation:

The config content of this user is 42.
This user does not have any config.

Citation:

Envoyé par Pyramidev

Le problème du langage C avec les pointeurs nuls est que, au niveau du typage, le langage C ne distingue pas les adresses obligatoires des adresses optionnelles

C'est la première fois que j'entends parler d'adresse qui peuvent être optionnelles ou obligatoires.
Si par cela tu entends que par exemple, un pointeur donnée à une fonction doit pointer sur quelque chose (adresse obligatoire) ou que ce pointeur peut ne pointer sur rien (adresse optionnelle), alors c'est à la fonction qui reçoit le pointeur de faire le test (assert au minimum) et la distinction entre "pointe sur quelque chose de valide" et "ne pointe sur rien" se fait grâce à NULL.

Citation:

Envoyé par Pyramidev

[...] : dans les deux cas, on prend un type de pointeur, qui est une adresse optionnelle.

Pour aller un peu plus loin : un pointeur n'est pas un type "d'adresse optionnelle".
Un pointeur, c'est un int, ni plus ni moins. C'est juste que la valeur est interprété comme étant une adresse.

Quand à la valeur d'une variable, quelque soit son type, elle est obligatoirement existante.
Ce que je veux dire par là, c'est que quand on déclare une variable, prenons par exemple
Code:

1 2 int a;
la variable "a" a forcement une adresse ET une valeur. (c'est juste physiquement impossible que ce ne soit pas le cas).
On ne choisit pas l'adresse de la variable "a" (c'est l'os qui s'en charge, et heureusement).
Par contre,qu'en est-il de la valeur ?
Et bien avec ce bout de code, la valeur de "a" peut être n'importe quoi.
0, -23, 90, 12345, -9974360 ....

Ca pose déjà problème avec un int, alors que ce passe-t-il si "a" n'est pas de type "int" mais de type "pointeur sur int" ?
Et bien tu as un pointeur qui va pointer vers une case mémoire dont tu n'ai certainement pas le propriétaire, et qui va faire crasher le programme.

C'est pour cela qu'il a fallu "réserver" une valeur ayant la signification "cette adresse n'est pas correct, il n'y a rien à cette adresse, etc etc".
C'est le pointeur NULL, et on se repose entièrement sur lui pour tester si le pointeur que l'on a est "valide" ou "invalide".
Il n'y a rien d'autre en langage C.

Maintenant, je vais aller regarder la conférence mise en ligne par Astraya parce que je ne comprends toujours pas pourquoi "0" était la mauvaise valeur à assigner à NULL.

Citation:

Envoyé par Pyramidev

Cette faiblesse dans le typage favorise les bogues. Par exemple, admettons qu'une certaine fonction Config const* User_get_config(const User* user) retourne une configuration optionnelle, car certains utilisateurs n'ont pas encore de config. Un jour, un utilisateur distrait, habitué à ce que la plupart des fonctions qui retournent des pointeurs ne retournent pas de pointeurs non nuls, va oublier de se demander si c'est bien le cas de cette fonction. Il va alors faire comme si le pointeur retourné n'était jamais nul. Dans le meilleur des cas, l'erreur sera interceptée par un test unitaire. Dans le pire des cas, le bogue se retrouvera en production.

Dans un langage statiquement typé qui gère correctement les données optionnelles, les données optionnelles ont un type distinct des données non optionnelles et, pour extraire une donnée d'une donnée optionnelle, on peut passer par une opération de pattern matching qui évite les erreurs d'étourderie. Par exemple, en Rust, on peut faire ceci :

Dans cet exemple, user.get_config() est une référence optionnelle vers un objet de type Config. On ne peut pas écrire directement user.get_config().content, car la configuration est optionnelle. À la place, on peut utiliser l'opérateur match qui fait ici une sorte de if-else sur l'existence de la config. Si la config existe, alors on va dans la branche Some(conf) => dans laquelle on a accès à la configuration via la variable conf. Si la config n'existe pas, alors on va dans la branche None => dans laquelle la variable conf n'est pas visible.

17/12/2019, 09h47
Astraya

Citation:

Envoyé par FatAgnus

Et dans quelle catégorie se trouve les développeurs du noyau Linux ou de GIT ? Linus Torvalds trouve le langage C++ est un langage horrible et ne l'a pas choisi pour une des deux raisons précédentes. Le C++ est tellement bien que certains projets adoptent Orthodox C++ (un sous-ensemble minimal de C++ qui améliore le C, mais évite toutes les choses inutiles du C++ moderne).

Le choix qui manque dans le sondage est la simplicité du langage C (à l'opposé de la complexité du C++), mais aussi le fait que le langage C soit très proche du langage machine.

Il y a même une tentative de création de pilotes en Rust pour remplacer le C. Sous certaines réserve https://lwn.net/Articles/797828/

Citation:

Envoyé par Bktero

Catégorie 1 bien sûr. Le noyaux Linux est bien antérieur (1991 d'après Wikipéédia) à la 1ère normalisation de C++ (1998). On ne peut pas vraiment dire qu'à l'époque, il(s) avai(en)t le choix. Et aujourd'hui c'est interdiction sur le projet et ça se comprend car un seul langage permet de garder une uniformité. Pour Git, vu que Linus n'aime pas C++, il a choisi C (et là on entre dans "interdiction sur le projet").

Donc si je comprends bien si un développeur choisi C (que ce soit Linus Torvalds ou un autre développeur) pour développer son projet alors c'est une « interdiction sur le projet ». Par contre si un développeur choisi C++ pour développer son projet c'est un choix éclairé ? On est vraiment dans le grand n'importe quoi. Pour information du trouveras une pléthore de projets écrits en pur langage C, même aujourd'hui, juste par choix des développeurs. Exemple, le résolveur Unbound qui en 2004 a été développé en Java pour prototypage à été réécrit totalement en langage C en 2006. Et Linus Torvalds n'y est pour rien.

Citation:

Envoyé par Bktero

Après, tu as l'inverse : GCC est depuis un bon moment codé en C++, alors qu'historiquement il était codé en C.

Pour un projet codé en C++ depuis un bon moment je compte 3 239 474 lignes de C :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
 
--------------------------------------------------------------------------------
Language                      files          blank        comment           code
--------------------------------------------------------------------------------
C                             37690         623497         764765        3239474
C++                           23882         188795         237538         852520
Ada                            6236         285984         379781         809719
Go                             4040          83027         132741         640946
C/C++ Header                   3388         129982         171906         561196
D                              2874          84623         107699         478621
Bourne Shell                    145          79216          65849         424391
Fortran 90                     5936          28538          47431         157868
m4                              216           8587           2188          78154
Assembly                        593          12828          18595          74994
XML                              61           6251            548          46797
Teamcenter def                  158           5922           1141          43353
Expect                          356           7200          13403          29799
HTML                            114            524             29          27739
make                            108           2340           1520          14031
Fortran 77                      532           1563           5968          13448
Objective C                     409           3871           2382          13307
Objective C++                   365           3445           2202          11788
Pascal                           25           1638           6957           8937
Python                           32           1651           1956           7134
awk                              22            568            739           4123
Fortran 95                      110           1029           3033           3184
Perl                             22            638            947           3003
Bourne Again Shell               20            450            715           2095
C#                                9            230            506            879
MUMPS                             5             75              0            366
yacc                              1             56             37            316
OCaml                             1             44             42            272
ASP.Net                           7             37              0            203
vim script                        4             50             71            193
CMake                             1             32             31            186
lex                               1             34             30            154
MSBuild scripts                   1              1              0            140
Haskell                          38             17              0            122
NAnt scripts                      2             17              0            103
MATLAB                            2             10              0             35
DOS Batch                         2              0              0              4
CSS                               1              0              0              1
--------------------------------------------------------------------------------
SUM:                          87409        1562770        1970750        7549595

Citation:

Envoyé par Bktero

J'ai lu la page d'Orthodox C++.

Le seul fait qu'Orthodox C++ existe (mais également d'autres variantes) signifie que C++ ne convient pas à tout le monde. Et que même en 2019 ou 2020 on peut choisir de développer un projet en langage C, car un développeur est plus à l'aise avec ce langage, que le C est beaucoup plus simple que C++ et aussi beaucoup plus proche de la machine. Et non pas interdiction ou refus de monter en compétance.

Voir 40 message(s) de cette discussion en une page