C ? C++ ? ocaml ? perl ?

   for (i = 0; i < n; ++i) {

   for (i = 0; i <= n - 1; i++) {

   while (…) {
       *p++ = *q++;
   }

   for (i = 1; i <= n; i++) {

   for (i = 0; i < n; i++) {

Trackbacks

Aucun trackback.

Les trackbacks pour ce billet sont fermés.

Commentaires

1. Le Wednesday 22 March 2006 à 15:00, par pouype :: site

Un moment j'ai quand même eu peur que tu dise: "ceux qui savent pas coder en C sont des mauvais programmeur". Peut-être parce que j'ai jamais codé en C.

Sinon le tout est très bon, très vrai je trouve. Je suis entierement d'accord sur le fait que les langages "modernes" nous facilite enormement les choses. D'ailleurs, ayant apris à coder avec ce genre de langage je me demande toujours si justement je fais les choses correctement, et si ça ne serais pas interessant pour ma culture que j'apprene à coder en C (voir objective-C car j'adore les concepts objet).

2. Le Wednesday 22 March 2006 à 15:13, par MadCoder :: site

Ceux qui n'ont jamais fait de C ne sont pas pour autant de mauvais programmeurs, néanmoins, je pense que c'est un langage qui devrait faire partie de la culture de n'importe quel programmeur.

Ce langage est proche de la machine, et de plus en plus de gens écrivent du code sans comprendre ce qui se passe derrière, et ne s'aperçoivent pas des pénalités qu'ils payent parce qu'ils ne comprennent pas ce que c'est le cache du processeur, la taille de la mémoire, la pénalité d'allouer, etc...

CF l'article de Spolski, qui dit ça bien mieux que moi.

3. Le Thursday 23 March 2006 à 01:47, par palpatine :: site

On parle de moi ? :) Bon, tu le dis toi-même, un langage comme le C est mal foutu et source d'erreur. Maintenant, le coup du "oui, mais si c'est bien programmé, ça marche sans problème", c'est fort naïf : déjà, parce que je pourrais ressortir la même chose pour l'assembleur à ce niveau-là, et que tout à coup ça paraîtrait évidement faux ; ensuite, parce que faire des tests complets, c'est très dur, très lent, très cher (personne ne le fait vraiment d'ailleurs, et en cas d'IHM au milieu, c'est pire...), et que les preuves mathématiques sont hors de portée pour ce langage. Alors écrire quelques milliers de lignes de code sans erreur, oui, possible, maintenant écrire avec plusieurs autres personnes des dizaines de milliers de lignes sans erreur, j'attends toujours de voir ça ; sans compter que pour ne pas avoir à réinventer la roue, on se base sur des bibliothèques bien souvent foireuses (qd je valgrinde mon jeu, j'ai droit aux milliers d'erreurs de SDL et pire, des drivers ATI tout pourris... Et je ne parle pas des comportement bizarres qui s'en suivent, et que je suis obligé de patcher comme un goret, démo au prochain Paris-Carnet ;) ).
Passé cette évidence, le problème est de savoir si un langage peut éviter ce genre de choses. La syntaxe ML évite la notion de pointeur, et fait appel à un vrai compilateur, pas un traducteur de niveau d'assembleur (le C, c'est juste au dessus du HIR, voire du MIR... :p ) ; alors à moins de se planter monstrueusement dans l'algo (mais à ce moment-là, ce n'est pas la faute au langage), ce qui reste plus difficile sur un typage fort (dès que l'on a oublié quoi que ce soit, c'est jetage immédiat par le compilo), c'est déjà une bonne réponse. Ensuite, si je prends un langage solide aux erreurs et très éprouvé dans des applications critiques comme l'Ada, là encore, c'est très bien. D'ailleurs, comment fait-on exploser une fusée en 12 lignes de code Ada ? Et bien on mets un pragma pour désactiver la détection du joli integer overflow juste en dessous... Bref, retomber dans des schémas typiques du C, sans filet. Maintenant, il vaut mieux parfois qu'un programme plante bien comme il faut plutôt que faire n'importe quoi ; mais là encore, une bonne gestion des exceptions n'est pas compliquée, il suffit de savoir programmer (alors qu'en C, bein, y'a pas, alors forcément...).
Maintenant, je suis le premier à dire que le Unchecked_Conversion de l'Ada est une erreur : en donnant accès à la mémoire et à un cast non contrôlé (c'est même plus que ça, avec son ami for 'address...), c'est la porte à toutes les absurdités atroces qui est grande ouverte ; il faut toujours partir du principe que peu savent bien coder, et que pourtant ils se retrouvent à écrire des horreurs, parce qu'il faut bien que quelqu'un s'y colle, c'est tout.
Bref, programmer en C n'apporte vraiment rien, je me range totalement du côté de Dijkstra sur ma pensée. Programmer au sens noble de l'informatique n'est pas se préoccuper de ce qu'il y a dans la mémoire, même s'il est bon de le savoir (attention, je parle d'algorithmie, qu'on n'aille pas dire que je soutiens les machins ignobles du genre Java...). Pour ma part, je fais du temps réel/embarqué, j'ai donc peu l'occasion de travailler en haut niveau, mais là encore, un langage comme Ada est très bien (mieux : il est fait pour), et un OS en Caml a été écrit (je rappelle que Caml est aussi rapide que le C à l'exécution...), nul besoin donc de syntaxe abominable ou de système d'include/preprocessing à la noix du C.
L'exemple de la boucle for d'ailleurs est très parlant : déjà parce que for et while ne sont pas identique suivant ce que l'on a à faire (le compilo pourrait choisir le plus rapide des deux, mais non...), ensuite parce que i++ et ++i ne sont pas identiques, question de parallélisme du pipeline à l'intérieur du cpu des instructions asm (et bien sûr, ça dépend du cpu, passionnant débat inutile pour savoir si l'on gagne un cycle ou pas, et qui donne lieu à une abondante littérature...) ; franchement, ce genre de chose, on n'en à rien à faire, c'est le boulot du compilo. Et un 'range en Ada, c'est quand même bien plus simple, esthétique, et sûr, y'a pas photo (et une récursivité finale en Caml, miam ! :) ).
Vala, vala, et si on me tente encore un peu, la prochaine fois je parle de programmation système sans me retenir, non mais :p (ou de comment faire un buffer overflow sans aucun warning du C, même avec tous les flags de détection, et ce grâce à une écriture préalable sur HP-UX, beark !).

4. Le Thursday 23 March 2006 à 09:20, par Jean-Damien

Salut, merci pour ce passage sur les programmeurs.
Ca va paraitre con, mais franchement, je me suis rendu compte que dans les languages que j'ai vu il y a toujours des 'astuces' pour que ce soit plus rapide, moins consommateur, algorithmiquement satisfaisant (Aaah... le goto - oups!), etc... A la fin on se retrouve expert dans un ou deux languages, et dans la masse pour les autres. On en vient souvent a faire des trucs sales /si/ on veut optimiser.
Reste les questions de consommation en tout genre et de fonctionnalités. C'est la qu'il faut bien choisir.
Donc je crois qu'on commence bien avant la programmation elle-meme: choix des outils, du language, le design. Puis: /bon codage/ (independant du language!). Apres c'est plus facile.
Tirer sur le C c'est facile. Je dis que tirer sur les autres aussi. Debat stérile par définition. Faut savoir ce qu'on veut faire. Le probleme est bien plus le programmeur que le language lui-meme.
J'ai vu des trucs sales en C++ et Java qui n'ont rien, mais rien du tout alors, a envier aux hacks du C, par example.
Et puis il y a les centaines d'autres languages que je ne connais pas -; et je me dis que parler de ca c'est se placer plus haut qu'on n'est.
Donc en fin de compte, c'est bien la préparation qui compte plus que la réalisation. Apres on rajoute une bonne dose d'expérience et SURTOUT on pense a bien documenter. Mais pas de bol: l'expérience ca ne se prépare pas. On l'a ou pas. D'ou la quantité dingue de code foireux qu'on trouve partout.

5. Le Thursday 23 March 2006 à 10:11, par MadCoder :: site

@palpatine:

Je n'ai jamais fait d'ADA, je ne peux pas en parler. Mais :

1. J'ai commencé ma thèse à l'INRIA, et je déjeunais souvent avec Xavier Leroy à midi, donc crois moi le caml, je connais _bien_. J'écris même des choses en caml (projects.aaege.net/mailto... ) parce que je sais que justement c'est un langage robuste et rapide (mais pas autant que le C, il faut compter un facteur 1.5 en moyenne).

2. le C++ est encore plus dangereux que le C.

3. N'importe quel compilo du monde optimise les récursions terminales.

Et ce que je dis, c'est que quelqu'un qui n'a pas la rigueur pour écrire un code C propre et correct, n'aura jamais la rigueur pour écrire un programme propre et correct quel que soit le langage.

Je ne dis pas que je ne partage pas ton avis sur la gestion de la mémoire, je dis qu'un bon programmeur devrait savoir faire du C correct. Donc tu enfonces des portes ouvertes, et tu n'as pas saisi le fond de mon article.

6. Le Thursday 23 March 2006 à 12:16, par Jean-Damien

Merci d'avoir rectifie le tir. Je suis d'accord.
JD.

7. Le Thursday 23 March 2006 à 19:04, par palpatine :: site

Bah en tout cas, je suis d'accord avec toi sur ces derniers points ^^ (à part que c'est "Ada", comme la comtesse, et que les bench du Caml poutrent vraiment leur maman, sérieux... Heu, le C optimise pas du tout la récursion terminale, et vu les effets de bords monstrueux que l'on peut faire, limite on ne lui en voudra pas trop ; idem pour Java, Ada, heu, presque tout le monde en fait >_<) ; toutes mes amitiés à m'sieu Leroy si tu le recroises, c'est mon Dieu :) (t'inquiètes que j'ai capté ton article et le fond de ta pensée, mais tout est un problème de point de vue ; j'ai ce genre de discussions 2 fois par semaine, avec des dotnettiens même, à présent, pour preuve que ça ne s'arrange pas -_-; ).

8. Le Thursday 23 March 2006 à 20:14, par MadCoder :: site

Tu es mal documenté.

gcc(1) :

-foptimize-sibling-calls
Optimize sibling and tail recursive calls.

Enabled at levels -O2, -O3, -Os.

9. Le Friday 24 March 2006 à 07:31, par palpatine :: site

Bien vu ; reste à savoir comment c'est détecté et géré (et à quel point c'est stable...)

10. Le Friday 24 March 2006 à 10:26, par MadCoder :: site

bah, t'es mauvaise langue. Réfléchis à ce que veut dire un appel récursif terminal en terme de pile, et tu comprendras normalement tout seul que ce que le compilo (et c'est ce que fait caml aussi) optimise, c'est qu'il ne construit pas de nouveau cadre de pile lors d'un appel récursif. Ce qui fait que dépiler les appels ne se fait pas, il ne dépile que le premier.

Ce genre d'optimisation, tu peux le faire dans tout langage qui ne fait pas *trop* de trucs pendant un appel. Ce qui fait que je ne suis par exemple pas certain que ça soit aussi faisable en C++. Ça parait aussi un peu subtil à marier avec alloca.

11. Le Saturday 25 March 2006 à 00:29, par palpatine :: site

Évidemment que je suis de mauvaise langue ! ^^ Le truc, c'est que -O3 n'est de toute façon pas très stable, reste donc le -O2, qui lui marche fort bien, mais moins bien optimisé, logiquement ; quand on en est au MIR, une façon simple d'optimiser est de switcher des instructions afin de paralléliser et de simplifier, mais encore faut-il tenir compte des effets de bord éventuels. C'est là que l'on voit l'importance de la grammaire, de la même manière qu'un switch est plus optimisé qu'une structure de pointeurs sur fonction : le but est d'être assez expressifs pour que le compilateur puisse travailler en toute connaissance de cause. Or, comme tu le dis, il faut pas qu'il fasse "trop" de choses au milieu, à savoir des effets de bords ; quiconque a déjà fait une lecture de fichier en argument d'un appel de fonction en C/C++ sait que ça peut être fatal (le joli exam bien planté à cause de ça :D ) ; l'allocation de mémoire (hé hé, un fan d'alloca ? ;) ) fait partie de ces choses-là, au même niveau que C et C++ (parce qu'il n'y a franchement pas tant de différence que ça ; on peut même faire de la généricité en C, avec quelques macros et '##', mais faut avoir le coeur bien accroché :s ), le problème étant qu'on s'en bouffe dans tous les sens dans ces langages. Je suis plus tranquille lorsque je crée un arbre en 3 lignes de Caml que lorsque j'ai une usine à gaz en C (l'Ada est pareil, pour la peine, décevant -_-; ). À part ça, quand j'ai fait mon shell (équivalent à un bash sans les fioritudes), l'arbre n-aire était codé en dur, et mon parseur était entièrement récursif (tout comme l'exécution), c'est juste que 400 lignes pour faire un parseur (je ne compte pas le lexeur, c'est un pote qui s'en est occupé de toute façon), ça fait 10 fois plus qu'en Caml, tout en étant beaucoup plus sujet à bugs (comparaisons de chaînes, copies en mémoire, allocation/désallocation, etc), et même si le Valgrind était tout bon (parce que sinon, c'était 0 au proj' :p ), bah c'était bien laid, avec les macros de typage au milieu >_< (faut bien connaître le token reconnu... Le Caml et l'Ada sont tellement plus propres...).
Au fait, en récursivité terminale, il me semble bien que Caml déroule tout simplement sous la forme itérative, un appel de fonction, c'est tout de même coûteux (sauvegarde des registres...) ; à ce propos, la pile du C est immonde (et dire que l'Ada en hérite -_-; ), ne pas oublier de mettre foo(void) et pas foo() tout court, sinon ça se comporte comme une va_args, qui en soit est un des hacks les plus merdouilleux qui soit >_<.
En plus tu l'as dis toi-même (dans THE super trop bon billet ;) ), la programmation, c'est un art :). Moi, j'adore le baroque :p.

12. Le Tuesday 4 April 2006 à 01:20, par Krunch :: site

En C++ il paraitrait qu'on a plutôt tendance à utiliser ++i car lorsque cet opérateur est surchargé il ne nécessite pas de copier un objet contrairement à i++ qui va devoire copier l'objet, "incrémenter" l'objet puis retourner la copie.

Par ailleurs j'ai récemment testé -foptimize-sibling-calls pour la récursion terminale et j'obtenais le même code avec ou sans (mais j'ai peut-être raté quelque chose quelque part et je ne me souviens plus de mon test exact).

13. Le Tuesday 4 April 2006 à 08:14, par MadCoder :: site

-foptimize-sibling-calls est par défaut dans -O2 ...

et il ne *faut pas* overloader ++.

14. Le Tuesday 4 April 2006 à 15:33, par Krunch :: site

Je n'aime pas particulièrement le C++ mais surcharger ++ a l'air d'être une pratique courante pour les itérateurs (et ça serait bête de s'en priver).

Bon ben après quelques tests, -foptimize-sibling-calls tout seul n'optimise rien du tout mais -O2 tient bien compte de la récursion terminale (GCC 4.0.1).

Ajouter un commentaire