Je vais également aller à contre-courant ici et essayer de faire un cas esthétique (légèrement humoristique) pour C. Alors que certaines personnes pourraient l'appeler "moche" pour différentes raisons, telles que le manque de constructions de niveau supérieur comme les classes ou sa dépendance aux pointeurs, je trouve que ce n'est pas le cas pour moi .
TL; DR : À mon avis, le C est simple, le bon C est lisible et il y a une certaine joie à se retrouver dans les morceaux.
C est simple
La norme C ne définit que quelques types et mécanismes de base pour créer des fonctions, des pointeurs et des tableaux à partir d'eux. En plus de cela, il existe un petit nombre de constructions de composition pour créer des types plus complexes à partir des primitives (comme les structures et les unions). Remarquez comment j'ai décrit la plupart du langage en deux phrases. Cela signifie que vous n'avez pas à garder trop de règles et de formes syntaxiques dans votre tête lors du codage.
C'est simple c'est beau .
C n'est pas mystérieux
Contrairement à de nombreux langages de niveau supérieur, vous auriez du mal à trouver beaucoup de symboles étranges et inintelligibles en C. Dans le monde C, la fonction principale pour l'abstraction et la "compression syntaxique" est la fonction - sémantiquement très simple et construction auto-explicative. Un bon style C encourage une beauté presque poétique et lisible. Pour illustrer cela, essayons de lire l'extrait suivant du noyau Linux. Même sans avoir une bonne compréhension des structures de données sous-jacentes et des détails d'implémentation, nous pouvons comprendre beaucoup de choses comme suit:
bool kthread_freezable_should_stop(bool *was_frozen)
{
bool frozen = false;
might_sleep();
if (unlikely(freezing(current)))
frozen = __refrigerator(true);
if (was_frozen)
*was_frozen = frozen;
return kthread_should_stop();
}
Le milieu de la fonction indique "dans le cas peu probable où le courant gèle, demandez au réfrigérateur si la congélation s'est réellement produite". Le Dr Seuss n'aurait pas pu mieux l'écrire.
Lisable est beau .
C est transparent
Sauf si une instruction C inclut un appel de fonction, vous pouvez généralement avoir une très bonne idée de son coût d'exécution et de ses effets secondaires. C donne au programmeur le contrôle et finalement lui fait confiance pour faire la bonne chose. Nous pouvons obtenir une image de ce qui se passe lorsque cet extrait (légèrement reformaté pour SE) de l'implémentation de strlen()dans la bibliothèque GNU C s'exécute, car chaque opérateur a une sémantique bien définie. Il n'y a pas de surcharge en C.
for (char_ptr = str; ((unsigned long int) char_ptr & (sizeof (longword) - 1)) != 0;
++char_ptr)
if (*char_ptr == '\0')
return char_ptr - str;
Aux fins de "l'optimisation", cette propriété est grande. On peut dire que certains langages de niveau supérieur facilitent l'expression concise d'algorithmes de niveau supérieur (comme C ++ avec des classes et la surcharge), mais pour les fins C a été conçu pour - agissant comme un assembleur portable - C est idéal. Parfois, lors de l'exécution réussie de code de bas niveau, un programmeur peut se sentir un avec la machine, dans un sens (ou zéro - c'est un détail d'implémentation). Cela ne veut pas dire que les autres langues sont mauvaises, pas assez "zen" ou quelque chose de stupide comme ça, juste que l'OMI C peut être intéressant d'une manière que de nombreuses autres langues ont choisi de ne pas l'être, pour de nombreuses raisons valables.
À mon avis, les trois points présentés ci-dessus rendent gérable la création de systèmes complexes - mais efficaces -, incarnés dans mon esprit par Linux. Je trouve que ce monde fait appel à mes sensibilités esthétiques et je conseillerais à quiconque considère C comme sa prochaine cible de considérer ces points. Je pense que les arguments sur les systèmes d'exploitation et autres sont mieux pris en charge en les énonçant explicitement car on n'a certainement pas besoin de comprendre les noyaux pour être un programmeur performant, mais on pourrait trouver ces champs convaincants subjectivement.