Discussion :

[Stéphane le calme]

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é.

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».

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 ?

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

Voir aussi :

« Le langage J offre une meilleure approche de l'itération que le C et d'autres », d'après ses concepteurs
Xilinx propose Vitis pour faciliter la programmation de FPGA, avec un compilateur C et des bibliothèques faciles à l'emploi
« 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
« 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
C2Rust : un outil qui permet de faire la traduction et la refactorisation de votre code écrit en langage C vers le langage Rust

[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

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.

[Kannagi]

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 :

(Les routines bas niveau sont en asm).

Je l'utilise aussi pour créer une lib multiplateforme 3D pour la Dreamcast/PS2/GameCube/PC
(la lib es un mélange de C/ASM)
Screen PS2 :

Sreen DC:

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.

[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++

[SofEvans]

- 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.

[Astraya]

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

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.

[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.

[Pyramidev]

Bonjour.

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 Rust :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

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.

- 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.

...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.

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.

[FatAgnus]

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.

[Invité]

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.

[Bktero]

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.

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 :

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.

[FatAgnus]

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.

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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.

[Bktero]

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.

Oula non ! Je ne dis pas que choisir le C++ est un choix éclairé en soit. C'est juste que je pense que c'est un choix naturel mais d'autres peuvent choisir autrement. Après, oui quand Linus dit "pas de C++ dans Linux", il interdit le C++ sur son projet. On est au moins d'accord là-dessus ?

Pour information du trouveras une pléthore de projets écrits en pur langage C, même aujourd'hui, juste par choix des développeurs.

Je n'en doute pas. Mais si je devais vraiment >> troller << je dirais :



Tout ce que tu peux faire en C, tu peux le faire en C++ (même si les standards diffèrent sur certains comportement soi-disant communs). Alors pourquoi se priver ? Rien qu'en compilant avec un compilateur C++, tu as une vérification des types plus forte (un exemple limite anecdotique ici).

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

Choisir de passer en C++ pour le futur ne veut pas dire recoder l'existant en C ! Faut pas s'enflammer comme ça hein

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.

Orthodox C++ ressemble plus à des coding rules pour moi. Touts les projets en ont. Même le mien qui utilise C++17 et lorgne déjà sur C++20 s'est interdit certaines features et utilise certaines autres avec modération. Pour ce qui est "proche de la machine", on fait de l'embarqué sur Cortex-M4, on a des contraintes importantes sur les tailles mémoires (RAM, ROM) et le temps CPU, on fait des calculs intensifs pour faire du pilotage moteur (avec les contraintes temps réel qui vont avec), on gère plein de matériel (EEPROM, flash, Bluetooth, capteurs)... et on est en C++17 dans tout ça

[Astraya]

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/

[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é.

[Kannagi]

Désolé de ne pas répondre au débat sur le C

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é.

Alors tu vas être déçu , il n'ya aucun site (a ma connaissance) qui parle de ça.
Disons que j'ai de solides bagages en bas niveau donc communiquer avec le hard c'est mon dada

Alors sur ce genre de machine , il y'a aucun lib , si tu veux afficher un truc , tu demande au hardware de le faire
Cela ressemble pas mal à de l'embarqué , y'a pas mal de point commun entre codé sur une console de cette gen et de faire de l'embarqué sans OS.
En général j'utilise quelque lib fait par les amateurs (principalement la libc , le joypad et les lib du kernel).

Pour l'export des models 3D , j'ai utilisé un tools personnel que j'ai codé en C++ (avec la lib assimp) , assimp permet de lire la plupart des formats 3D existants , ensuite je le converti dans un format optimisé pour ces machines

Pour l'assembleur , je ne fais que de l'asm inline en C un exemple de multiplication de matrice sur PS2 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
void LMP3D_MatrixMultiply(float* dest,float* src1,float* src2)
{
  asm __volatile__(
    "lqc2            vf16,0x00(%1)\n"
    "lqc2            vf20,0x00(%2)\n"
 
    "lqc2            vf21,0x10(%2)\n"
    "lqc2            vf22,0x20(%2)\n"
    "lqc2            vf23,0x30(%2)\n"
 
    "lqc2            vf17,0x10(%1)\n"
    "lqc2            vf18,0x20(%1)\n"
    "lqc2            vf19,0x30(%1)\n"
 
    "vmulax          ACC,vf20,vf16\n"   //ACC = VF20 * VF16.x
    "vmadday         ACC,vf21,vf16\n"   //ACC = ACC + VF21 * VF16.y
    "vmaddaz         ACC,vf22,vf16\n"   //ACC = ACC + VF22 * VF16.z
    "vmaddw          vf16,vf23,vf16\n"  //VF16 = ACC + VF21 * VF16.w
 
    "vmulax          ACC,vf20,vf17\n"
    "vmadday         ACC,vf21,vf17\n"
    "vmaddaz         ACC,vf22,vf17\n"
    "vmaddw          vf17,vf23,vf17\n"
 
    "vmulax          ACC,vf20,vf18\n"
    "vmadday         ACC,vf21,vf18\n"
    "vmaddaz         ACC,vf22,vf18\n"
    "vmaddw          vf18,vf23,vf18\n"
 
    "vmulax          ACC,vf20,vf19\n"
    "vmadday         ACC,vf21,vf19\n"
    "vmaddaz         ACC,vf22,vf19\n"
    "vmaddw          vf19,vf23,vf19\n"
 
    "sqc2            vf16,0x00(%0)\n"
    "sqc2            vf17,0x10(%0)\n"
    "sqc2            vf18,0x20(%0)\n"
    "sqc2            vf19,0x30(%0)\n"
    : : "r"(dest), "r"(src1), "r"(src2) : "memory");
}

Apres sur PS2 , tu as un assembleur spécifique pour codé les VU0 et VU1 , mais ce sont des processeurs assez complexe , si tu veux un exemple de code asm que ça donne :
https://paste.ofcode.org/N669stSa3RSJuHR4C8YUF7

Mais la PS2 est un cas bien particulier niveau programmation , elle possède une architecture atypique sur certain point

Pour anecdote je ne compte plus le nombre de nouvel embauché ou prestataire qui vient me dire que ça serait bien de remplacer toute notre base de code par du Rust parce que c'est le mieux qui se fait et que faut se mettre à jour. Bah je leur répond qu'il serait temps qu'ils pensent bas niveau et qu'ils me trouvent comment compiler du Rust pour des vieux processeurs comme du Motorola 68000 et qu'on en reparlera. J'attends toujours, depuis bizarrement ils font du C et ils ne s'en plaignent pas.

Vous utilisez du M68000 ?
C'est un processeur que je connais bien , mais je suis étonné que le compilateur GCC pour le 68000 reste bien inférieur a ce qu'en peut faire en asm.
Par exemple pour mon SDK pour la Neo Geo (qui utilise le 68k) , mon code asm pour la décompression est 3 fois plus rapide que le code C (pourtant en -O3).
Du coup j'ai l'impression que GCC est vraiment performant que pour le x86 pour les autres architecture les compilateurs sont bon , mais j'ai l'impression que le code asm reste assez supérieur (si on à un bon niveau) :/
du coup ma question est vous utilisez le compilateur GCC pou un compilo spécifique ?

[transgohan]

Vous utilisez du M68000 ?
C'est un processeur que je connais bien , mais je suis étonné que le compilateur GCC pour le 68000 reste bien inférieur a ce qu'en peut faire en asm.
Par exemple pour mon SDK pour la Neo Geo (qui utilise le 68k) , mon code asm pour la décompression est 3 fois plus rapide que le code C (pourtant en -O3).
Du coup j'ai l'impression que GCC est vraiment performant que pour le x86 pour les autres architecture les compilateurs sont bon , mais j'ai l'impression que le code asm reste assez supérieur (si on à un bon niveau) :/
du coup ma question est vous utilisez le compilateur GCC pou un compilo spécifique ?

Historiquement nous sommes sur la chaîne de Microtec.
Nous avions tenté de passer sous GCC il y a 5 ans il me semble pour des questions de coût mais nous avons déchanté en tombant sur des bugs du compilateur (que je n'ai plus en tête mais ça nous a fait perdre pas mal de jours...).

Microtec racheté par Mentor Graphics, une filiale de Siemens si je ne m'abuse.
C'est propriétaire donc, et cela coûte un bras (7000$ la licence flottante si je ne m'abuse).
Sachant que la version la plus à jour il me semble est une versions pour Solaris.
Mais on utilise la version Linux sans problème vu depuis 2ans.