Un peu comme les plaintes puériles à propos des votes et des XP.
Tu peux aussi te demander pourquoi tu en reçois... apparemment là il y a abus d'après le modéro, mais je n'aurais pas été surpris que tu en reçoives autant, et de manière complètement justifiée...
« Et moi je ne vois pas ce qu'il y'a de pas clair dans ce que j'explique. Comme je l'ai déjà dit, il y'a pleins de bonne raisons pour ne pas mettre d'objet dans la pile et pour toutes ces bonnes raisons ce n'est pas la méthode normale pour allouer des objets. »
Et moi je ne sais pas où tu as lu qu'il n'y avait pas de telles raisons.
« Utiliser la pile pour les types primitifs absolument je suis entièrement d'accord mais pour des objets non ou alors quand vraiment le besoin de performance se fait sentir. Là, il y a un bouquin de C++ que tu dois brûler ou des personnes dont il faudrait arrêter d'écouter les conseils... Sérieusement. »
Je crois que tu ajotues beaucoup de choses à ce que j'ai dit (en supprimant les nuances que je pense pourtant bien avoir ajoutées la plupart du temps). En particulier puisque tu parles d'objet de grande taille par exemple :-/
Je ne réponds pas sur le reste parce que je suis plutôt d'accord (ta comparaison avec les audits de C++ et Java ne me surprend pas quand du dynamique est utilisé (et il y en a forcément)). Quant à Java il ne s'agit pas de le dénigrer, je l'apprécie aussi ; et de manière très classique, dans un projet, si ses inconvénients ont finalement peu d'importance, ça fait un excellent choix. On s'est retrouvé à parler de Java mais ce n'était pas mon propos, je parlais juste de certains aspects trop souvent « sous-utilisés » de C++ (dont par exemple l'utilisation indirecte de mémoire dynamique en la « cachant » par des conteneurs en automatique -- note bien que ça ne veut pas dire que toutes les données se retrouvent sur la pile)
« La norme ISO presente un interet! Mais pas question de s'y limiter pour le C.
Quant a Java, s'il faut creer une norme, ce n'est surement pas parce qu'elle existe pour le C. S'il faut la creer, c'est dans un besoin de normaliser Java, c'est tout. »
Tout à fait.
« Au vu d'autres post precedents de ta part, je prefere te laisser me dire ou j'ai pu "croire lire ca" alors que "ce n'etait pas dit".
Et si ca doit degenerer en querelle de vocabulaire comme ca (...) »
C'est pas du tout mon intention, on a pu mal se comprendre, et ça peut être de ma faute. Les forums web ont quelques inconvénients par rapport à Usenet, quelques citations auront manqué, ou auront été mal interprétées.
« Seulement si la JVM avait ete libre. A moins que je ne me trompe, ni Perl ni Python ne sont ISO. Pourtant, personne ne dira le contraire quand je dis qu'ils sont tres utilises dans le libre!
Que Java soit ISO est par contre un plus.»
Exact. Le problème avec Java est (était ?) qu'un implémenteur ne pouvait pas reprendre le nom de « Java » sans que Sun vérifie la conformité. Il ne s'agit donc pas que ce soit ISO, je suis d'accord, c'est plus large que ça.
« Trop limite pas en fournisseurs, mais en qualite chez les autres fournisseurs. (...) »
Oui, c'est bien dans ce sens là que je disais ça.
« Pourquoi ce "huh" ?
Qui es-tu pour me dire "Je ne sais pas ce que tu as imaginé mais il ne s'agit que de ça, et tu reconnais toi-même le problème" ?
A nouveau, danakil, si t'as des reproches a me faire ou des attaques directes, tu n'auras aucun mal a trouver mon mail sur le net. »
Aucun reproche ni attaques directe, il y a un truc sur lequel on s'est mal compris (peut-être de ma faute, je n'ai plus le thread en tête et j'ai la flemme de relire -- ça n'en vaut surtout pas le coup). Le « huh? » est juste une onomatopée de surprise... et je ne vois pas ce que tu as mal pris dans le reste (le "qui es-tu pour me dire..." ), en tous cas il ne fallait pas -- si je comprends bien, tu l'as lu comme si je parlais sur un ton de "donneur de leçon", je faisais juste remarquer qu'il y avait forcément méprise quelque part, n'y vois rien d'autre.
« Pardon mais, faire du C purement ISO ca veut dire n'utiliser que les mot-clés du C pour vous ? Vous avez fumé ou quoi ?
Il me semble que l'ISO specifie le langage, et il n'interdit pas d'utiliser des librairies. »
Libs qui ne seront pas ISO, et pas forcément portable, donc pour être plus précis, leur remarque est correcte au sens strict, mais pour aller dans le sens que tu dis, on aura par exemple un noyau d'appli parfaitement ISO et des portions dépendantes de bibliothèques présentes et non ISO. Comme tu le dis, il ne s'agit pas que d'utiliser la définition du langage.
(suite)
...mmh remarque, si tu emploies "scandaleux" pour qualifier un avis politique différent et qui ne te va pas, le terme convient bien sûr. C'est juste qu'il semblait faire référence à une atteinte à quelque chose de naturel ou de fondamental. Alors que ce n'est que politique.
Ensuite tu le qualifies comme tu veux...
...Par contre tu as raison de réagir sur le mot pile, je n'aurais pas dû le reprendre, c'est trompeur. Le but est que l'utilisateur se serve de variables automatiques, mais bien sûr des données vont quand même se retrouver en mémoire globale via les conteneurs (par exemple). Mais là la désallocation interne sera fiable.
Quand on argumente, qu'on discute, on pense avoir raison, c'est comme ça. Et puis si on se trompe, si on est convaincu par quelqu'un d'autre, on change d'avis, c'est plutot constructif.
Sur ce thread ci il y a plusieurs points sur lesquels on est finalement d'accord.
Maintenant, si tu « penses » que j'ai tort, sans dire pourquoi, ça ne m'avance pas beaucoup, contrairement aux réponses argumentées qui peuvent mener à quelque chose.
Évidemment si pour toi répondre et discuter c'est « polémiquer », il n'y a que les réponses AOL qui vont te convenir... Pour ce qui est de discuter sans répliquer, le concept semble curieux aussi...
« Oui, mais ce n'est certainement pas car la loi les en empeche en mettant le fruit de leur travail potentiel en libre acces. »
La propriété n'existant pas de manière naturelle, l'inexistance de certains aspects du droit d'auteur ne serait pas « empêcher » quoi que ce soit.
« Que les gens doivent pour certains faire un boulot qui leur plait pas c'est une chose, que la loi les empeche de faire un boulot qui leur plait c'est autre chose. »
La loi ne l'empecherait pas.
« Oui, et qu'est ce qui rapporte de l'argent aux auteurs ? L'achat de copies. »
L'achat de copies, qui n'est qu'une partie des revenus, ne serait pas interdit. D'ailleurs malgré la disponibilité de quasiment tout illégalement, les fans continuent d'acheter les artistes qu'ils apprécient. Les autres sources de revenu ne sont pas modifiées.
« Tant que c'est une action volontaire ca me gene pas, mais nombre de gens ici veulent enlever le droit des artistes a gagner leur vie en vendant leur musique, c'est de ca dont je parles. »
Je n'ai vu que des souhaits de libérer (ie autoriser la copie libre) les oeuvres d'art, mais aucun souhait d'enlever le droit de vendre ou de gagner sa vie.
« Il y a plein de gens ici qui ont justement parle de ce "droit a la culture" sense justifier l'acces gratuit aux creations d'autrui. »
Bien sûr, c'est certainement défendable. Par contre l'interdiction de vendre, tu l'as inventée.
« Nope justement, pour moi un artiste c'est la meme chose qu'un developpeur, obliger les softs a etre en GPL serait pour moi scandaleux, qu'on laisse le choix aux auteurs. »
Ca ne le serait pas en cas de redéfinition de la propriété intellectuelle. Celle-ci pourrait être automatiquement publique. C'est une décision politique réformant une chose qui n'a rien de naturel, et qui n'irait pas contre la liberté et l'égalité (je dirais le contraire en fait), serait appliquée sans discrimination, etc. Tu es juste contre comme on est pour ou contre une politique, celle-ci ne contient rien de scandaleux.
« La seule chose que je veux, c'est qu'on laisse au createur le soin de decider de qui peut profiter de son oeuvre et comment, qu'il le mette en libre acces si il a envie, ou qu'il demande 3 sacrifices de jeunes vierges si il le veut, c'est son choix. »
C'est un point de vue politique. Pas plus "naturel" qu'un autre comme tu as l'air de le penser. De quel droit fondamental le créateur irait-il interdire toutes ces choses à d'autres ? C'est un privilège que notre système lui a donné, rien de plus.
« Non, comme je le disais ce n'est pas la méthode normale. »
Là il y a un bouquin de C++ que tu dois brûler ou des personnes dont il faudrait arrêter d'écouter les conseils... Sérieusement.
« En général on instancie pas d'objets sur la pile, le heap est parfaitement adapté comme espace utilisateur, d'autant que question sécurité utiliser la pile ce n'est pas vraiment terrible. »
Ce n'est « en général » que si on s'obstine à appliquer en C++ des habitudes venant de C ou de Java. Sinon c'est à éviter quand on fait du C++. L'instanciation dont tu parles, dans la mémoire globale (et pas dans le heap, a priori, même si le compilo peut faire comme ça) n'est pas plus adaptée, juste plus coûteuse. Et évidemment amène les risques liés aux pointeurs. C'est un peu facile de ne pas prendre la solution normale proprosée par le langage, et ensuite de se plaindre des difficultés liées à une solution plus compliquée et contenant plus de risques, mais que tu a décidé d'utiliser.
« D'ailleurs, Java ne place que des références sur la pile et jamais d'objets (ok pas pour les même raisons mais bon ... C# n'alloue jamais d'objets sur la pile non plus). »
Ben c'est pas une référence puisque ces langages offrent moins de types de mémoire possibles. Je vois mal comment Java pourrait mettre autre chose que des références sur la pile puisque la durée de vie des objets n'est pas liée aux blocs... c'est normal vu les contraintes du langage.
« Oui il y'a une raison qui est liée au conteneur, si je me souviens bien, on ne peut pas mettre des objets d'une classe de base et des objets de la classe dérivé dans ce conteneur (je ne me souviens plus la raison) ce qui implique qu'on utilise des pointeurs. Et là notre problème de libération mémoire se pose. »
C'est parce qu'une copie est effectuée, qui va copier dans le type de base, enfin je suppose. Mais tu te places aussi dans un cas où des références plutot que des pointeurs ne conviennent pas, et où la libération des pointeurs poserait problème (contrairement à une utilisation généralisée de pointeurs, là on sait plus facilement où regarder). Boost propose aussi des pointeurs intelligents qui supportent la copie (donc la SL aussi)...
« Oui bien sûr avec un exemple tel que celui-là (qui est décidement mal choisi), on peut utiliser la pile mais bon (cf quelques lignes plus haut). »
Mais bon, t'as décidé de ne pas faire comme ça, ça me parait être la principale raison.
« C'est un pattern justement ;-). Je trouve que c'est un bricolage parce que pour disposer de tous les avantages du java (...) »
Tous les avantages de Java ? C'est une curieuse manière de voir les choses quand tant de choses sont supprimées et que l'on n'a plus le choix. L'avantage c'est juste qu'il y a un ramasse-miettes ; qu'il soit obligatoire n'en est pas forcément un.
Le GC est une solution qui peut convenir, ce n'est pas la solution qui corrige des difficultés du C++. Une solution digne de ce nom ne dégrade pas.
« je me souviens d'un papier de Stroustrup parlant d'un GC pour C++ preuve que même son créateur est conscient que c'est une fonctionnalité qui manque. »
Et ? Le fait que ça manque veut seulement dire que l'ajout des possibilités d'un GC serait un plus. Et ça parait évident. Mais il ne s'agit que d'un ajout, pas d'un remplacement... heureusement, en particulier puisque C++ possède des choses plus efficaces et simples, qu'il serait néfaste de supprimer (choix fait dans Java).
« Le comportement n'est pas différent d'un new en C++ à la différence que ce n'est pas au programmeur de se soucier de l'élimination de l'objet. »
Que le programmeur n'ait pas à s'en soucier, c'est l'avantage. Que ce soit « comme un new en C++ », c'est là l'inconvénient. En C++ justement on cherche à les éviter. C'est quand même bien porc de taper dans la mémoire dynamique quand on peut utiliser de l'automatique...
« Oui mais dès que tu as besoin d'instancier des classes tu utilises l'opérateur new et donc l'allocation dynamique (oui on peut parfaitement utiliser la pile et non la heap mais la pile n'est pas vraiment faite pour les objets donc on fait rarement de cette façon). On fait de l'objet ne l'oublions pas donc l'objectif est d'utiliser des classes. »
Et tu les utilises très bien avec de la mémoire automatique, c'est la méthode normale, faire du dynamique c'est uniquement si on ne peut pas faire autrement. La pile convient très bien.
« Pour reprendre mon exemple, mes comptes ce sont évidemment des objets (ce n'était peut-être pas très clair) qui contiennent des informations relatives à chaque compte et à chaque nouveau compte récupéré j'instancie mon objet compte que je place dans un vector (de pointeurs à cause des objets que je mets dedans) »
C'était clair que c'était des objets, mais tu ne dis pas pourquoi tu utilises des pointeurs, ce n'est pas une obligation. Rien ne t'empêche de mettre tes objets nouvellement créés directement dans ton vector, sans passer par des pointeurs. Ou alors il y a une raison qui t'en empeche, mais celle-là tu ne l'as pas explicitée.
« Compte *l_compte = new Compte;
l_compte->changerProprietaire(nom);
//d'autres trucs ici
delete l_compte;
Si ma fonction lève une exception je ne passe pas au niveau du delete et mon pointeur n'est jamais libéré. »
{
Compte l_compte() ;
l_compte.changerProprietaire(nom);
// d'autres trucs ici
}
Que cette manière de faire ne convienne pas toujours, ok, mais dans le cas de ton exemple, je ne vois rien qui l'empeche.
« Tu inclus d'ailleurs dans ton raisonnement l'utilisation de pointeurs intelligents comme un "best pratice" pour faire du code sûr mais tout ça ce n'est en quelque sorte que du "bricolage" par rapport à ce qui est fait en Java ... c'est un peu comme dire qu'on peut faire de l'objet en C ... oui on peut mais ce n'est pas spécialement pensé pour. C'est la même chose avec le C++. »
Un pointeur intelligent là ou on pouvait utiliser de la mémoire automatique, c'est pas une « best practice » :) , à moins d'être très à l'aise avec ces derniers, personnellement j'éviterais. Les pointeurs intelligents je ne les indiquais que comme possibilités à envisager, j'insistais beaucoup plus sur la mémoire automatique. Ca ne parait vraiment pas plus « bricolage » qu'un « design pattern » quelconque, qu'un ramasse-miette, ou d'autres choses, le tout est de connaître l'outil qu'on utilise.
« Des variables ont des portées de bloc ou de méthode en Java aussi, elle n'ont pas le même scope et les variables locales sont aussi détruites en fin de bloc donc en ça, Java a aussi une gestion de la mémoire automatique. Java n'utilise pas de pointeurs mais des références et le new n'empêche pas de disposer d'une mémoire automatique. »
Ma question c'est : ces variables locales peuvent-elles être des instances de classe, et alors leur constructeur et la libération de mémoire est-elle faite à la fin du bloc ? Évidemmnent si j'ai parlé de pointeurs en Java il s'agit de références, ça va sans dire...
« Et c'est tellement farfelu que je trouve que c'est un drole d'argument que de dire que Java n'est pas ISO alors que C l'est. »
Si pour toi une norme publique ne présente aucun intérêt, c'est pas étonnant...
« Et par ailleurs, utiliser le C en ne voulant respecter que la norme ISO, bah, euh, c'est ce que je disais, on ne peut rien faire!!! »
C'est bien tu l'as déjà dit. Même réponse : l'intérêt de la norme ne se trouve pas dans la création de programmes purement ISO.
« Par ailleurs, un truc que je n'ai pas aborde plus haut: pourquoi se limiter au fait que C soit ISO et pas Java ? Si c'est Perl le langage le plus adapte a ce qu'on veut faire, Je trouve aussi mauvais de dire "Java n'est pas le bon langage parce que Java n'est ISO" que de dire "il faut utiliser C parce que C est ISO". »
Et ? Évidemment, mais je n'ai pas dit le contraire dans la remarque initiale. Si on exclue Java parmi un ensemble de solutions, ce sera en raison d'un ensemble d'arguments. Qui a dit que C était forcément la solution qui s'imposait quand on veut un langage ISO ? Voilà encore une chose farfelue que tu as cru lire et qui n'était pas dite.
« On s'en fiche, que ce soit ISO. Ce qui compte, c'est d'utiliser le langage le mieux adpte au besoin. »
L'idéal serait de ne pouvoir prendre en compte que des considérations techniques évidemment. Le fait que ce ne soit pas ISO est un inconvénient qui s'ajoute éventuellement, c'est un problème indépendant du reste. Mais ça a des conséquences sur les outils, si Java avait été ISO et la JVM libre, le LL l'aurait bien plus utilisé, il y aurait plus de choix, plus de portabilité. Parce que Java est une option intéressante ou à envisager si on fait abstraction du coté proprio. Mais actuellement l'offre en outils est trop limitée (en diversité, Sun fournit beaucoup mais je parle de plusieurs fournisseurs) par rapport aux autres langages.
« (...) la norme Java qui n'est pas une vraie norme (a moins que je ne sois mal renseigne) mais qui est definie par les specs de java (entre les mains de SUN - ce serait bien qu'un groupe independant en aie la maitrise). »
Huh? Mais tu exprimes là exactement le reproche que l'on fait quand on regrette que Sun possède tout et que la norme ne soit pas ISO. Je ne sais pas ce que tu as imaginé mais il ne s'agit que de ça, et tu reconnais toi-même le problème. Problème qui ne sera pas forcément suffisant pour écarter systématiquement Java et lui préférer un langage comme C ou C++, mais c'est juste un argument parmi d'autres, qui apporte sa contribution dans un choix...
« Si on regarde la norme ANSI/ISO pour le C, on ne fait pas grand chose avec. Il est tout simplement impossible de faire un programme qui fasse un minimum de choses interessantes avec uniquement du code ISO en C. »
Avoir une norme c'est s'interdire d'utiliser d'autres normes, des bibliothèques, etc ? Personne n'a dit ça, c'est même assez farfelu comme idée.
(je pense que ça répond à toute la suite du post, dont une phrase importante est « une norme Java (que malheureusement Sun definit selon son bon vouloir) » puisque le problème est là)
Ce n'est pas toi qui décide pour les autres ce qui leur convient ou non, en particulier l'aspect libre a son importance si on le souhaite. Et Java est un problème dans ce cas, que tu le veuilles ou non.
Il va de soi que pour quelqu'un qui veut du Java, cette distrib ne pose aucun problème, et convient même plutot bien. Donc je ne vois pas l'interet de cette intervention, ce n'est pas la question.
« Ce n'est pas du tout ce que j'ai dit ou voulu dire. Je ne vois pas comment tu es arrivé à une telle conclusion. »
En tant que réponse à ce que je disais, ça me parait la seule interprétation, c'est pour ça que je le soulignais, je me doute bien que tu ne le penses pas.
Relis bien : je suis d'accord avec ce que tu dis là sur le fait qu'un installeur/gestionnaire proprio est moins grave que des outils de développement proprio s'il faut faire un choix entre ces deux alternatives. Mais il n'y a aucune obligation de faire ce choix : on peut se passer de Java même si Java est installé, et ce sur toute distrib. Par contre on ne peut pas se passer de certains outils comme l'installeur ou le gestionnaire de paquets (ou alors c'est qu'on refait sa distrib).
Je suis d'accord avec ce que tu dis dans ton post là, mais c'est une considération sur des outils qu'on va utiliser, ce n'est plus le même problème que la question initiale ou on compare des aspects propriétaires de distribs, et où on ne va pas forcément utiliser les outils proprio. Tu fais une remarque sur les outils, tandis qu'il s'agissait d'une remarque sur les distribs et là la différence change tout !
L'auto_ptr a des limitations, il faut les connaitre. Un plus gros problème est qu'on ne peut pas les utiliser dans les conteneurs standard.
Tu insistes beaucoup sur les pointeurs intelligents, mais ce n'est pas à ça que je pensais, j'en ai parlé comme solution à envisager si on a besoin de mémoire dynamique, mais je pensais surtout à privilégier la mémoire automatique, et utiliser des références, pas des pointeurs. Ca peut paraitre évident, mais c'est une habitude trop peu répandue (surtout si on a fait du C avant).
Je ne suis pas trop d'accord avec ton exemple de liste avec vector ou autre conteneur : du moins dans l'exemple que tu donnes, on peut tout faire en mémoire automatique. Je ne dis pas qu'il n'y a pas de cas avec vector où il faut utiliser de la mémoire dynamique (avec des pointeurs dans le vecteur par exemple), mais on peut quand même souvent s'en passer. Et en plus la mémoire automatique est plus rapide, et tout se passe bien avec les exceptions...
Je suis bien d'accord que dès qu'il y a de la désallocation explicite à faire, les fuites sont quasi-inévitables. Mais je parle justement d'utiliser des méthodes qui ne nécessitent pas la désallocation : mémoire automatique surtout, pointeurs intelligents s'il faut du dynamique, et dynamique sans pointeurs intelligents en dernier recours, ce qui réduit considérablement les endroits où il y a des désallocations à faire. (Et je ne suis pas d'accord si tu dis que la mémoire automatique c'est laisser au programmeur la gestion de la mémoire. Quand on utilise des pointeurs oui, mais là ce n'est pas le cas)
Si mes souvenirs sont bons, Java ne propose pas de mémoire automatique, on passe toujours par un new ? Si c'est bien le cas, ça me paraît abusif de dire que Java corrige un problème de C++, parce que c'est en partie supprimer quelque chose d'utile et qui ne posait pas de problème. Mais je peux me tromper sur ce point, ou ça a peut-etre été introduit depuis ma dernière utilisation...
« Tiens, 3 personnes qui moinssent, pas une seule qui ose dire pourquoi... >
Sans doute parce que c'était pas la peine de crier de manière aussi agressive. Enfin je dis ça, j'aurais surement moinssé pour cette raison si le post avait été visible. Ca te fait une explication, qui n'a rien d'un « pas d'accord » (en fait je suis plutot d'accord, la remarque sur le possessif n'est pas justifiée, surtout en langue anglaise qui l'utilise bien plus).
Dans ta remarque tu fais comme si les choses avaient toujours été comme ça, comme si on regardait uniquement à un instant donné. Il est évident que la remarque en question évoque une évolution des choses. Ce que toi et Daganf répondez demande d'oublier volontairement ce point important.
Donc d'après toi s'il y a Staroffice et Java de Sun sur une distrib, on ne peut pas s'en passer. On ne peut pas utiliser une alternative, on est obligé de s'en servir. Évidemment pour les gens comme ça, mieux vaut que ce soit l'installeur qui soit proprio. Mais je ne parlais pas de ces cas non réalistes (et c'était explicite).
Le problèlme que peut poser Sun Java en tant que langage proprio est bien sûr le même quelle que soit la distribution, existe pour toutes celles qui le proposent, et sur toute distrib 100% libre aussi si on l'installe.
« Hum ... soit j'ai du mal comprendre soit cet argument n'a aucun sens »
C'est ta question qui n'a pas de sens, plus précisément c'est le mot « mieux » qui n'a pas de sens (simplification abusive). Donc la réponse à la première question c'est que tu as mal compris.
« Sans être _la_ solution, Java a quand même permis d'éviter quelques petits pièges du C++ comme par exemple la gestion de la mémoire »
Encore faut-il être compétent en C++. Je ne pense pas l'être assez et je me débrouillerais donc mieux en Java qu'en C++ de ce point de vue, mais quelqu'un qui maîtrise le C++ saura éviter bien des problèmes de mémoire parce qu'il fait du code propre et non du « C avec des classes ». Même sans parler d'utiliser les smart pointers de boost, rien qu'en utilisant bien la bibltiohèque C++ et en n'utilisant de la mémoire dynamique qu'en dernier recours, on évite bien des pièges. Beaucoup de gens n'utilisent pas assez ce qu'a apporté C++, c'est compréhensible pour plein de raisons, mais ça fausse la comparaison à mon avis.
# Re: "modération" des gens qui abusent.
Posté par #3588 . En réponse au journal "modération" des gens qui abusent.. Évalué à 10.
Un peu comme les plaintes puériles à propos des votes et des XP.
Tu peux aussi te demander pourquoi tu en reçois... apparemment là il y a abus d'après le modéro, mais je n'aurais pas été surpris que tu en reçoives autant, et de manière complètement justifiée...
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
Et moi je ne sais pas où tu as lu qu'il n'y avait pas de telles raisons.
« Utiliser la pile pour les types primitifs absolument je suis entièrement d'accord mais pour des objets non ou alors quand vraiment le besoin de performance se fait sentir. Là, il y a un bouquin de C++ que tu dois brûler ou des personnes dont il faudrait arrêter d'écouter les conseils... Sérieusement. »
Je crois que tu ajotues beaucoup de choses à ce que j'ai dit (en supprimant les nuances que je pense pourtant bien avoir ajoutées la plupart du temps). En particulier puisque tu parles d'objet de grande taille par exemple :-/
Je ne réponds pas sur le reste parce que je suis plutôt d'accord (ta comparaison avec les audits de C++ et Java ne me surprend pas quand du dynamique est utilisé (et il y en a forcément)). Quant à Java il ne s'agit pas de le dénigrer, je l'apprécie aussi ; et de manière très classique, dans un projet, si ses inconvénients ont finalement peu d'importance, ça fait un excellent choix. On s'est retrouvé à parler de Java mais ce n'était pas mon propos, je parlais juste de certains aspects trop souvent « sous-utilisés » de C++ (dont par exemple l'utilisation indirecte de mémoire dynamique en la « cachant » par des conteneurs en automatique -- note bien que ça ne veut pas dire que toutes les données se retrouvent sur la pile)
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
Sauf que tu ne veux pas lire la remarque dans le contexte de départ, mais dans celui que tu souhaites lui coller. Et là bien sûr ça n'a pas de sens.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
Quant a Java, s'il faut creer une norme, ce n'est surement pas parce qu'elle existe pour le C. S'il faut la creer, c'est dans un besoin de normaliser Java, c'est tout. »
Tout à fait.
« Au vu d'autres post precedents de ta part, je prefere te laisser me dire ou j'ai pu "croire lire ca" alors que "ce n'etait pas dit".
Et si ca doit degenerer en querelle de vocabulaire comme ca (...) »
C'est pas du tout mon intention, on a pu mal se comprendre, et ça peut être de ma faute. Les forums web ont quelques inconvénients par rapport à Usenet, quelques citations auront manqué, ou auront été mal interprétées.
« Seulement si la JVM avait ete libre. A moins que je ne me trompe, ni Perl ni Python ne sont ISO. Pourtant, personne ne dira le contraire quand je dis qu'ils sont tres utilises dans le libre!
Que Java soit ISO est par contre un plus.»
Exact. Le problème avec Java est (était ?) qu'un implémenteur ne pouvait pas reprendre le nom de « Java » sans que Sun vérifie la conformité. Il ne s'agit donc pas que ce soit ISO, je suis d'accord, c'est plus large que ça.
« Trop limite pas en fournisseurs, mais en qualite chez les autres fournisseurs. (...) »
Oui, c'est bien dans ce sens là que je disais ça.
« Pourquoi ce "huh" ?
Qui es-tu pour me dire "Je ne sais pas ce que tu as imaginé mais il ne s'agit que de ça, et tu reconnais toi-même le problème" ?
A nouveau, danakil, si t'as des reproches a me faire ou des attaques directes, tu n'auras aucun mal a trouver mon mail sur le net. »
Aucun reproche ni attaques directe, il y a un truc sur lequel on s'est mal compris (peut-être de ma faute, je n'ai plus le thread en tête et j'ai la flemme de relire -- ça n'en vaut surtout pas le coup). Le « huh? » est juste une onomatopée de surprise... et je ne vois pas ce que tu as mal pris dans le reste (le "qui es-tu pour me dire..." ), en tous cas il ne fallait pas -- si je comprends bien, tu l'as lu comme si je parlais sur un ton de "donneur de leçon", je faisais juste remarquer qu'il y avait forcément méprise quelque part, n'y vois rien d'autre.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
Il me semble que l'ISO specifie le langage, et il n'interdit pas d'utiliser des librairies. »
Libs qui ne seront pas ISO, et pas forcément portable, donc pour être plus précis, leur remarque est correcte au sens strict, mais pour aller dans le sens que tu dis, on aura par exemple un noyau d'appli parfaitement ISO et des portions dépendantes de bibliothèques présentes et non ISO. Comme tu le dis, il ne s'agit pas que d'utiliser la définition du langage.
[^] # Re: Pour ceux qui sauraient pas
Posté par #3588 . En réponse à la dépêche Le développeur principal d'xMule poursuivi en justice. Évalué à 1.
...mmh remarque, si tu emploies "scandaleux" pour qualifier un avis politique différent et qui ne te va pas, le terme convient bien sûr. C'est juste qu'il semblait faire référence à une atteinte à quelque chose de naturel ou de fondamental. Alors que ce n'est que politique.
Ensuite tu le qualifies comme tu veux...
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
[^] # Re: Juge t on un logiciel pour son usage ?
Posté par #3588 . En réponse à la dépêche Le développeur principal d'xMule poursuivi en justice. Évalué à 2.
Sur ce thread ci il y a plusieurs points sur lesquels on est finalement d'accord.
Maintenant, si tu « penses » que j'ai tort, sans dire pourquoi, ça ne m'avance pas beaucoup, contrairement aux réponses argumentées qui peuvent mener à quelque chose.
Évidemment si pour toi répondre et discuter c'est « polémiquer », il n'y a que les réponses AOL qui vont te convenir... Pour ce qui est de discuter sans répliquer, le concept semble curieux aussi...
[^] # Re: Pour ceux qui sauraient pas
Posté par #3588 . En réponse à la dépêche Le développeur principal d'xMule poursuivi en justice. Évalué à 1.
La propriété n'existant pas de manière naturelle, l'inexistance de certains aspects du droit d'auteur ne serait pas « empêcher » quoi que ce soit.
« Que les gens doivent pour certains faire un boulot qui leur plait pas c'est une chose, que la loi les empeche de faire un boulot qui leur plait c'est autre chose. »
La loi ne l'empecherait pas.
« Oui, et qu'est ce qui rapporte de l'argent aux auteurs ? L'achat de copies. »
L'achat de copies, qui n'est qu'une partie des revenus, ne serait pas interdit. D'ailleurs malgré la disponibilité de quasiment tout illégalement, les fans continuent d'acheter les artistes qu'ils apprécient. Les autres sources de revenu ne sont pas modifiées.
« Tant que c'est une action volontaire ca me gene pas, mais nombre de gens ici veulent enlever le droit des artistes a gagner leur vie en vendant leur musique, c'est de ca dont je parles. »
Je n'ai vu que des souhaits de libérer (ie autoriser la copie libre) les oeuvres d'art, mais aucun souhait d'enlever le droit de vendre ou de gagner sa vie.
« Il y a plein de gens ici qui ont justement parle de ce "droit a la culture" sense justifier l'acces gratuit aux creations d'autrui. »
Bien sûr, c'est certainement défendable. Par contre l'interdiction de vendre, tu l'as inventée.
« Nope justement, pour moi un artiste c'est la meme chose qu'un developpeur, obliger les softs a etre en GPL serait pour moi scandaleux, qu'on laisse le choix aux auteurs. »
Ca ne le serait pas en cas de redéfinition de la propriété intellectuelle. Celle-ci pourrait être automatiquement publique. C'est une décision politique réformant une chose qui n'a rien de naturel, et qui n'irait pas contre la liberté et l'égalité (je dirais le contraire en fait), serait appliquée sans discrimination, etc. Tu es juste contre comme on est pour ou contre une politique, celle-ci ne contient rien de scandaleux.
« La seule chose que je veux, c'est qu'on laisse au createur le soin de decider de qui peut profiter de son oeuvre et comment, qu'il le mette en libre acces si il a envie, ou qu'il demande 3 sacrifices de jeunes vierges si il le veut, c'est son choix. »
C'est un point de vue politique. Pas plus "naturel" qu'un autre comme tu as l'air de le penser. De quel droit fondamental le créateur irait-il interdire toutes ces choses à d'autres ? C'est un privilège que notre système lui a donné, rien de plus.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 0.
D'un bouquin de de C ou de Java ;-)
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
Là il y a un bouquin de C++ que tu dois brûler ou des personnes dont il faudrait arrêter d'écouter les conseils... Sérieusement.
« En général on instancie pas d'objets sur la pile, le heap est parfaitement adapté comme espace utilisateur, d'autant que question sécurité utiliser la pile ce n'est pas vraiment terrible. »
Ce n'est « en général » que si on s'obstine à appliquer en C++ des habitudes venant de C ou de Java. Sinon c'est à éviter quand on fait du C++. L'instanciation dont tu parles, dans la mémoire globale (et pas dans le heap, a priori, même si le compilo peut faire comme ça) n'est pas plus adaptée, juste plus coûteuse. Et évidemment amène les risques liés aux pointeurs. C'est un peu facile de ne pas prendre la solution normale proprosée par le langage, et ensuite de se plaindre des difficultés liées à une solution plus compliquée et contenant plus de risques, mais que tu a décidé d'utiliser.
« D'ailleurs, Java ne place que des références sur la pile et jamais d'objets (ok pas pour les même raisons mais bon ... C# n'alloue jamais d'objets sur la pile non plus). »
Ben c'est pas une référence puisque ces langages offrent moins de types de mémoire possibles. Je vois mal comment Java pourrait mettre autre chose que des références sur la pile puisque la durée de vie des objets n'est pas liée aux blocs... c'est normal vu les contraintes du langage.
« Oui il y'a une raison qui est liée au conteneur, si je me souviens bien, on ne peut pas mettre des objets d'une classe de base et des objets de la classe dérivé dans ce conteneur (je ne me souviens plus la raison) ce qui implique qu'on utilise des pointeurs. Et là notre problème de libération mémoire se pose. »
C'est parce qu'une copie est effectuée, qui va copier dans le type de base, enfin je suppose. Mais tu te places aussi dans un cas où des références plutot que des pointeurs ne conviennent pas, et où la libération des pointeurs poserait problème (contrairement à une utilisation généralisée de pointeurs, là on sait plus facilement où regarder). Boost propose aussi des pointeurs intelligents qui supportent la copie (donc la SL aussi)...
« Oui bien sûr avec un exemple tel que celui-là (qui est décidement mal choisi), on peut utiliser la pile mais bon (cf quelques lignes plus haut). »
Mais bon, t'as décidé de ne pas faire comme ça, ça me parait être la principale raison.
« C'est un pattern justement ;-). Je trouve que c'est un bricolage parce que pour disposer de tous les avantages du java (...) »
Tous les avantages de Java ? C'est une curieuse manière de voir les choses quand tant de choses sont supprimées et que l'on n'a plus le choix. L'avantage c'est juste qu'il y a un ramasse-miettes ; qu'il soit obligatoire n'en est pas forcément un.
Le GC est une solution qui peut convenir, ce n'est pas la solution qui corrige des difficultés du C++. Une solution digne de ce nom ne dégrade pas.
« je me souviens d'un papier de Stroustrup parlant d'un GC pour C++ preuve que même son créateur est conscient que c'est une fonctionnalité qui manque. »
Et ? Le fait que ça manque veut seulement dire que l'ajout des possibilités d'un GC serait un plus. Et ça parait évident. Mais il ne s'agit que d'un ajout, pas d'un remplacement... heureusement, en particulier puisque C++ possède des choses plus efficaces et simples, qu'il serait néfaste de supprimer (choix fait dans Java).
« Le comportement n'est pas différent d'un new en C++ à la différence que ce n'est pas au programmeur de se soucier de l'élimination de l'objet. »
Que le programmeur n'ait pas à s'en soucier, c'est l'avantage. Que ce soit « comme un new en C++ », c'est là l'inconvénient. En C++ justement on cherche à les éviter. C'est quand même bien porc de taper dans la mémoire dynamique quand on peut utiliser de l'automatique...
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 0.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
Et tu les utilises très bien avec de la mémoire automatique, c'est la méthode normale, faire du dynamique c'est uniquement si on ne peut pas faire autrement. La pile convient très bien.
« Pour reprendre mon exemple, mes comptes ce sont évidemment des objets (ce n'était peut-être pas très clair) qui contiennent des informations relatives à chaque compte et à chaque nouveau compte récupéré j'instancie mon objet compte que je place dans un vector (de pointeurs à cause des objets que je mets dedans) »
C'était clair que c'était des objets, mais tu ne dis pas pourquoi tu utilises des pointeurs, ce n'est pas une obligation. Rien ne t'empêche de mettre tes objets nouvellement créés directement dans ton vector, sans passer par des pointeurs. Ou alors il y a une raison qui t'en empeche, mais celle-là tu ne l'as pas explicitée.
« Compte *l_compte = new Compte;
l_compte->changerProprietaire(nom);
//d'autres trucs ici
delete l_compte;
Si ma fonction lève une exception je ne passe pas au niveau du delete et mon pointeur n'est jamais libéré. »
{
Compte l_compte() ;
l_compte.changerProprietaire(nom);
// d'autres trucs ici
}
Que cette manière de faire ne convienne pas toujours, ok, mais dans le cas de ton exemple, je ne vois rien qui l'empeche.
« Tu inclus d'ailleurs dans ton raisonnement l'utilisation de pointeurs intelligents comme un "best pratice" pour faire du code sûr mais tout ça ce n'est en quelque sorte que du "bricolage" par rapport à ce qui est fait en Java ... c'est un peu comme dire qu'on peut faire de l'objet en C ... oui on peut mais ce n'est pas spécialement pensé pour. C'est la même chose avec le C++. »
Un pointeur intelligent là ou on pouvait utiliser de la mémoire automatique, c'est pas une « best practice » :) , à moins d'être très à l'aise avec ces derniers, personnellement j'éviterais. Les pointeurs intelligents je ne les indiquais que comme possibilités à envisager, j'insistais beaucoup plus sur la mémoire automatique. Ca ne parait vraiment pas plus « bricolage » qu'un « design pattern » quelconque, qu'un ramasse-miette, ou d'autres choses, le tout est de connaître l'outil qu'on utilise.
« Des variables ont des portées de bloc ou de méthode en Java aussi, elle n'ont pas le même scope et les variables locales sont aussi détruites en fin de bloc donc en ça, Java a aussi une gestion de la mémoire automatique. Java n'utilise pas de pointeurs mais des références et le new n'empêche pas de disposer d'une mémoire automatique. »
Ma question c'est : ces variables locales peuvent-elles être des instances de classe, et alors leur constructeur et la libération de mémoire est-elle faite à la fin du bloc ? Évidemmnent si j'ai parlé de pointeurs en Java il s'agit de références, ça va sans dire...
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 3.
Si pour toi une norme publique ne présente aucun intérêt, c'est pas étonnant...
« Et par ailleurs, utiliser le C en ne voulant respecter que la norme ISO, bah, euh, c'est ce que je disais, on ne peut rien faire!!! »
C'est bien tu l'as déjà dit. Même réponse : l'intérêt de la norme ne se trouve pas dans la création de programmes purement ISO.
« Par ailleurs, un truc que je n'ai pas aborde plus haut: pourquoi se limiter au fait que C soit ISO et pas Java ? Si c'est Perl le langage le plus adapte a ce qu'on veut faire, Je trouve aussi mauvais de dire "Java n'est pas le bon langage parce que Java n'est ISO" que de dire "il faut utiliser C parce que C est ISO". »
Et ? Évidemment, mais je n'ai pas dit le contraire dans la remarque initiale. Si on exclue Java parmi un ensemble de solutions, ce sera en raison d'un ensemble d'arguments. Qui a dit que C était forcément la solution qui s'imposait quand on veut un langage ISO ? Voilà encore une chose farfelue que tu as cru lire et qui n'était pas dite.
« On s'en fiche, que ce soit ISO. Ce qui compte, c'est d'utiliser le langage le mieux adpte au besoin. »
L'idéal serait de ne pouvoir prendre en compte que des considérations techniques évidemment. Le fait que ce ne soit pas ISO est un inconvénient qui s'ajoute éventuellement, c'est un problème indépendant du reste. Mais ça a des conséquences sur les outils, si Java avait été ISO et la JVM libre, le LL l'aurait bien plus utilisé, il y aurait plus de choix, plus de portabilité. Parce que Java est une option intéressante ou à envisager si on fait abstraction du coté proprio. Mais actuellement l'offre en outils est trop limitée (en diversité, Sun fournit beaucoup mais je parle de plusieurs fournisseurs) par rapport aux autres langages.
« (...) la norme Java qui n'est pas une vraie norme (a moins que je ne sois mal renseigne) mais qui est definie par les specs de java (entre les mains de SUN - ce serait bien qu'un groupe independant en aie la maitrise). »
Huh? Mais tu exprimes là exactement le reproche que l'on fait quand on regrette que Sun possède tout et que la norme ne soit pas ISO. Je ne sais pas ce que tu as imaginé mais il ne s'agit que de ça, et tu reconnais toi-même le problème. Problème qui ne sera pas forcément suffisant pour écarter systématiquement Java et lui préférer un langage comme C ou C++, mais c'est juste un argument parmi d'autres, qui apporte sa contribution dans un choix...
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 2.
Avoir une norme c'est s'interdire d'utiliser d'autres normes, des bibliothèques, etc ? Personne n'a dit ça, c'est même assez farfelu comme idée.
(je pense que ça répond à toute la suite du post, dont une phrase importante est « une norme Java (que malheureusement Sun definit selon son bon vouloir) » puisque le problème est là)
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à -1.
Il va de soi que pour quelqu'un qui veut du Java, cette distrib ne pose aucun problème, et convient même plutot bien. Donc je ne vois pas l'interet de cette intervention, ce n'est pas la question.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 2.
En tant que réponse à ce que je disais, ça me parait la seule interprétation, c'est pour ça que je le soulignais, je me doute bien que tu ne le penses pas.
Relis bien : je suis d'accord avec ce que tu dis là sur le fait qu'un installeur/gestionnaire proprio est moins grave que des outils de développement proprio s'il faut faire un choix entre ces deux alternatives. Mais il n'y a aucune obligation de faire ce choix : on peut se passer de Java même si Java est installé, et ce sur toute distrib. Par contre on ne peut pas se passer de certains outils comme l'installeur ou le gestionnaire de paquets (ou alors c'est qu'on refait sa distrib).
Je suis d'accord avec ce que tu dis dans ton post là, mais c'est une considération sur des outils qu'on va utiliser, ce n'est plus le même problème que la question initiale ou on compare des aspects propriétaires de distribs, et où on ne va pas forcément utiliser les outils proprio. Tu fais une remarque sur les outils, tandis qu'il s'agissait d'une remarque sur les distribs et là la différence change tout !
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 2.
Tu insistes beaucoup sur les pointeurs intelligents, mais ce n'est pas à ça que je pensais, j'en ai parlé comme solution à envisager si on a besoin de mémoire dynamique, mais je pensais surtout à privilégier la mémoire automatique, et utiliser des références, pas des pointeurs. Ca peut paraitre évident, mais c'est une habitude trop peu répandue (surtout si on a fait du C avant).
Je ne suis pas trop d'accord avec ton exemple de liste avec vector ou autre conteneur : du moins dans l'exemple que tu donnes, on peut tout faire en mémoire automatique. Je ne dis pas qu'il n'y a pas de cas avec vector où il faut utiliser de la mémoire dynamique (avec des pointeurs dans le vecteur par exemple), mais on peut quand même souvent s'en passer. Et en plus la mémoire automatique est plus rapide, et tout se passe bien avec les exceptions...
Je suis bien d'accord que dès qu'il y a de la désallocation explicite à faire, les fuites sont quasi-inévitables. Mais je parle justement d'utiliser des méthodes qui ne nécessitent pas la désallocation : mémoire automatique surtout, pointeurs intelligents s'il faut du dynamique, et dynamique sans pointeurs intelligents en dernier recours, ce qui réduit considérablement les endroits où il y a des désallocations à faire. (Et je ne suis pas d'accord si tu dis que la mémoire automatique c'est laisser au programmeur la gestion de la mémoire. Quand on utilise des pointeurs oui, mais là ce n'est pas le cas)
Si mes souvenirs sont bons, Java ne propose pas de mémoire automatique, on passe toujours par un new ? Si c'est bien le cas, ça me paraît abusif de dire que Java corrige un problème de C++, parce que c'est en partie supprimer quelque chose d'utile et qui ne posait pas de problème. Mais je peux me tromper sur ce point, ou ça a peut-etre été introduit depuis ma dernière utilisation...
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
Sans doute parce que c'était pas la peine de crier de manière aussi agressive. Enfin je dis ça, j'aurais surement moinssé pour cette raison si le post avait été visible. Ca te fait une explication, qui n'a rien d'un « pas d'accord » (en fait je suis plutot d'accord, la remarque sur le possessif n'est pas justifiée, surtout en langue anglaise qui l'utilise bien plus).
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 4.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à -2.
Donc d'après toi s'il y a Staroffice et Java de Sun sur une distrib, on ne peut pas s'en passer. On ne peut pas utiliser une alternative, on est obligé de s'en servir. Évidemment pour les gens comme ça, mieux vaut que ce soit l'installeur qui soit proprio. Mais je ne parlais pas de ces cas non réalistes (et c'était explicite).
Le problèlme que peut poser Sun Java en tant que langage proprio est bien sûr le même quelle que soit la distribution, existe pour toutes celles qui le proposent, et sur toute distrib 100% libre aussi si on l'installe.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 3.
C'est ta question qui n'a pas de sens, plus précisément c'est le mot « mieux » qui n'a pas de sens (simplification abusive). Donc la réponse à la première question c'est que tu as mal compris.
[^] # Re: SUN annonce Mad Hatter
Posté par #3588 . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
Encore faut-il être compétent en C++. Je ne pense pas l'être assez et je me débrouillerais donc mieux en Java qu'en C++ de ce point de vue, mais quelqu'un qui maîtrise le C++ saura éviter bien des problèmes de mémoire parce qu'il fait du code propre et non du « C avec des classes ». Même sans parler d'utiliser les smart pointers de boost, rien qu'en utilisant bien la bibltiohèque C++ et en n'utilisant de la mémoire dynamique qu'en dernier recours, on évite bien des pièges. Beaucoup de gens n'utilisent pas assez ce qu'a apporté C++, c'est compréhensible pour plein de raisons, mais ça fausse la comparaison à mon avis.