Programmation C en 2011 [clôturé]

Il y a plusieurs lunes, j'ai coupé du code C pour gagner ma vie, principalement tout en maintenant un serveur POP3 qui supportait une large gamme d'OS (Linux, * BSD, HPUX, VMS ...).

Je prévois d'éliminer la rouille de mes compétences en C et d'en apprendre un peu plus sur la mise en œuvre du langage en codant un simple FORTH en C.

Mais je me demande comment (ou si?) Les choses ont changé dans le monde C depuis 2000. Quand je pense à C, je pense ...

1. comp.lang.c
2. ANSI C dans la mesure du possible (mais C89 comme C99 n'est pas largement pris en charge)
3. gcc -Wall -ansi -pedantic au lieu d'outils d'analyse statique
4. Emacs
5. Ctags
6. Autoconf + make (et voir le point 2 pour les avantages VMS, HP-UX, etc.)

Est-ce que quelqu'un qui écrit en C depuis onze ans peut me dire ce qui (le cas échéant ;-)) a changé au fil des ans?

(Dans d'autres nouvelles, merde, je fais ça depuis plus d'une décennie).

C'est vraiment difficile pour moi de penser dans le temps comme "Wow, à quoi ressemblait la programmation C il y a 10 ans?", Mais je peux parler de certaines choses que je sais que je fais différemment.

• Bien que vous puissiez généralement invoquer quelqu'un comme Peter Seebach sur comp.lang.c pour obtenir de l'aide sur un bogue particulièrement loufoque que vous soupçonnez être lié au langage, la plupart sinon toutes les questions de programmation C obtiennent des réponses exceptionnelles sur Stack Overflow.

• L'analyse statique est toujours un peu douloureuse. Splint (du moins pour autant que je sache) ne gère pas si bien C99, les graphiques de couverture sont encore un peu pénibles à visualiser. Les avertissements GCC se sont "beaucoup" améliorés (entre guillemets car cela dépend de qui vous demandez).

• Valgrind est le saint de tous les vérificateurs d'erreurs de mémoire et vous indique généralement des problèmes dans votre code qu'aucun outil d'analyse statique ne pourrait / ne pourrait trouver. Ce n'est pas parfait à 100%, mais je ne pense pas que ce soit possible. Je dois très rarement toucher GDB ces jours-ci, ce qui (rien de personnel) me convient parfaitement. L'outil du massif de Valgrind est également un très bon profileur de tas.

• Il y a toujours de nouvelles extensions dans GCC, certaines subtiles , donc -pédantique est une bonne idée si la portabilité est un gros problème. Pour le programmeur novice / rouillé, il est parfois facile de confondre les extensions avec les fonctionnalités de langage «cachées».

• CCAN a émergé (pensez CPAN, mais pour C) et commence à décoller. Il y a beaucoup de joyaux utiles, y compris une adaptation de TAP qui est un outil de test génial. Les cordes en do sont toujours nulles, mais le nombre et la qualité des bibliothèques pour les gérer ont sûrement augmenté au cours des dix dernières années.

• SCons et CMake gagnent en popularité pour la configuration de build. Autoconf / Automake / Libtool sont encore largement utilisés, mais beaucoup de gens se sentent un peu trop limités par M4. Pourtant, si c'est le système que vous aimez utiliser, l'archive de macros Autoconf est toujours bien vivante.

• Il y a évidemment plus d'éditeurs disponibles aujourd'hui. Je n'ai pas encore trouvé un "IDE" qui ne me gêne pas lorsque je travaille avec C, mais c'est probablement parce que je suis un vieil évangéliste buveur de Sanka pour plus de simplicité.

Dans l'ensemble, cependant, je ne dirais pas que la vie (en ce qui concerne C) est même presque profondément différente de ce qu'elle était il y a 10 ans. Mais, à bien des égards, c'est en fait un peu plus facile. Il est difficile d'attribuer cela aux outils plutôt qu'à l'expérience.

glib pourrait être la "nouvelle bibliothèque standard". Il offre une grande partie de ce que beaucoup pensent être exclu de la norme - threading et mise en réseau indépendants de la plate-forme, structures de données de conteneur, etc. Bien sûr, il n'est pas applicable partout, mais si vous pouvez l'utiliser, cela fait gagner beaucoup de temps.

1. StackOverflow ;)
2. J'utilise principalement C pour écrire le firmware des microcontrôleurs de Microchip, et comme leur compilateur est basé sur GCC, j'utilise C99 (mais je ne vais pas fou avec les fonctionnalités supplémentaires, principalement pour restreindre la portée des variables de boucle et des tableaux dynamiques sur la pile). Lorsque j'écris des extensions Python, je m'en tiens à C89 au cas où quelqu'un aurait besoin de le compiler avec MSVC. Je ne sais pas ce que tout le monde utilise.
3. Splint (fonctionne sur C89, pas C99) et l'analyseur statique de Clang - bien que, comme ils s'étouffent tous les deux avec le code du firmware macro-lourd, je n'ai pas une grande expérience avec eux. En fait, une grande partie des choses de LLVM est assez intéressante pour un geek C.
4. D'accord, c'est juste un appât de guerre sainte: P
5. Je n'ai jamais utilisé de Ctags, mais je suis amateur de Doxygen.
6. Dieu que je déteste Autoconf. Je déteste tellement ça. Je n'ai jamais, jamais réussi à fabriquer une boule de boue Autoconf à partir de zéro. Si un projet en avait déjà un, je finirais par bâtarder tout ce qui existe déjà. Si j'écris quelque chose de nouveau, je raconte et délire et cherche des alternatives, bien que je sois damné si j'en ai trouvé une avec laquelle je resterais. La dernière fois que je suis passé par ce cycle, je me suis installé sur SCons, que je pourrais utiliser à nouveau.

2) et 3) ont changé. C99 est grand public, C90 devient de plus en plus obsolète. gcc -Wall -std=c99 -pedantic.

En dehors de cela, les deux changements les plus notables qui n'ont pas déjà été abordés dans d'autres réponses sont:

• C11. ISO 9899: 2011.
• MISRA-C: 2004.

Le langage de programmation C a atteint les 2 ou 3 principaux langages de programmation du journal du Dr Dobb dans sa dernière étude / enquête.

Quant à l'implémentation d'un langage, C est utilisé pour implémenter un nouveau langage en cours de construction chez Google, appelé Go (golang.org).

Je n'ai pas suivi le groupe usenet de C ces dernières années. Je visite souvent son canal IRC Freenode. Il est actif et fréquenté par beaucoup.

De nouveaux programmes sont en cours d'écriture en C, mais ils ne reçoivent pas la publicité qu'ils auraient eu si cette année devait être, disons, 1999.

Ce sont des choses qui viennent à l'esprit. Il pourrait y en avoir beaucoup plus, mais j'espère que vous êtes resté en contact avec votre chapeau de programmeur, bien que vous n'ayez peut-être pas fréquenté le modèle C du chapeau :)

Je pense que le support C99 est meilleur que vous ne le pensez. Visual Studio ne le prend pas en charge, mais tous les autres compilateurs auxquels je peux penser le prennent en charge (avec peut-être quelques omissions ici et là). Si vous n'avez pas besoin de compatibilité avec VS, je dirais que vous allez avec C99, car il est beaucoup plus agréable à écrire que C89 IMHO.