Le langage de programmation C est-il toujours utilisé?
Je suis un programmeur C #, et la majeure partie de mon développement concerne les sites Web ainsi que quelques applications Windows. En ce qui concerne C, je ne l'ai pas utilisé depuis longtemps, car ce n'était pas nécessaire. Cela m'est venu comme une surprise lorsqu'un de mes amis m'a dit qu'elle devait apprendre le C pour tester des emplois, alors que je l'aidais à apprendre le C #.
J'ai pensé que quelqu'un n'apprendrait le C pour les tests que si le développement se faisait en C. D'après mes connaissances, tout le développement lié à la conception COM et matérielle se fait également en C++. Par conséquent, l'apprentissage du C n'a pas de sens si vous devez utiliser C++. Je ne crois pas non plus à l'importance historique, alors pourquoi perdre du temps et de l'argent dans l'apprentissage du C?
Le C est-il toujours utilisé dans tout type de développement de nouveaux logiciels ou autre chose?
C a l'avantage d'être relativement petit langage, ce qui le rend facile à implémenter un compilateur C (alors qu'un compilateur C++ est un monstre à écrire), et le fait = plus facile d'apprendre la langue. Voir aussi indice TIOBE , selon lequel C légèrement en avance sur C++.
Dans (IMO) ordre décroissant de justification, C est encore beaucoup utilisé pour
Trucs intégrés
Il est beaucoup plus facile de porter un compilateur C sur une petite plate-forme que de porter un compilateur C++. De plus, les partisans de C affirment que le C++ "fait trop de choses derrière leur dos". Cependant, l'OMI c'est FUD.Programmation des systèmes
Encore une fois, cela est généralement dû aux affirmations selon lesquelles il est plus facile de "savoir ce que fait le compilateur". Cependant, de nombreux programmes intégrés bénéficieraient, par exemple, de modèles et d'autres fonctionnalités clés C++.Logiciels open source
C'est surtout un problème d'attitude, cependant: OSS a toujours préféré le C au C++ (alors que c'est le contraire dans de grandes parties de l'industrie). La haine irrationnelle de Torvalds pourrait en fait être la raison la plus importante de cela sur Linux.
C est beaucoup utilisé dans la programmation matérielle embarquée où les ressources sont rares.
Le noyau Linux est écrit en C parce que, selon Linus Torvalds, C++ est un langage horrible .
Tous des langages modernes que j'ai vus peuvent interagir avec C:
- C++
- Java
- C #
- Python
- Haskell
- Objectif c
La nécessité d'interagir avec C découle de:
- C ayant un ABI simple
- C être là depuis longtemps
Cela signifie que puisque ces langages peuvent communiquer avec C, ils peuvent:
- tirer parti de ses bibliothèques
- communiquer entre eux via C (par exemple, Clang est écrit en C++ mais offre Python Liaisons accrochées à son C interface).
Et je parierais que tous comptent sur C pour leurs temps d'exécution (à moins qu'ils ne soient complètement assemblés? Douteux).
C est la Lingua Franca des langages de programmation et l'un des plus simples (ABI-sage) non liés à une architecture spécifique (comme Assembly est), il vais prendre un virage majeur pour s'en débarrasser.
À mon avis, c'est une question à courte vue qui s'apparente à "Mes amis et j'écoute du Reggae. Est-ce que quelqu'un écoute vraiment encore le Rap?".
Chaque langue a son utilité. Différentes langues ont définitivement leurs niches. Mais poser des questions sur C! Je suis sûr que moins de gens utilisent C # que C sur une base quotidienne (du point de vue totalement biaisé de travailler dans un magasin où personne n'utilise C #).
Google recherche rapidement la popularité relative des langues.
Je suis sûr que rien de tout cela fait autorité, mais nous pouvons l'utiliser pour voir les tendances:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
http://langpop.com/
Même en regardant SO rapport de question sur les balises:
https://stackoverflow.com/tags
- C #: 209845
- 16 autres tags
- C: 38790
C est donc le 18 sujet le plus populaire sur SO (et il y a beaucoup d'autres langages là-bas).
Remarque: L'index TIOBE ci-dessus a été constamment mis à jour depuis plus d'une décennie (et certaines données remontent à 3 décennies). Il est censé mesurer les ingénieurs travaillant dans chaque langue (bien que je ne sache pas à quel point cela est précis). Parmi les 10 premiers langages, à l'exception de Java/Visual Basic, il reflète ce que les gens de ma boutique savent (bien que nos ratios soient légèrement différents car nous avons un échantillon beaucoup plus petit).
Vous devrez peut-être utiliser C lorsque vous manquez de ressources et n'avez pas besoin de capacités orientées objet.
De nombreux logiciels utilisés aujourd'hui sont toujours écrits en C, sans parler des pilotes matériels.
Selon Tiobe index, C est toujours le langage le plus utilisé.
Comme l'a suggéré tcrosley, vous voudrez peut-être jeter un œil à cette question connexe .
Vous devriez également vérifier certains articles connexes sur les différences entre C et C++, comme ce wiki ou ce par exemple.
On dirait que vous essayez de vous convaincre que C est inutile et peut donc être ignoré. Décomposons votre question:
"J'ai pensé que quelqu'un n'apprendrait le C pour les tests que si le développement était fait en C."
Non, il y a de nombreuses raisons d'apprendre C. Même si vous ne saviez pas que j'éviterais tout de même d'utiliser des déclarations générales comme celle-ci, surtout en conjonction avec la logique circulaire. Évidemment, il faut connaître la langue dans laquelle le code est écrit pour pouvoir le tester/le corriger correctement, mais cela suppose que la jauge est toujours utilisée comme donnée et est vraie pour n'importe quelle langue et pas seulement C.
"À ma connaissance, tous les développements liés à la conception COM et matérielle se font également en C++."
C'est incorrect.
"Par conséquent, l'apprentissage du C n'a pas de sens si vous devez utiliser le C++. Je ne crois pas non plus à l'importance historique, alors pourquoi perdre du temps et de l'argent à apprendre le C?"
C'est la logique la plus discutable de toutes. Tout d'abord, la signification historique est quelque chose que vous devriez croire, car si vous le saviez, vous savez que C est un sous-ensemble de C++ et, à cause de cela, connaître C peut vous aider à être un meilleur programmeur C++. Bien sûr, C a également influencé la plupart des langues qui l'ont suivi, donc les avantages ne s'arrêtent pas là. De plus, parce que C est si important, il ne peut pas être considéré comme n'ayant qu'une signification historique. Il est encore largement utilisé et ne peut donc pas être relégué à un poste secondaire comme celui-là. Vous pouvez faire valoir que ce n'est pas un langage que chaque programmeur doit utiliser et avoir une connaissance approfondie et ce serait bien, mais s'il vous plaît ne construisez pas votre argument en disant que vous ne croyez pas quelque chose sans examiner d'abord ses véritables mérites.
En plus des systèmes embarqués, la plupart des langages les plus récents ont un moyen de s'interfacer avec C. Lorsque vous écrivez une bibliothèque que vous souhaitez utiliser facilement dans tous ces langages, C est un choix évident. C++, alors qu'il peut également s'interfacer avec certains langages (tels que Python (CPython uniquement))), C++ ne peut pas s'interfacer avec un plus grand nombre de langages en raison de certaines de ses fonctionnalités (nom mangling en particulier, mais Les modèles ABI sont l'un des plus faciles à interfacer (je sais que vous pouvez écrire C++ et utiliser extern "C" pour l'interface. Je m'en fiche).
Il a également l'avantage que C et C++ sont vraiment les meilleurs langages pour la programmation de systèmes et les temps de compilation C sont beaucoup plus rapides. Les temps de compilation C++ sont sensiblement les pires de tous les langages que j'ai utilisés.
Maintenant, alors qu'il existe d'autres langages qui veulent devenir le langage système populaire (je connais D en particulier), une grande majorité de logiciels est écrite en C/C++. Les langages comme D nécessitent que quelqu'un crée un wrapper autour de la bibliothèque C au lieu de simplement l'utiliser directement (comme vous le feriez avec C++).
Je l'utilise presque tous les jours en développant pour iPad/iPhone. De nombreuses bibliothèques sont écrites en C et n'ont pas d'équivalent Objective-C. Alors oui, il est toujours utilisé et par l'un des appareils les plus récents du marché.
Avec C, vous pouvez programmer de nombreux systèmes embarqués, il est petit et pratique, et sera probablement là pendant de nombreuses années à venir (aka vous ne perdez pas de temps ni d'argent pour l'apprendre)
consultez langpop.com , en particulier les graphiques de Freshmeat et Google Code. Cela montre que C est toujours en avance.
C est toujours populaire sur les systèmes où vous devez vous rapprocher du métal (c'est-à-dire du système embarqué) et des applications gourmandes en performances.
Portabilité.
Faites une liste de tous les systèmes qui, selon vous, exécuteront le code C, puis une liste similaire pour toutes les autres langues que vous aimez.
Si vous avez trouvé la même réponse que moi, la conclusion est oui.
Généralement pour le système embarqué C est encore largement utilisé.
Cette question donne un autre exemple.
index Tiobe , qui tente de classer la langue par popularité / utilisation , met systématiquement C en premier lieu.
Eh bien, je pense que C est le langage le plus puissant pour les raisons suivantes!
1) AT premier C, c'est un langage système (ce qui signifie qu'il peut être utilisé pour faire de la programmation de bas niveau avec un temps d'exécution minimal ou nul).
2) Vitesse de l'application résultante. Le code source C peut être optimisé beaucoup plus que les langages de niveau supérieur car l'ensemble de langues est relativement petit et très efficace. C'est à peu près aussi proche que possible de la programmation en langage assembleur, sans programmation en langage assembleur. et vous pouvez même utiliser Assembly et C ensemble!
3) C a qui est son application en programmation Firmware (hardware). Cela est dû à sa capacité à utiliser/travailler avec Assembly et à communiquer directement avec les contrôleurs, processeurs et autres périphériques.
4) C est un bloc de construction pour de nombreux autres langages actuellement connus. Recherchez l'historique de C et vous constaterez qu'il existe depuis un certain temps (comme les langages de programmation disparaissent de toute façon). Jetez un œil à Python par exemple un langage de programmation de haut niveau entièrement orienté objet. Il est écrit en C (peut-être aussi C++). Cela vous dit si vous voulez savoir ce qui se passe sous le capot dans d'autres langues; comprendre le C et son fonctionnement est essentiel.
Un langage d'applications est utilisé pour la programmation de haut niveau, par ex. écrire un traitement de texte ou un jeu. Des exemples de langages d'applications sont Java, C #. La raison en est qu'ils contiennent la récupération de place, la saisie automatique, la validation au moment de l'exécution, etc. - où l'accent est mis sur la productivité.
Un langage système est utilisé pour la programmation de bas niveau. par exemple. Un microcontrôleur, un pilote et un noyau OS. Les exemples incluent Assembly, C. Ils nécessitent peu ou pas d'exécution pour exécuter le code directement sur le matériel, et l'accent est mis sur le programmeur pour avoir un contrôle direct sur le matériel.
Globalement, il diminue en tant que langage d'applications, mais reste solide en tant que langage de systèmes.
Oh oui, il est utilisé. Je travaille dans le domaine du traitement de paquets réseau. J'ai travaillé dans deux sociétés différentes où nous traitons des paquets réseau. Donc, nous fonctionnons au niveau Ethernet ou IP, pas au niveau supérieur à TCP.
Fait intéressant, dans les deux sociétés, C a été préféré à C++. Dans l'une des sociétés, l'un des deux produits a été construit au-dessus du noyau Linux, tandis que l'autre produit a été construit dans l'espace utilisateur Linux. Le produit du noyau a évidemment utilisé C car le noyau Linux est programmé en C, mais ils ont également choisi d'utiliser C pour le produit de l'espace utilisateur. Les deux produits ont été développés à partir de l'an 2000 environ (le produit noyau un peu avant 2000 et le produit espace utilisateur un peu après 2000).
Dans l'entreprise où je suis allé après, le produit était construit sur C, pas sur C++. Il s'agit en fait d'une continuation d'un projet du milieu des années 1990, bien qu'en raison des récentes demandes d'amélioration des performances, il a été décidé que tout sera essentiellement réécrit. Nous avions une option pour sélectionner C++ en raison de cette réécriture, mais nous ne l'avons pas fait.
Dans le domaine du traitement des paquets réseau, les performances comptent beaucoup. Donc, je veux implémenter ma propre table de hachage ayant des performances plus élevées que les tables de hachage existantes. Moi, pas l'auteur de la table de hachage, suis celui qui sélectionne la fonction de hachage à utiliser. Peut-être que je veux des performances et optez pour MurMurHash . Peut-être que je veux de la sécurité et optez pour SipHash . Les allocateurs de mémoire sont évidemment personnalisés. En fait, toutes les structures de données importantes que nous utilisons ont été implémentées sur mesure pour les meilleures performances possibles.
Bien qu'il n'y ait rien qui empêcherait l'utilisation de C++, c'est généralement une mauvaise idée. Une seule exception levée par paquet réduira le taux de traitement des paquets à des niveaux inacceptables! Donc, nous ne pouvons pas utiliser les exceptions de C++. Beaucoup trop lent. Nous utilisons déjà une sorte de code C orienté objet en implémentant des structures de données en tant que structures, puis en implémentant des fonctions opérant sur ces structures. C++ permettrait d'avoir des fonctions virtuelles, mais là encore, les appels de fonctions virtuelles tueraient les performances s'ils étaient utilisés partout. Il est donc préférable d'être explicite et d'avoir un pointeur de fonction si des appels de fonction virtuels sont nécessaires.
C++ fera beaucoup de choses derrière votre dos: allocation de mémoire, etc. En revanche, en C, cela ne se produit généralement pas. Vous pouvez écrire une fonction qui alloue de la mémoire, mais généralement, il ressort de l'interface de la fonction que l'allocation se produit.
Comme exemple du type de micro-optimisations que vous pouvez faire lors de la programmation en C, jetez un œil à la macro container_of dans le noyau Linux. Bien sûr, vous pouvez utiliser container_of dans le code C++, mais qui fait ça? Je veux dire, c'est tout à fait acceptable dans la plupart des programmes C, mais les programmeurs C++ typiques proposeraient immédiatement autre chose, comme une liste chaînée qui alloue les nœuds de liaison en blocs séparés. Nous ne voulons pas cela car chaque bloc de mémoire alloué est mauvais pour les performances.
La seule chose qui pourrait nous être bénéfique en C++ est peut-être que C++ autorise la métaprogrammation de modèle, ce qui signifie que vous pouvez parfois éviter les appels de fonction virtuels tout en ayant un paramètre de fonction et permettre au compilateur d'inline les fonctions. Mais la métaprogrammation des modèles est compliquée, et nous avons réussi à répondre à toutes les exigences en C, donc l'avantage de cette fonctionnalité en C++ n'est pas si critique.
Dans l'une des sociétés, nous avions en fait un langage compilé personnalisé dans lequel une partie des fonctionnalités était implémentée. Devinez quel était le langage cible du compilateur? Assemblée? Non, nous avons dû prendre en charge les architectures 32 bits et 64 bits. C++? Vous plaisantez sûrement. De toute évidence, c'était C avec GCC's goto calculé . Ainsi, le langage personnalisé a été compilé en C (ou en fait la variante gcc de C qui supportait le goto calculé), et le compilateur C a produit Assembly.
J'utilise toujours C quotidiennement et l'une des principales raisons est à cause de l'interopérabilité avec d'autres langages et d'un SDK conçu pour être utilisé par des plugins construits par toutes sortes de compilateurs dans différentes langues.
Je ne peux pas écrire une API C++ qui utilise des classes avec constructeurs et destructeurs et vtables, surcharge de fonctions, lève des exceptions, etc. qui peuvent être utilisées à partir de Lua, C #, Python, C, etc. sans parler d'un plugin C++ écrit en utilisant différents compilateurs et les paramètres de la nôtre.
Je ne peux pas écrire un SDK C # qui peut être appelé depuis Python, par exemple, ou un SDK Python qui peut être appelé depuis C #.
C est le seul langage ici qui me permet de créer une API qui peut être appelée à partir de n'importe lequel de ces langages. Cela dit, j'utilise souvent C++ pour implémenter ces interfaces C (même si je les implémente parfois en C).
En plus de cela, je trouve parfois C le langage le plus facile à utiliser pour des choses comme les structures de données de bas niveau et les allocateurs de mémoire. Toute la sécurité de type supplémentaire que vous gagnez en C++ n'aide pas si vous écrivez un allocateur de mémoire conçu pour regrouper des bits et des octets alignés. Et par rapport au système de type riche et à la gestion des exceptions de C++, il n'est pas facile de rouler vos propres structures de données - regardez simplement combien d'efforts il faut pour écrire une structure de données aussi triviale que std::vector si vous voulez le protéger contre les exceptions et éviter d'appeler des ctors et dtors sur des éléments que vous n'avez pas insérés dans le conteneur (je parle comme celui qui a implémenté la bibliothèque standard C++ entière). Quand il est très difficile de mettre en œuvre simplement une matrice évolutive, imaginez le travail requis pour mettre en œuvre une BVH de qualité production.
Je préfère le C++ au C quand je veux tiliser les structures de données existantes ou implémenter celles de niveau supérieur en utilisant celles existantes, mais si je vais implémenter une structure de données de bas niveau au cœur de un moteur qui n'a aucune utilité pour les structures de données existantes, C rend cela beaucoup plus facile à faire avec son système de type uber simpliste qui vous permet de simplement memcpy choses ici et memmove choses là, malloc un bloc contigu et realloc là, sans se soucier des constructeurs, destructeurs et exceptions levés.