Posté par bleh .
En réponse au journal Coup de g....
Évalué à 9.
Si si y'a de très bons passages très drôles comme celui-là par exemple :
Certaines susnommées "moules" sont des professionnels de l'informatique, travaillant depuis des années au sein des plus grands groupes internationaux, et ayant pour client les plus grandes entreprises françaises... Je fais personnellement partie de l'une des plus grandes entreprises informatiques mondiales, et mes clients sont principalement les grandes industries françaises aéronautiques... Je ne développe pas des sites web pour la cousine de la secrétaire du voisin...
Il est atrocement réducteur de vouloir faire croire que les gens qui poussent le logiciel libre sont des fanatiques élevés à l'assembleur, au coca et à la pizza...
Et sincèrement, étant donné les orientations actuelles de la plupart des professionnels, il serait peut-être temps de changer de discours, celui-ci devient franchement suicidaire...
Il est vrai que sur LinuxFR, de nombreux trolls et réflexion hâtives circulent. Mais en lisant avec attention les commentaires, on trouve aussi des réflexions poussées d'experts dans les domaines abordés, où l'on apprend beaucoup plus que dans la plupart des magazines... D'ailleurs, certains magazines relaient facilement ces trolls et autres, avec en plus un mois de retard...
Guillaume a effectivement raison en ce qui concerne le coût de concaténation d'une string en java. Un simple coup d'oeil au bytecode montre que Java utilise des stringbuffers pour la concaténation et si ce procédé est bien plus rapide que celui qui était utilisé avant (création d'une nouvelle string à chaque concaténation car les strings sont "immutable"), il n'empêche que ça reste un procédé très couteux :
- StringBuffer est un tableau d'une taille défini par défaut à 16 caractères et chaque "append()" peut potentiellement povoquer une "expansion" du tableau d'origine avec les couts d'un appel à arraycopy().
- Le principe d'expansion du StringBuffer est assez rudimentaire, en gros doublement de la capacité initiale à chaque fois ce qui fait que pour une simple String on peut avoir un espace mémoire assez conséquent utilisé.
- On crée toujours 2 objets, un procédé qui reste couteux en Java.
Bref, au niveau lisibilité ce n'est pas forcement terrible et ça reste couteux. Personnellement je pense qu'un printf() pourrait être intéressant.
Ce que fait Java, le C++ le fait. Ce que fais le C++ (class dérivée de plusieurs class) surcharge, java ne le fait pas.
L'héritage multiple en tant que tel n'existe pas en java parce que ça pose plus de problèmes que ça n'en résouds. Tu as tout de suite des problèmes de nommage qui t'oblige à revoir ton design (les solutions avec une hierarchie en diamant). La solution pour l'héritage multiple en Java c'est les interfaces. Quant à la surcharge des opérateurs, elle manque un peu c'est vrai.
un langage plus OO et plus dynamique est plus approprie
Expliques toi !
C++ a un typage statique. L'objective-C a un typage dynamique. Le polymorphisme est aussi plus naturel en Objective-C parce il n'y a pas besoin de spécifier que l'édition de liens est dynamique.
Baser tout sur Java, en disant: "On recommence tout", ca me parait improductif pour rester poli.
Je suis tout à fait d'accord avec toi (si si :-). Mais globalement c'est une sorte d'effet de mode, j'entends dire la même chose à propos du mainframe, du COBOL etc depuis longtemps. On ne répetera jamais assez que pour chaque usage il y'a un langage adapté.
Sans rancunes?
Bien sûr ! Je suis en vacance, la vie est belle ! :+)
Maintenant pour l'argument. Un mec qui vient du C, qui se palluche la mémoire, les pointeurs dès le départ parce qu'il n'a pas d'autre choix est largement plus poilu qu'un gentil developpeur Java qui vit dans son monde de bisounours. Il est sensibilisé au système dès le départ. Point.
Qui a dit le contraire ? Un programmeur C est confronté au problème de la mémoire dès la phase de programmation et le dev Java s'en soucie moins pendant cette même phase, c'est une évidence. En revanche, il est clairement obligé de le prendre en compte pendant les phase de tests et d'optimisation (les memory leaks existent aussi en Java). En ça il est sensibilisé au problème et une bonne connaissance de la structure mémoire de la JVM est indispensable.
Autre chose, par exemple, les conteneurs Java ne sont pas tous thread-safe et les programmeurs Java doivent toujours prendre en compte l'aspect multi-thread dans le choix de ces conteneurs. La mémoire joue ici aussi un rôle important puisque certains conteneurs sont très rapides en lecture et écriture mais induisent la création d'index pour accelerer les accès et peuvent donc poser des problèmes lorsque les collections contiennent une grande quantité d'objets. Les OutOfMemoryException ce n'est pas seulement dans les cauchemards.
Bref ce que je te reproche c'est de sortir des lieux communs sur Java sans véritablement prendre en compte le fait que pour bien connaitre et utiliser Java il faut nécessairement comprendre les notions de threads, de mémoire et de processeur.
Les mecs en C sont plus balaises et ont une culture informatique largement plus étendues
Puisqu'apparemment l'expérience personnelle a ici valeur de preuve, je vais moi aussi y aller de mon expérience. Je travaille sur les parties backend d'un gros projet J2EE, en gros MQseries, Moniteur transactionnel CICS, DB2 etc. Je cotoie donc 2 mondes :
- Celui des programmeurs COBOL capables de te dire la différence de réprésentation mémoire entre S9(4) COMP et S9(4). Je fais partie de ces gens-là aussi puisque j'ai écris des programmes COBOL.
- Celui des devs Java pour qui les notions d'encapsulation, d'objet sont importantes. J'en fais aussi partie puisque comme je le disais j'ai écris la partie Java de connexion MQ, d'envoi et de création des messages.
Et bien, il n'y a pas pour moi de grosses différence de culture entre ces 2 mondes. Pour la simple et bonne raison que aucun des devs Java n'a fait que du Java dans sa vie de programmeur. Et bien que j'ai quitté le monde des écoles d'ingénieurs depuis un petit bout de temps, je ne crois pas que les étudiants n'apprennent que du Java durant leurs études.
Je crois moi que tu as une culture "bas niveau" et que donc tu "idolatres" les programmeurs C parce qu'il correspondent à ta conception de l'informatique, c'est un droit mais laisse moi douter de ton objectivité lorsque tu parles des dev Java.
"Ha ouais, super, J2EE et tout. On va prendre ce FrameWork de la mort qui tue et on va leur montrer aux minus d'UNIX comment qu'on fait des applis pour les end-user...". Désolé ça m'énerve.
Le serveur d'application IBM WebSphere fonctionne très bien sous AIX ... je vois vraiment pas où tu as pu entendre ça. D'autant que ça ne veut presque rien dire J2EE c'est plutôt du client/serveur avec des conteneurs et il n'y a pas de notions purement "Unix" équivalente . Java et Unix ne sont pas antinomique. OK Java a mauvaise presse du coté de Linux pour des raisons de licence mais IBM contribue à améliorer Java pour les plateformes Unix.
Finalement si les gens prenaient le temps de connaitre vraiment les technos, on aurait probablement une meilleure collaboration à tous les niveaux, entendre "Haha on va leur expliquer la mémoire à ces tapettes de programmeurs Java ..." c'est énervant aussi.
Tous les mecs que j'ai rencontré faisant du Java sont des non-techniciens (threads, mutex, IPC, sockets, POSIX ? "connais pas")
Franchement c'est à mourir de rire. Heureusement que les dev java connaissent ce genre de notions, ne serait-ce que pour utiliser un pattern singleton thread-safe. Et les "synchronized" ça sert à quoi d'après toi ?
D'autant que les notions dont tu parles existent en Java exepté les IPC (bien qu'il soit possible d'en émuler le comportement en se débrouillant avec des sockets), je te conseille d'aller jeter un coup d'oeil au package java.net., tu seras etonné de voir ce qu'on y trouve.
La plupart des gens qui utilisent Java ont oublié la notion de processeurs ou de mémoires (Procéquoi ? Memqui ?)
Mais bien sur ! Est-ce que tu as déjà été sur un projet java sérieux ? L'optimisation en Java est clairement basée sur l'optimisation de l'utilisation mémoire, le cycle du garbage est vital pour avoir des performances correctes idem pour le comportement de la heap (les paramètres -Xms et -Xmx sont par exemple importants).
L'existance en Java d'un garbage collector fait que la libération des ressources est moins problématique mais cela reste tout de même une préoccupation majeure. Et d'ailleurs, le fait que des logiciels tels que OptimizeIt de Borland ou JProbe existent montre que les notions de processeurs et de mémoire ne sont clairement pas oubliées.
Tu as raison de mettre "connaissances de base en Java" sur ton cv. Lire ce genre de conneries ça me gacherait presque mes vacances :-)
Franchement on s'en fout un peu que les autres s'y mettent ou pas. Ce qui compte c'est qu'il existe un standard.
A quoi sert un standard si il n'est utilisé que par un IM ? A rien. Après on peut effectivement se féliciter que ça soit le protocole Jabber qui ait été choisi mais finalement ça n'apporte pas grand chose. Donc non on s'en fout pas un peu que les autres s'y mettent pas.
Peut-être qu'ils sont audités par Anders^H^H^H^H^Hccenture, qui sait.
Pour info, Accenture ne fait pas d'audit. Accenture était la branche conseil d'Andersen sous le nom d'Andersen consulting et cette branche s'est séparé (comme pour PWC qui a vendu sa filière conseil à IBM) en 1999. L'audit et le controle de gestion c'est (était) Arthur Andersen.
Tu vas te faire des copains du coté des banques ...
Franchement, le COBOL II est clairement le meilleur langage de gestion. Les structures COBOL sont largement mieux foutues que dans d'autres langages, le mode étendu, le COMP, le COMP-3 sont extrêmement utiles et lorsqu'on doit s'amuser à passer des messages avec MQSeries on est content que le mapping soit fait simplement grâce au mode étendu (idem pour le signe avec trailing-separate).
C'est amusant cette dictature des langages. En dehors du C/C++/java point de salut, un peu comme une mode. L'objet n'est pas adapté pour tous les usage et dans la série langage mal fichus, le C s'impose aussi (tout programmeur normalement constitué admettra que la gestion des chaines de caractères en C est pourrie). Alors le cobol a encore de beaux jours devant lui.
C'est une bonne chose que les étudiants voient d'autres langages pour leur culture personnelle et aussi pour le fait que ces langages ne sont pas aussi confidentiels que certains aimeraient le croire.
Je lit un sujet "Sortie de KOffice 1.3", et vient se greffer dessus un deuxième message: "Microsoft n'est pas malhonnête, Windows c'est bien".
Parce que comme d'habitude ici, il y'a quelqu'un pour se pointer dans un thread et dire "Microsoft est malhonnête, Windows c'est pas bien". C'est un grand classique de linuxfr et comme d'habitude pBpG est obligé de rétablir la vérité en apportant des faits. je ne vois pas où est le problème ... si on ne lisait pas autant de conneries ici, il n'aurait probablement jamais rien à dire sur MS. Et puis, contrairement à ce que tu crois pBpG participe aussi sur d'autre sujet, je me souviens particulièrement d'une discussion sur Java où il avait participé (et pas pour parler de Microsoft).
Bref, tout n'est pas aussi simple que tu sembles le croire.
Et l'idée que Microsoft ai "placé" quelqu'un sur un site comme linuxfr, n'est pas si absurde que ça.
Non, elle est complètement débile. Franchement, MS n'a absolument rien à faire de gens qui de toute façon dans leur grande majorité ne seront jamais convaincu par aucun produit Microsoft. Et si tu veux un argument supplémentaire lis ce commentaire : http://linuxfr.org/comments/337199.html(...)
Quelle belle URL, il y a quasiment une erreur par ligne
Oh la oui c'est merveilleux. Ne même pas prendre le temps de pas se planter sur le nom du créateur de CP/M (gary Kildall) ! Pour ceux qui veulent savoir un peu plus sur CP/M et le travail de Kildall :
à mon avis utiliser 50 développeurs n'est pas souvent une bonne idée car ils se mélangent souvent les pinceaux
J'espère que tu n'es pas sérieux quand tu dis ça ... Des gros projets d'industrie comptent des fois plus de 100 développeurs ! Une application peut être découpée en modules indépendant et developpés de manière indépendante par des équipes indépendantes. L'intégration se fait ensuite en phase de test et de prod. Encore heureux que les projets ne se limitent pas à 5 dev !
Oui et c'est pour ça que faire un try/catch et ensuite relancer une exception c'est encore plus couteux. Voilà pourquoi je disais que dans ce cas là, c'était bien utile d'avoir quelque chose qui fera le ménage sans que j'ai à utiliser des techniques immondes dans le style "try/catch puis throw de la même exception".
Comme le nom l'indique, ce n'est pas le but.
Qui a dit le contraire mais ça n'empêche qu'un programme doit avoir des exceptions et des méthodes pour les gérer.
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.
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:
- La pile n'est pas un espace mémoire immense et mettre des objets (et a fortiori gros) dans la pile c'est s'exposer à un risque de stack overflow.
- Le programme sauvegarde son contexte d'execution dans la pile et ça implique des problèmes de sécurité puisque la pile est "executable". Le buffer overflow ce n'est pas seulement dans mes cauchemars.
Et il y'a aussi les problèmes dans le cas de programme multithreadé que j'avais oublié (merci pBpG). La pile n'est pas vraiment un espace thread-safe et effectivement on peut arriver à des résultats rigolos.
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.
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.
Bien bien ok toi tu utilises la pile mais d'autres personnes non (sûrement des mauvais programmeurs) et dans ces cas là le problème se pose, tu peux retourner le problème dans tous les sens mais ça reste toujours la même chose : la gestion mémoire n'est pas simple et est source d'erreur (dans la vraie vie, dans les programmes des entreprises mais pas dans les tiens ok).
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.
Elle ne dégrade pas au contraire. Bon, sérieusement, j'ai fait de l'audit de code C++, j'en fais aussi (Java cette fois-c)i actuellement pour la boite ou je travaille et clairement le nombre de memory leaks est bien plus élevé dans le programme C++ que dans ce programme Java. Le GC est à mon avis plus efficace que des désallocations manuelles. En ça c'est une bonne solution, permettre d'avoir des programmes plus fiables c'est tout de même le plus important.
Pour finir, j'aprécie le C++ et ses qualités mais je l'ai assez pratiqué pour savoir qu'il a des défauts, que Java corrige entre autre. Après on peut se mettre la tête dans le sable et tout nier en bloc mais c'est un fait et probablement qu'un jour un langage corrigera les erreurs du Java. C'est tant mieux, c'est ça l'évolution.
Tu met le tout dans un try qui intercepte toutes les exceptions, si une exception survient tu libère ton pointeur et tu relance l'exception telle quelle.
Bof, on peut effectivement faire comme ça mais ce n'est pas très joli et question perf ce n'est pas terrible non plus.
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.
Non, comme je le disais ce n'est pas la méthode normale. La pile n'est pas seulement disponible pour les variables locales, elle sert aussi à sauver le contexte d'exécution, l'exemple que je donnais était simple (je ne vais pas écrire une classe de 2000 lignes pour un exemple) mais supposons que j'utilise _beaucoup_ d'objets dans ma méthode, là le risque de dépassement est clair. 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. 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).
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.
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.
{
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.
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). Eventuellement si on veut à tout prix utiliser la pile on peut mettre un pointeur sur la pile mais finalement ça revient au même vu qu'on sera tout de même obligé de supprimer le pointeur pour éliminer l'objet.
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.
C'est un pattern justement ;-). Je trouve que c'est un bricolage parce que pour disposer de tous les avantages du java il faut bien choisir son pointeur intelligent (auto_ptr ne fonctionne pas avec la STL par exemple) et que ça crée des dépendances supplémentaires, bref c'est contraignant tout simplement parce que le langage n'a pas été prévu pour. 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.
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 ?
Ok je n'avais pas compris. Quand on instancie un objet dans une méthode, la référence est effectivement libérée à la fin du bloc mais l'objet lui est toujours en mémoire et attends d'être éliminé par le GC. 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. Pour les autres variables (types primitifs), comme je le disais, le système est le même qu'en C++, elles sont détruites en fin de bloc.
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).
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. Dès que tu utilises des objets tu es pratiquement obligé de renoncer à la mémoire automatique et la desallocation se fait à la main. Si j'ai insisté sur les pointeurs intelligents c'est parce que ça montre un besoin de la part des programmeurs d'avoir un système de gestion mémoire automatique (ce que possède Java).
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
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) à des fins d'affichage, dans ce cas on est d'accord j'utilise bien la mémoire dynamique et là si on place des objets compte chèque et compte titre qui sont dérivés de compte on doit effectuer le nettoyage à la main. On pourrait trouver des dizaines d'exemples du même type.
Et en plus la mémoire automatique est plus rapide, et tout se passe bien avec les exceptions...
Oui je suis d'accord mais avec cet exemple là :
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é.
(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)
Loin de moi l'idée de dire que des variables automatiques sont gérées par le programmeurs (quand même ! ;-), pour les pointeurs oui on est d'accord mais là où je ne suis pas d'accord c'est que ce n'est pas aussi simple que ça de ne pas utiliser de pointeurs. 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++.
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...
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.
Bref, Java a clairement été conçu pour être un dérivé simplifié de C++ et pour corriger certain défauts dont la gestion de la mémoire mais ça n'enlève rien à la qualité du C++ (ça reste un bon langage que j'aprécie beaucoup) et son utilisation massive le prouve mais je pense sincèrement que le jour où les perfs en Java seront équivalente au C++ ce sera la fin du C++.
Même sans parler d'utiliser les smart pointers de boost, [...]
Je ne parlais pas de ceux de boost en particuliers, je me suis mal exprimé, je voulais parler des pointeurs intelligents en général (smartpointers ... mélanger le français et l'anglais dans un commentaire n'est pas une bonne idée) style auto_ptr de la lib standard. Il y'a surement d'autres implémentations de pointeurs intelligents mais j'avoue que je ne fais plus beaucoup de C++ et que je ne me tiens plus vraiment au courant.
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.
Qu'on implémente des pointeurs intelligents qui comptent les références sur eux montre bien que ce n'est pas aussi évident et que des fois ce n'est pas une question de maitrise du C++ : par exemple une méthode qui lève une exception et qui execute donc le code correspondant à la place du code prévu, des pointeurs qui pointent sur null ... ce genre de choses, sans compter les erreurs d'étourderie, qu'on ne peut pas toujours éviter bon codeur ou mauvais, font qu'un code n'a pas le comportement attendu. C'est un refrain connu le programmeur responsable qui alloue et désalloue la mémoire parfaitement sans jamais une erreur mais dans la vraie vie c'est rare ... très rare. Quant à utiliser l'allocation dynamique qu'en dernier recours c'est à mon avis très illusoire dès qu'on a besoin de conteneurs tels que vector ce qui est le cas dans beaucoup de programmes (voire la majorité), supposons que je souhaite aficher une liste de comptes rapatriés d'une base je suis clairement obligé d'allouer dynamiquement une liste, ce n'est qu'un exemple mais il y'en a des centaines dans les programmes.
Je suis d'accord avec toi pour dire que beaucoup de gens n'utilisent pas ce qu'a apporté le C++ mais ça n'enlève rien au fait que confier la gestion de la mémoire au programmeur n'est pas forcement une bonne idée et que justement Java corrige cette erreur (ça en induit d'autre comme par exemple quand la heap atteint le seuil de garbage collection trop vite et force le GC à s'executer dans des intervalles très courts ce qui impacte clairement la performance mais bon ce n'est pas le propos du thread). Pour moi le tort du C++ est clairement d'avoir voulu garder un rapport avec le C pour ne pas dépayser, Java a su au moins rompre l'héritage en utilisant un GC.
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 ou de simplifier certaines notions de l'objet comme le polymorphisme. Lors de tests de performance, j'ai constaté beaucoup moins de fuites mémoire sur des programmes en Java que sur des programme en C++ et pour ça le Garbage Collector est vraiment apréciable (non les smartpointers de la STL ne sont pas efficaces). Alors sans dire que Java a reglé tous les problèmes, on peut quand même dire que ça a amélioré certaines choses.
Pourtant, j'ai du code Java pourri de chez pourri, Java n'est pas si portable que ça (jamais pour une application qui employe beaucoup de lib ou un peu vieille), et quand il compilé en natif, je pense que les effets de bords sont pas si négligeable que ça...
Le code reste toujours écrit par un programmeur, ça n'a pas changé avec Java, il est toujours possible d'écrire comme un goret sans commenter son code et ce sera toujours comme ça avec ou sans Java. Quand à compiler en natif je ne vois pas l'intérêt à part peut-être un soucis de performance, et encore, mieux gérer les synchronized, éviter l'utilisation de trop d'objets temporaires couteux en mémoire et à la création, corriger les speed bottlenecks sont des solutions à envisager bien avant la compilation en natif.
Oui mais la question est finalement peu intéressante parce qu'il faut bien se rendre compte que ça n'a jamais été un argument décisif dans l'adoption d'un langage. Le C++ n'est normalisé ISO que depuis 1997 (je n'ai pas réussi à retrouver le lien exact mais je donne quand même comme exemple un des projets de normalisation de C++):
et ça n'a pourtant pas empêché son utilisation bien avant sa normalisation. Les langages sont soumis à normalisation souvent bien après qu'ils aient été largement diffusés parmis les entreprises (c'était le cas pour le C++ mais aussi pour le COBOL). Ensuite, il existe un organisme de "normalisation" JCP (Java community process) permettant de s'assurer que le langage ne va pas dans un direction qui va à l'encontre des intérêts de ceux qui l'utilisent, Java suit donc un processus très précis pour son évolution :
Les fameux membres de cet organisme ne sont pas franchement des inconnus, on retrouve parmis les plus grosses entreprises du monde (et aussi des representants du libre comme Apache pour ce qui est de J2EE) garantissant que Java ne va pas à la dérive :
Bref ce "Java est-il normalisé ANSI//ISO ?" est une fausse question qui n'interesse pas grand monde (surtout ceux qui n'aiment pas Java pour diverses raisons certaines valables d'autres non).
Quels sont tes arguments à toi, si ce n'est que certains projets respectent ces "standards", pour justifier leurs utilisation ? Rien.
Les conventions et leur lisibilité est très subjective, personnellement je n'aime pas du tout l'idée du type et du nom de fonction à la colonne 0, ça n'apporte pas grand chose au niveau du repérage de type et nuit carrement, à mon sens, à la lisibilité. Et que des tas de gens l'utilisent ne me fait pas changer d'avis, je pense que rajouter un préfixe suivant la type de la variable est bien plus utile que tous ces fameux standards. Bref St GNU n'a pas toujours raison et on attends encore tes arguments.
A joint development agreement between SCO and SuSE will protect SuSE from any legal action, the Linux seller has said
Si je comprends bien cette phrase, Suse estime que l'accord qu'il possède avec SCO le protège d'une quelconque action en justice de la part de SCO. Maintenant, effectivement, Suse n'a pas acheté de license à SCO pour se proteger mais ça démontre ce que ArnY voulait dire (je cite) :
Alors bon, Suse semble plus proche de SCO que des contestataires comme RedHat dans cette histoire.
Et les linuxiens qui sont d'accord avec moi, pourquoi le sont-ils ?
Peut-être parce qu'ils ont muri, peut-être parce que passé l'emerveillement propice à l'aveuglement ils ont ouvert les yeux. Peut-être qu'ils sont rentrés dans le monde du travail et que leur certitudes idéalistes ont été balayées par la réalité de l'industrie.
En 95, lorsque j'ai découvert Linux, je n'aurais probablement pas accepté la moindre critique sur cet OS et puis j'ai découvert, comme tous les étudiants un jour, le monde du développement dans l'industrie. J'ai compris que toutes ces formidables certitudes sur le développement libre et Linux n'étaient que du vent : on ne travaille pas mieux quand l'équipe de développement est éclatée aux quatres coins de la terre, les developpeurs du libre ne sont pas des artistes qui développent mieux que les autres (la lecture de quelques codes sources bien choisis suffit pour s'en convaincre), qu'un OS sans applis fonctionnelles ne peut interesser qu'une petite frange de la population etc.
Et contrairement à benjamin, j'ai clairement retrouvé le discours à la "azerty0" chez beaucoup de "linuxiens", dans cette "communauté" où les RTFM vont bon train à l'epoque où je contribuais modestement (je traduisais des docs, j'en ai écrit). Désabusé ? Peut-être un peu. Maintenant, je n'utilise que Linux que parce que techniquement il a tout ce que je cherche chez un OS, le "c'est libre c'est bien" est devenu plus nuancé.
Voilà pourquoi moi je suis d'accord avec toi.
[^] # Re: Reponse
Posté par bleh . En réponse au journal Coup de g.... Évalué à 9.
Certaines susnommées "moules" sont des professionnels de l'informatique, travaillant depuis des années au sein des plus grands groupes internationaux, et ayant pour client les plus grandes entreprises françaises... Je fais personnellement partie de l'une des plus grandes entreprises informatiques mondiales, et mes clients sont principalement les grandes industries françaises aéronautiques... Je ne développe pas des sites web pour la cousine de la secrétaire du voisin...
Il est atrocement réducteur de vouloir faire croire que les gens qui poussent le logiciel libre sont des fanatiques élevés à l'assembleur, au coca et à la pizza...
Et sincèrement, étant donné les orientations actuelles de la plupart des professionnels, il serait peut-être temps de changer de discours, celui-ci devient franchement suicidaire...
Il est vrai que sur LinuxFR, de nombreux trolls et réflexion hâtives circulent. Mais en lisant avec attention les commentaires, on trouve aussi des réflexions poussées d'experts dans les domaines abordés, où l'on apprend beaucoup plus que dans la plupart des magazines... D'ailleurs, certains magazines relaient facilement ces trolls et autres, avec en plus un mois de retard...
[^] # Re: C'est un troll.
Posté par bleh . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 1.
- StringBuffer est un tableau d'une taille défini par défaut à 16 caractères et chaque "append()" peut potentiellement povoquer une "expansion" du tableau d'origine avec les couts d'un appel à arraycopy().
- Le principe d'expansion du StringBuffer est assez rudimentaire, en gros doublement de la capacité initiale à chaque fois ce qui fait que pour une simple String on peut avoir un espace mémoire assez conséquent utilisé.
- On crée toujours 2 objets, un procédé qui reste couteux en Java.
Bref, au niveau lisibilité ce n'est pas forcement terrible et ça reste couteux. Personnellement je pense qu'un printf() pourrait être intéressant.
[^] # Re: ...
Posté par bleh . En réponse à la dépêche Nouvelles versions de GNUstep. Évalué à 2.
L'héritage multiple en tant que tel n'existe pas en java parce que ça pose plus de problèmes que ça n'en résouds. Tu as tout de suite des problèmes de nommage qui t'oblige à revoir ton design (les solutions avec une hierarchie en diamant). La solution pour l'héritage multiple en Java c'est les interfaces. Quant à la surcharge des opérateurs, elle manque un peu c'est vrai.
un langage plus OO et plus dynamique est plus approprie
Expliques toi !
C++ a un typage statique. L'objective-C a un typage dynamique. Le polymorphisme est aussi plus naturel en Objective-C parce il n'y a pas besoin de spécifier que l'édition de liens est dynamique.
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par bleh . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 2.
Je suis tout à fait d'accord avec toi (si si :-). Mais globalement c'est une sorte d'effet de mode, j'entends dire la même chose à propos du mainframe, du COBOL etc depuis longtemps. On ne répetera jamais assez que pour chaque usage il y'a un langage adapté.
Sans rancunes?
Bien sûr ! Je suis en vacance, la vie est belle ! :+)
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par bleh . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 6.
Qui a dit le contraire ? Un programmeur C est confronté au problème de la mémoire dès la phase de programmation et le dev Java s'en soucie moins pendant cette même phase, c'est une évidence. En revanche, il est clairement obligé de le prendre en compte pendant les phase de tests et d'optimisation (les memory leaks existent aussi en Java). En ça il est sensibilisé au problème et une bonne connaissance de la structure mémoire de la JVM est indispensable.
Autre chose, par exemple, les conteneurs Java ne sont pas tous thread-safe et les programmeurs Java doivent toujours prendre en compte l'aspect multi-thread dans le choix de ces conteneurs. La mémoire joue ici aussi un rôle important puisque certains conteneurs sont très rapides en lecture et écriture mais induisent la création d'index pour accelerer les accès et peuvent donc poser des problèmes lorsque les collections contiennent une grande quantité d'objets. Les OutOfMemoryException ce n'est pas seulement dans les cauchemards.
Bref ce que je te reproche c'est de sortir des lieux communs sur Java sans véritablement prendre en compte le fait que pour bien connaitre et utiliser Java il faut nécessairement comprendre les notions de threads, de mémoire et de processeur.
Les mecs en C sont plus balaises et ont une culture informatique largement plus étendues
Puisqu'apparemment l'expérience personnelle a ici valeur de preuve, je vais moi aussi y aller de mon expérience. Je travaille sur les parties backend d'un gros projet J2EE, en gros MQseries, Moniteur transactionnel CICS, DB2 etc. Je cotoie donc 2 mondes :
- Celui des programmeurs COBOL capables de te dire la différence de réprésentation mémoire entre S9(4) COMP et S9(4). Je fais partie de ces gens-là aussi puisque j'ai écris des programmes COBOL.
- Celui des devs Java pour qui les notions d'encapsulation, d'objet sont importantes. J'en fais aussi partie puisque comme je le disais j'ai écris la partie Java de connexion MQ, d'envoi et de création des messages.
Et bien, il n'y a pas pour moi de grosses différence de culture entre ces 2 mondes. Pour la simple et bonne raison que aucun des devs Java n'a fait que du Java dans sa vie de programmeur. Et bien que j'ai quitté le monde des écoles d'ingénieurs depuis un petit bout de temps, je ne crois pas que les étudiants n'apprennent que du Java durant leurs études.
Je crois moi que tu as une culture "bas niveau" et que donc tu "idolatres" les programmeurs C parce qu'il correspondent à ta conception de l'informatique, c'est un droit mais laisse moi douter de ton objectivité lorsque tu parles des dev Java.
"Ha ouais, super, J2EE et tout. On va prendre ce FrameWork de la mort qui tue et on va leur montrer aux minus d'UNIX comment qu'on fait des applis pour les end-user...". Désolé ça m'énerve.
Le serveur d'application IBM WebSphere fonctionne très bien sous AIX ... je vois vraiment pas où tu as pu entendre ça. D'autant que ça ne veut presque rien dire J2EE c'est plutôt du client/serveur avec des conteneurs et il n'y a pas de notions purement "Unix" équivalente . Java et Unix ne sont pas antinomique. OK Java a mauvaise presse du coté de Linux pour des raisons de licence mais IBM contribue à améliorer Java pour les plateformes Unix.
Finalement si les gens prenaient le temps de connaitre vraiment les technos, on aurait probablement une meilleure collaboration à tous les niveaux, entendre "Haha on va leur expliquer la mémoire à ces tapettes de programmeurs Java ..." c'est énervant aussi.
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par bleh . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 1.
Franchement c'est à mourir de rire. Heureusement que les dev java connaissent ce genre de notions, ne serait-ce que pour utiliser un pattern singleton thread-safe. Et les "synchronized" ça sert à quoi d'après toi ?
D'autant que les notions dont tu parles existent en Java exepté les IPC (bien qu'il soit possible d'en émuler le comportement en se débrouillant avec des sockets), je te conseille d'aller jeter un coup d'oeil au package java.net., tu seras etonné de voir ce qu'on y trouve.
La plupart des gens qui utilisent Java ont oublié la notion de processeurs ou de mémoires (Procéquoi ? Memqui ?)
Mais bien sur ! Est-ce que tu as déjà été sur un projet java sérieux ? L'optimisation en Java est clairement basée sur l'optimisation de l'utilisation mémoire, le cycle du garbage est vital pour avoir des performances correctes idem pour le comportement de la heap (les paramètres -Xms et -Xmx sont par exemple importants).
L'existance en Java d'un garbage collector fait que la libération des ressources est moins problématique mais cela reste tout de même une préoccupation majeure. Et d'ailleurs, le fait que des logiciels tels que OptimizeIt de Borland ou JProbe existent montre que les notions de processeurs et de mémoire ne sont clairement pas oubliées.
Tu as raison de mettre "connaissances de base en Java" sur ton cv. Lire ce genre de conneries ça me gacherait presque mes vacances :-)
[^] # Re: Jabber est officiellement un standard
Posté par bleh . En réponse à la dépêche Jabber proposé comme standard IETF (XMPP). Évalué à 2.
A quoi sert un standard si il n'est utilisé que par un IM ? A rien. Après on peut effectivement se féliciter que ça soit le protocole Jabber qui ait été choisi mais finalement ça n'apporte pas grand chose. Donc non on s'en fout pas un peu que les autres s'y mettent pas.
[^] # Re: Nouveau memo Halloween - SCO attaque
Posté par bleh . En réponse à la dépêche Nouveau memo Halloween - SCO attaque. Évalué à 1.
Pour info, Accenture ne fait pas d'audit. Accenture était la branche conseil d'Andersen sous le nom d'Andersen consulting et cette branche s'est séparé (comme pour PWC qui a vendu sa filière conseil à IBM) en 1999. L'audit et le controle de gestion c'est (était) Arthur Andersen.
[^] # Re: Grande pétition contre le fortran
Posté par bleh . En réponse au journal Grande pétition contre le fortran. Évalué à 5.
Franchement, le COBOL II est clairement le meilleur langage de gestion. Les structures COBOL sont largement mieux foutues que dans d'autres langages, le mode étendu, le COMP, le COMP-3 sont extrêmement utiles et lorsqu'on doit s'amuser à passer des messages avec MQSeries on est content que le mapping soit fait simplement grâce au mode étendu (idem pour le signe avec trailing-separate).
C'est amusant cette dictature des langages. En dehors du C/C++/java point de salut, un peu comme une mode. L'objet n'est pas adapté pour tous les usage et dans la série langage mal fichus, le C s'impose aussi (tout programmeur normalement constitué admettra que la gestion des chaines de caractères en C est pourrie). Alors le cobol a encore de beaux jours devant lui.
C'est une bonne chose que les étudiants voient d'autres langages pour leur culture personnelle et aussi pour le fait que ces langages ne sont pas aussi confidentiels que certains aimeraient le croire.
[^] # Re: Sortie de KOffice 1.3
Posté par bleh . En réponse à la dépêche Sortie de KOffice 1.3. Évalué à 1.
Parce que comme d'habitude ici, il y'a quelqu'un pour se pointer dans un thread et dire "Microsoft est malhonnête, Windows c'est pas bien". C'est un grand classique de linuxfr et comme d'habitude pBpG est obligé de rétablir la vérité en apportant des faits. je ne vois pas où est le problème ... si on ne lisait pas autant de conneries ici, il n'aurait probablement jamais rien à dire sur MS. Et puis, contrairement à ce que tu crois pBpG participe aussi sur d'autre sujet, je me souviens particulièrement d'une discussion sur Java où il avait participé (et pas pour parler de Microsoft).
Bref, tout n'est pas aussi simple que tu sembles le croire.
Et l'idée que Microsoft ai "placé" quelqu'un sur un site comme linuxfr, n'est pas si absurde que ça.
Non, elle est complètement débile. Franchement, MS n'a absolument rien à faire de gens qui de toute façon dans leur grande majorité ne seront jamais convaincu par aucun produit Microsoft. Et si tu veux un argument supplémentaire lis ce commentaire : http://linuxfr.org/comments/337199.html(...)
[^] # Re: Voix sur IP : Teamspeak
Posté par bleh . En réponse à la dépêche Voix sur IP : Teamspeak. Évalué à 1.
Oh la oui c'est merveilleux. Ne même pas prendre le temps de pas se planter sur le nom du créateur de CP/M (gary Kildall) ! Pour ceux qui veulent savoir un peu plus sur CP/M et le travail de Kildall :
http://www.maxframe.com/GARY&CPM.HTM(...)
Et pour ceux qui ne connaitraient pas l'histoire de MS-DOS, voilà un petit lien qui sans être exhaustif résume bien l'histoire :
http://inventors.about.com/library/weekly/aa033099.htm(...)
[^] # Re: il faut des efforts pour être créatif/original
Posté par bleh . En réponse à la dépêche Linux est prêt pour le bureau. Évalué à 1.
J'espère que tu n'es pas sérieux quand tu dis ça ... Des gros projets d'industrie comptent des fois plus de 100 développeurs ! Une application peut être découpée en modules indépendant et developpés de manière indépendante par des équipes indépendantes. L'intégration se fait ensuite en phase de test et de prod. Encore heureux que les projets ne se limitent pas à 5 dev !
[^] # Re: Marché du travail, licenciements abusifs et offshore en informatique
Posté par bleh . En réponse à la dépêche Marché du travail, licenciements abusifs et offshore en informatique. Évalué à 2.
Plus grosse en terme de quoi ? Employés ? CA ? Je suis pas un spécialiste des classements mais j'ai jamais vu EDS dans les premières places.
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
Comme le nom l'indique, ce n'est pas le but.
Qui a dit le contraire mais ça n'empêche qu'un programme doit avoir des exceptions et des méthodes pour les gérer.
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
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:
- La pile n'est pas un espace mémoire immense et mettre des objets (et a fortiori gros) dans la pile c'est s'exposer à un risque de stack overflow.
- Le programme sauvegarde son contexte d'execution dans la pile et ça implique des problèmes de sécurité puisque la pile est "executable". Le buffer overflow ce n'est pas seulement dans mes cauchemars.
Et il y'a aussi les problèmes dans le cas de programme multithreadé que j'avais oublié (merci pBpG). La pile n'est pas vraiment un espace thread-safe et effectivement on peut arriver à des résultats rigolos.
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.
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.
Bien bien ok toi tu utilises la pile mais d'autres personnes non (sûrement des mauvais programmeurs) et dans ces cas là le problème se pose, tu peux retourner le problème dans tous les sens mais ça reste toujours la même chose : la gestion mémoire n'est pas simple et est source d'erreur (dans la vraie vie, dans les programmes des entreprises mais pas dans les tiens ok).
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.
Elle ne dégrade pas au contraire. Bon, sérieusement, j'ai fait de l'audit de code C++, j'en fais aussi (Java cette fois-c)i actuellement pour la boite ou je travaille et clairement le nombre de memory leaks est bien plus élevé dans le programme C++ que dans ce programme Java. Le GC est à mon avis plus efficace que des désallocations manuelles. En ça c'est une bonne solution, permettre d'avoir des programmes plus fiables c'est tout de même le plus important.
Pour finir, j'aprécie le C++ et ses qualités mais je l'ai assez pratiqué pour savoir qu'il a des défauts, que Java corrige entre autre. Après on peut se mettre la tête dans le sable et tout nier en bloc mais c'est un fait et probablement qu'un jour un langage corrigera les erreurs du Java. C'est tant mieux, c'est ça l'évolution.
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
Bof, on peut effectivement faire comme ça mais ce n'est pas très joli et question perf ce n'est pas terrible non plus.
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 1.
Non, comme je le disais ce n'est pas la méthode normale. La pile n'est pas seulement disponible pour les variables locales, elle sert aussi à sauver le contexte d'exécution, l'exemple que je donnais était simple (je ne vais pas écrire une classe de 2000 lignes pour un exemple) mais supposons que j'utilise _beaucoup_ d'objets dans ma méthode, là le risque de dépassement est clair. 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. 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).
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.
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.
{
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.
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). Eventuellement si on veut à tout prix utiliser la pile on peut mettre un pointeur sur la pile mais finalement ça revient au même vu qu'on sera tout de même obligé de supprimer le pointeur pour éliminer l'objet.
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.
C'est un pattern justement ;-). Je trouve que c'est un bricolage parce que pour disposer de tous les avantages du java il faut bien choisir son pointeur intelligent (auto_ptr ne fonctionne pas avec la STL par exemple) et que ça crée des dépendances supplémentaires, bref c'est contraignant tout simplement parce que le langage n'a pas été prévu pour. 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.
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 ?
Ok je n'avais pas compris. Quand on instancie un objet dans une méthode, la référence est effectivement libérée à la fin du bloc mais l'objet lui est toujours en mémoire et attends d'être éliminé par le GC. 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. Pour les autres variables (types primitifs), comme je le disais, le système est le même qu'en C++, elles sont détruites en fin de bloc.
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 2.
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. Dès que tu utilises des objets tu es pratiquement obligé de renoncer à la mémoire automatique et la desallocation se fait à la main. Si j'ai insisté sur les pointeurs intelligents c'est parce que ça montre un besoin de la part des programmeurs d'avoir un système de gestion mémoire automatique (ce que possède Java).
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
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) à des fins d'affichage, dans ce cas on est d'accord j'utilise bien la mémoire dynamique et là si on place des objets compte chèque et compte titre qui sont dérivés de compte on doit effectuer le nettoyage à la main. On pourrait trouver des dizaines d'exemples du même type.
Et en plus la mémoire automatique est plus rapide, et tout se passe bien avec les exceptions...
Oui je suis d'accord mais avec cet exemple là :
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é.
(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)
Loin de moi l'idée de dire que des variables automatiques sont gérées par le programmeurs (quand même ! ;-), pour les pointeurs oui on est d'accord mais là où je ne suis pas d'accord c'est que ce n'est pas aussi simple que ça de ne pas utiliser de pointeurs. 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++.
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...
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.
Bref, Java a clairement été conçu pour être un dérivé simplifié de C++ et pour corriger certain défauts dont la gestion de la mémoire mais ça n'enlève rien à la qualité du C++ (ça reste un bon langage que j'aprécie beaucoup) et son utilisation massive le prouve mais je pense sincèrement que le jour où les perfs en Java seront équivalente au C++ ce sera la fin du C++.
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 3.
Je ne parlais pas de ceux de boost en particuliers, je me suis mal exprimé, je voulais parler des pointeurs intelligents en général (smartpointers ... mélanger le français et l'anglais dans un commentaire n'est pas une bonne idée) style auto_ptr de la lib standard. Il y'a surement d'autres implémentations de pointeurs intelligents mais j'avoue que je ne fais plus beaucoup de C++ et que je ne me tiens plus vraiment au courant.
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.
Qu'on implémente des pointeurs intelligents qui comptent les références sur eux montre bien que ce n'est pas aussi évident et que des fois ce n'est pas une question de maitrise du C++ : par exemple une méthode qui lève une exception et qui execute donc le code correspondant à la place du code prévu, des pointeurs qui pointent sur null ... ce genre de choses, sans compter les erreurs d'étourderie, qu'on ne peut pas toujours éviter bon codeur ou mauvais, font qu'un code n'a pas le comportement attendu. C'est un refrain connu le programmeur responsable qui alloue et désalloue la mémoire parfaitement sans jamais une erreur mais dans la vraie vie c'est rare ... très rare. Quant à utiliser l'allocation dynamique qu'en dernier recours c'est à mon avis très illusoire dès qu'on a besoin de conteneurs tels que vector ce qui est le cas dans beaucoup de programmes (voire la majorité), supposons que je souhaite aficher une liste de comptes rapatriés d'une base je suis clairement obligé d'allouer dynamiquement une liste, ce n'est qu'un exemple mais il y'en a des centaines dans les programmes.
Je suis d'accord avec toi pour dire que beaucoup de gens n'utilisent pas ce qu'a apporté le C++ mais ça n'enlève rien au fait que confier la gestion de la mémoire au programmeur n'est pas forcement une bonne idée et que justement Java corrige cette erreur (ça en induit d'autre comme par exemple quand la heap atteint le seuil de garbage collection trop vite et force le GC à s'executer dans des intervalles très courts ce qui impacte clairement la performance mais bon ce n'est pas le propos du thread). Pour moi le tort du C++ est clairement d'avoir voulu garder un rapport avec le C pour ne pas dépayser, Java a su au moins rompre l'héritage en utilisant un GC.
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 3.
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 ou de simplifier certaines notions de l'objet comme le polymorphisme. Lors de tests de performance, j'ai constaté beaucoup moins de fuites mémoire sur des programmes en Java que sur des programme en C++ et pour ça le Garbage Collector est vraiment apréciable (non les smartpointers de la STL ne sont pas efficaces). Alors sans dire que Java a reglé tous les problèmes, on peut quand même dire que ça a amélioré certaines choses.
Pourtant, j'ai du code Java pourri de chez pourri, Java n'est pas si portable que ça (jamais pour une application qui employe beaucoup de lib ou un peu vieille), et quand il compilé en natif, je pense que les effets de bords sont pas si négligeable que ça...
Le code reste toujours écrit par un programmeur, ça n'a pas changé avec Java, il est toujours possible d'écrire comme un goret sans commenter son code et ce sera toujours comme ça avec ou sans Java. Quand à compiler en natif je ne vois pas l'intérêt à part peut-être un soucis de performance, et encore, mieux gérer les synchronized, éviter l'utilisation de trop d'objets temporaires couteux en mémoire et à la création, corriger les speed bottlenecks sont des solutions à envisager bien avant la compilation en natif.
[^] # Re: SUN annonce Mad Hatter
Posté par bleh . En réponse à la dépêche SUN annonce Mad Hatter. Évalué à 9.
Oui mais la question est finalement peu intéressante parce qu'il faut bien se rendre compte que ça n'a jamais été un argument décisif dans l'adoption d'un langage. Le C++ n'est normalisé ISO que depuis 1997 (je n'ai pas réussi à retrouver le lien exact mais je donne quand même comme exemple un des projets de normalisation de C++):
http://www.comnets.rwth-aachen.de/doc/c++std.html(...)
et ça n'a pourtant pas empêché son utilisation bien avant sa normalisation. Les langages sont soumis à normalisation souvent bien après qu'ils aient été largement diffusés parmis les entreprises (c'était le cas pour le C++ mais aussi pour le COBOL). Ensuite, il existe un organisme de "normalisation" JCP (Java community process) permettant de s'assurer que le langage ne va pas dans un direction qui va à l'encontre des intérêts de ceux qui l'utilisent, Java suit donc un processus très précis pour son évolution :
http://www.jcp.org/en/procedures/overview(...)
Les fameux membres de cet organisme ne sont pas franchement des inconnus, on retrouve parmis les plus grosses entreprises du monde (et aussi des representants du libre comme Apache pour ce qui est de J2EE) garantissant que Java ne va pas à la dérive :
http://www.jcp.org/en/participation/committee(...)
Bref ce "Java est-il normalisé ANSI//ISO ?" est une fausse question qui n'interesse pas grand monde (surtout ceux qui n'aiment pas Java pour diverses raisons certaines valables d'autres non).
[^] # Re: ftp.gnu.org piraté
Posté par bleh . En réponse à la dépêche ftp.gnu.org compromis. Évalué à 1.
Les conventions et leur lisibilité est très subjective, personnellement je n'aime pas du tout l'idée du type et du nom de fonction à la colonne 0, ça n'apporte pas grand chose au niveau du repérage de type et nuit carrement, à mon sens, à la lisibilité. Et que des tas de gens l'utilisent ne me fait pas changer d'avis, je pense que rajouter un préfixe suivant la type de la variable est bien plus utile que tous ces fameux standards. Bref St GNU n'a pas toujours raison et on attends encore tes arguments.
[^] # Re: RedHat porte plainte contre SCO.
Posté par bleh . En réponse à la dépêche RedHat porte plainte contre SCO.. Évalué à 3.
Au fait que Suse est proche de SCO :
A joint development agreement between SCO and SuSE will protect SuSE from any legal action, the Linux seller has said
Si je comprends bien cette phrase, Suse estime que l'accord qu'il possède avec SCO le protège d'une quelconque action en justice de la part de SCO. Maintenant, effectivement, Suse n'a pas acheté de license à SCO pour se proteger mais ça démontre ce que ArnY voulait dire (je cite) :
Alors bon, Suse semble plus proche de SCO que des contestataires comme RedHat dans cette histoire.
Donc non ce n'est pas des conneries.
[^] # Re: précisions glanées sur slashdot (les copieurs!)
Posté par bleh . En réponse à la dépêche Le projet Kroupware est achevé : parution de Kolab.. Évalué à 1.
Peut-être parce qu'ils ont muri, peut-être parce que passé l'emerveillement propice à l'aveuglement ils ont ouvert les yeux. Peut-être qu'ils sont rentrés dans le monde du travail et que leur certitudes idéalistes ont été balayées par la réalité de l'industrie.
En 95, lorsque j'ai découvert Linux, je n'aurais probablement pas accepté la moindre critique sur cet OS et puis j'ai découvert, comme tous les étudiants un jour, le monde du développement dans l'industrie. J'ai compris que toutes ces formidables certitudes sur le développement libre et Linux n'étaient que du vent : on ne travaille pas mieux quand l'équipe de développement est éclatée aux quatres coins de la terre, les developpeurs du libre ne sont pas des artistes qui développent mieux que les autres (la lecture de quelques codes sources bien choisis suffit pour s'en convaincre), qu'un OS sans applis fonctionnelles ne peut interesser qu'une petite frange de la population etc.
Et contrairement à benjamin, j'ai clairement retrouvé le discours à la "azerty0" chez beaucoup de "linuxiens", dans cette "communauté" où les RTFM vont bon train à l'epoque où je contribuais modestement (je traduisais des docs, j'en ai écrit). Désabusé ? Peut-être un peu. Maintenant, je n'utilise que Linux que parce que techniquement il a tout ce que je cherche chez un OS, le "c'est libre c'est bien" est devenu plus nuancé.
Voilà pourquoi moi je suis d'accord avec toi.