Guillaume Laurent a écrit 1148 commentaires

> Il ne faut pas s'étonner quand on apprend que ximian a imposé à Eazel le C alors qu'ils avaient déjà commencé en C++

C'est inexact.

Le premier proto de Nautilus qui a ete presente aux principaux developpeurs Gnome avant meme qu'Eazel annonce publiquement son existence etait bien en C++ et utilisait Gtk--. Ces developpeurs (pas seulement Ximian) ont fait comprendre a Eazel qu'un composant aussi important de Gnome ecrit en C++ passerait mal au sein de la communaute.

Par ailleurs, le proto etait aussi tres gourmand en ressources (je ne me souviens pas dans quelle mesure, je sais que c'etait ameliorable mais je ne sais pas a quel point).

Ils ont donc tout repris en C, et ainsi perdu 3 mois de developpement.

> La programmation Objet n'est qu'une approche plus ou moins réussi de l'appréhension du monde par les humains.

Non, c'est l'evolution naturelle de la programmation structuree, de la meme facon que celle-ci est l'evolution de if/goto.

Des que tu commences a manipuler des structs et des fonctions, tot ou tard les bases de la POO vont apparaitre.


> Par contre, si je veux faire un calcul distribué, à quoi me sert l'approche objet ?

A organiser un peu mieux ton code.

Ah, dans ce cas on est d'accord :-).

> Bha les modules Linux sont programmés en C non ?

Oui, et alors ?

> En ce qui concerne les systèmes embarqués "légers", bien souvent le microcontrolleur ne posséde pas la memoire suffisante pour coder en objet.

Si tu as la place pour une struct et des fonctions associees, tu as la place pour un objet.

> En utilisant le type string et les vector<>, tu occulte des choses trés importante, au nivo de la gestion de la memoire par exemple.

Dans la majorite des cas tu n'as rien a foutre de ce genre de details.
Il vaut mieux avoir quelques bases sur malloc/free, juste pour savoir que ca existe et comment s'en servir si tu es oblige, et utiliser des classes (ou carrement un langage) qui ne te fasse pas chier avec, plutot que de s'empetrer dedans et de croire qu'on ne peut pas programmer sans.

Il y a deja assez de jeunes couillons scleroses dans le C comme ca, pas la peine d'en former d'autres.

> D'autre par, comme tu le sait certainement le C++ n'est rien d'autre qu'un bricolage (proche du #define) au dessus du C

Cliche aussi :-).

> Dans bien des cas, la programmetion objet n'est pas indispensable

Rien n'est indispensable, juste plus ou moins utile.

> (programmation système, systèmes embarqués "légers"...).

Non, on peut faire ca en POO (on le fait meme assez souvent je crois), c'est tres bien aussi.

> La programmation C++ necessite en outre un apprentissage de la conception objet

Pas forcement... S'en servir simplement comme d'un C avec un type vector<> et un type string en plus, c'est deja une immense amelioration.

En plus pour apprendre la POO, le C++ n'est vraiment pas le meilleur choix.

> Une dernière remarque globale sur le fait de ne pas acheter de logiciels : un logiciel est une idée, je ne vois pas comment on arrive à vendre des idées.

Qu'il est mignon le petit... guiliguiliguili, fait risette a tonton Stallman :-).

> - les 127 Mo de mémoire pris par un seul process

A tout hasard, je te signale que la taille memoire du process d'un serveur X, telle qu'elle est reporte par 'ps', inclu la RAM de ta carte graphique.

Tu veux sans doute parler de

http://kt.zork.net/kde/kde20010420_7.html#2(...)

T'as lu trop vite, ou pas jusqu'au bout. :-)

A propos, il y a quelques temps dans une autre news, quelqu'un avait demande l'ajout du scoring sous KMail. C'est fait, ca n'est pas dans cette release, mais ca sera dans la la prochaine, et donc dans la 2.2 finale.

OK, tu veux juste parler de la simple redefinition d'une methode. Rien ne t'oblige a la declarer virtual, si tu n'as pas besoin du polymorphisme. Ton appel de methode est alors strictement equivalent a un appel de fonction.

Et tout ca n'a rien a voir avec un pointeur sur une fonction membre, ca c'est encore autre chose :-).

> Si je ne me trompe pas, inline est juste une directive au compilo [...]

Pour autant que je sache, c'est exact. Et je suis d'accord, un programmeur fait le plus souvent de mauvais inlines. D'ailleurs la plupart du temps on recommande de n'inliner qu'apres profiling (sauf evidemment, comme tu le dis, les trucs triviaux genre accesseurs).

J'ignorais qu'il y avait encore des boites qui fournissaient des compilos C++ qui compilent vers C, a part pour maintenir un vieux produit dont certains clients peuvent encore avoir besoin.

Sinon oui, compiler du C++ en passant par C, c'est completement obsolete.

> Il faut voir le C++ comme une série de Macro évoluées au dessus du C.

Oh la belle fortune pour le bas de page de linuxfr :-).

> Savoir l'utiliser, c'est forcement programmer en objet, et je doute que le dynamic binding puisse etre aussi rapide que le static binding.

Tu peux faire de l'objet avec du static binding (mais pas du polymorphisme), et C++ sait tres bien faire ca (de tout les langages OO c'est meme lui qui sait le mieux le faire).

Par ailleurs, un appel a une methode virtuelle c'est juste un dereferencement de plus. Negligeable dans 99% des cas.

> inline: Encore un truc qui ne devrait etre que l'affaire du compilateur plutot que d'un programmeur

Vieux debat. Ca ne fait pas tres longtemps qu'on sait faire des compilos qui savent bien quand inliner, et c'est pas du tout facile a faire. Alors deja qu'un compilo C++ c'est complexe, si en plus il fallait rajouter ca... Quoique il me semble que certains le font plus ou moins (je crois que rien n'oblige le compilo a effectivement inliner ce que tu specifies "inline", c'est juste un indice, pas un ordre).

>Va peut-être falloir que tu relise ton C++.

Toi aussi :-).

> (vu que ton C++ est traduit en C avant compilation).

Ca fait bien quelques siecles que ce genre de compilos n'existe plus. Tous les compilos actuels generent directement de l'assembleur.

> Par contre pour l'apprentissage, c'est la misère (gérer le inline, le volatile).

Le volatile ? Tu veux parler des methodes virtuelles peut-etre ?

Leur recommandation est parfaitement sensee. Si tu files au manager moyen un portable sous Linux, il ne va pas en faire grand chose. Avec W2k il peut bosser tranquille, et en plus ca marche tres bien (j'ai ca au boulot, un mois d'uptime sans pbs).

IBM pousse Linux sur les serveurs, pas sur le desktop, ca serait suicidaire (pour l'instant).

Meuh non, suffit de commencer a lire par le bas :-)

> la configuration d'une connexion adsl

Qu'est-ce qu'elle a leur config ADSL ?

> des scripts a la cons qui te bloquent ta machine pour un rien !!!!!! (regarde ce qui marche a 2-4h lit le code et rigole bien fort !!!)

En general il y a un update de la db locate et une verif de l'etat du systeme (nouveaux fichiers en world write, et ports IP ouverts). N'importe quel sysadmin sera tres content d'avoir ca sous la main des l'install. Et si ca pose un pb, n'importe quel newbie lobotomise est encore capable de les disabler en moins de 30 secondes.

Donc ou est le probleme ?

Si, il en a au moins un : que la plupart des produits Open Source ne sont pas systematiquement testes. Il a aussi raison quand il dit que l'argument "given enough eyes, all bugs are shallow" ne remplace pas un code review systematique fait pas des gens competent et payes pour ca.

Il n'y a qu'OpenBSD qui soit une exception. Sinon, il n'y a qu'a voir le nombre de trous causes par des buffer overflow stupides qui sont rapportes regulierement.

Maintenant, il est clair que les editeurs Closed Source ne font pas mieux. Quand un produit est en retard (ce qui arrive 99% du temps), on compresse ce qui est compressible : le code review (quand il y en a) est en general le premier a passer a la trappe. Par ailleurs, il n'est pas dit non plus qu'il soit fait pas des gens qui s'y connaissent en securite (en general il est fait par des programmeurs lambda que ca fait copieusement chier, donc ils baclent).

A tout prendre, l'Open Source est clairement plus sur a long terme, mais l'etat actuel des choses n'est pas brillant non plus.

s/light/life

Sinon ca fait un peu ridicule :-).

Excellent. Je vais l'ajouter en reference, merci beaucoup :-).

Tres interessant, d'ailleurs dans l'intro on peut lire : "It is clear that the techniques presented here have not the pretension to replace C++ or Objective C". Et juste avant, que ces techniques s'adressent à ceux qui n'ont pas de compilo C++ pour leur plateforme, ou à ceux qui sont déçus des compilos C++ actuels (mais franchement, je préfère encore un mauvais compilo C++ qu'utiliser les techniques décrites).

De nos jours pour du gros developpement, j'irais sous Java direct, sinon C++.

Je ne pretend pas avoir la science infuse, je suis un codeur experimente, quant au diktat du tout OO, il n'existe plus que dans les cours de quelques profs d'infos integristes, le reste du monde en est revenu depuis longtemps.

Par ailleurs je serais curieux de savoir en quoi mon article te semble vouloir imposer un tel diktat, d'autant que je critique les extremistes de l'OO au debut. Et j'ai deja repondu tout a l'heure a quelqu'un qui preferait Ruby pour son cote "tout OO" qu'il se trompait.

Dans la mesure ou le but de l'article est precisement d'expliquer en quoi ce raisonnement est absurde, je vois pas ce que je peux ajouter.

Tout l'article tente d'expliquer pourquoi l'OO n'est pas que "pour faire beau", que repondre a quelqu'un qui arrive en disant "l'OO c'est que pour faire beau" ? A part en rire, je ne vois pas.

OK, en plus de dire "t'as rien compris", j'aurais du rajouter "relis l'article", mais bon, si la premiere fois ca n'a pas marche, est-ce vraiment utile de retenter une seconde passe ?