Pour ton exemple, ca n'a aucun rapport avec final, mais avec la sémantique du private en Java. Pour le reste, je ne comprends rien à ton charabia (permettre ce que final n'autorise pas : des fonctions avec le nom en question qu'est-ce que ça veut dire ?).
Ce que j'adore avec toi, c'est ton caractère borné. Je n'ai jamais dit que Java était formidable et bien meilleur que C++, j'ai juste mis en cause certains éléments de tes critiques. Et maintenant que tu te rends compte que tu t'es lourdement trompé, tu oublies tes délires sur final/virtual pour revenir à un élément sur lequel tu as partiellement raison. C'est affligeant.
Comme je m'attends à une bonne dose de mauvaise foi, je complète :
Tu es formidable. Tu te rends compte que tu as au mieux mélangé un peu tout et hop, en avance, tu évacues toute contestation par une sympathique accusation de mauvaise foi. Pathétique.
Donc, si j'ai bien lu entre les lignes, tu proposes de créer une classe abstraite avec une méthode bidule non virtuelle qui contient des tests (pré/post conditions, etc.) et qui appelle une méthode bidule_interne qui est elle virtuelle et privée.
Effectivement, en Java, on ne peut pas faire exactement ça pour deux raisons :
1) l'absence d'héritage mutliple fait qu'on ne peut pas faire ça pour plusieurs classes abstraites
2) la méthode bidule_interne ne peut pas être private mais protected (franchement, ce n'est pas un drame)
Et oui, les primitives de contrôle d'accès de C++ sont plus riches que celles de Java et le langage supporte l'héritage multiple. Je n'ai jamais dit le contraire. Ceci étant, explique moi en quoi ceci démontre la différence entre le final de Java et le virtual de C++ et on verra qui est le plus de mauvaise foi.
Une version beta ce n'est pas du concret. Quand ce sera stable, ce sera un bon point.
Oui, oui, bien sûr. Puisque je te dis que c'est la même techno que celle de GJ (ce sont les mêmes auteurs) qui est testé littéralement depuis des années !
Je vais même te donner un exemple plus plus simple que je ne pensais au départ : une classe qui implémente proprement plusieurs interfaces. C'est possible en C++, c'est impossible en Java (on ne peut le faire que pour une interface). Proprement, bien sûr, c'est à dire que l'interface inclue le code de vérification pré/post condition.
Quel est le rapport avec final/virtual ? Tu peux implémenter plusieurs interfaces avec une même classe en Java, puisque justement la notion d'interface est faite pour : il n'y a pas de corps de méthodes dans les interfaces. Donc, je suppose que tu veux dire qu'en C++ tu peux écrire plusieurs classes abstraites (mélangeant des méthodes implémentées et des en-têtes seuls) et en hériter. Nous sommes d'accord, c'est l'héritage multiple qui n'existe pas en Java. Je vois bien l'intérêt que tu trouves à ça, mais toujours pas le rapport avec final/virtual. Donc, si tu donnais un exemple concret, ça serait peut être idéal. Je vais finir par croire que tu te fous de moi.
Et toi tu ferais pas mal de lire (ou plus dur : réfléchir) avant de répondre. Tiens lis donc ma remarque initiale pour voir à quel point tu réponds à coté.
La technologie qui permet les foncteurs existe de façon nettemment plus puissante en Java. L'implémentation proprement dite existe sous forme d'une bibliothèque open source (cf http://jga.sourceforge.net/(...)).
C'est bete, des langages utilisent cet idiome. Celui que tu présente s'appelle plutot « bidouille pour compenser une faiblesse ».
Quelle puissance dans l'argumentation. Note bien que je n'ai pas dit que c'était un mauvais idiome, juste qu'il était incompatible avec les langages à GC.
Il y a une incohérence dans ta phrase : un verbe au présent. Quand ce sera du concret, j'enlèverai ce manque, mais pas avant.
Java 1.5 est disponible en version beta, tu peux tester. La plupart des concepts derrière l'implémentation actuelle datent de gj, une extension de Java qui a au moins 5 ou 6 ans et qui est une technologie très éprouvée. C'est du concret.
final et non-virtual c'est pas la même chose. Ah, ça y ressemble de loin, dans le détail non.
Et si tu ne vois pas le rapport avec les pré/post conditions vérifiées dans une interface, ton commentaire suivant sur « comprendre la conception objet » est assez comique.
Oui, oui, bien sûr. Donne un exemple et on va voir. Si ton seul argument est que C++ perd le type d'un objet passé par valeur, nous sommes d'accord, il y a bien une différence entre non virtual et final, mais si tu arrives à défendre ça en terme de conception objet, je te tire mon chapeau.
Non des foncteurs de C++. Mais là j'ai dit que je n'étais pas sûr de l'absence d'équivalent. Si tu en vois...
Classes anonymes et interface. Tu connais bien Java, ça fait peur. Tu n'a pas pratiqué depuis la version 1.1 ?
Oui en faisant un destructeur (c'est le terme générique) que l'on est obligé d'appeler manuellement avant de supprimer la dernière référence. Super propre.
T'as tout compris, ça se sent. C'est clair que quand on supprime la dernière référence en Java, on a la super classe et on connaît bien le langage. Aller, je suis de bonne humeur (faut dire que tu es très drole), je t'explique. Si un objet accapare une ressource unique qui doit être relachée à un moment ou à un autre, tu peux utiliser le destructeur de l'objet en C++ pour lui faire relacher cette ressource : c'est un idiome de programmation C++ qui vaut ce qu'il vaut. Il est totalement incompatible avec la notion même de GC dans laquelle on ne sait jamais quand on objet va être détruit (ce qui est bien plus efficace en terme de gestion de la mémoire, d'ailleurs). En Java et en général dans les langages avec GC, tu ne peux pas utiliser cet idiome, donc tu programmes proprement avec un autre idiome. Par exemple, tu fabriques un objet qui prend comme paramètre du code à faire tourner (implémenter par une classe anonyme), qui récupère la ressource, exécute le code, puis relache la ressource.
De toute manière, si tu as vraiment besoin d'utiliser des ressources uniques critiques, en général tu as vraiment intérêt à faire du J2EE car le serveur d'application gère ces ressources à ta place de façon très efficace. Mais j'oubliais que Java ne sert qu'à faire du web, idiot que je suis.
Pour tout ce qui est conteneurs, ce que propose Java est quand même ridicule par rapport à la STL à cause de ça, non ?
C'est sûrement moins efficace, mais ridicule, je dois dire que je ne comprends pas pourquoi, d'autant que la STL est très complexe à cause de la gestion mémoire. Et puis bon, les templates c'est dans java 1.5 qui est déjà disponible en version beta...
« final » peut être une solution mais pas toujours, ce n'est pas exactement la même chose.
Pourrais-tu détailler pourquoi ? J'ai fait pas mal d'années de programmation C++ et je t'avoue que je ne vois pas à quoi tu peux bien faire référence.
Oui, sauf que non. Si tu utilises un GC dans un environement de production, ce n'est pas pour avoir un memory leak. Or, les GC destinés aux langages comme le C ou le C++ ne peuvent pas garantir à 100% qu'il n'y aura pas de memory leak. Tu me diras qu'il y a toujours des bugs dans les GC et donc que du 100%, ça n'existe pas, ce qui n'est pas faux. Sauf que dans la situation présente, ce n'est un bug dans le GC qui est à craindre, mais un problème dans ton code qui fait que le GC ne peut pas désallouer une partie de la mémoire...
Sinon, je t'avoue que la prose de Stroustrup ne m'intéresse absolument pas. Ce brave homme a montré depuis des années qui ne connaissait absolument rien à ce que la recherche a produit dans le domaine des langages de programmation et le résultat est C++, plein de bonne volonté et plein d'erreurs de conception. Ca m'arrache le coeur de l'avouer, mais Microsoft a bien compris le problème et a donc embaucher des gens compétents dans le domaine pour faire C#, et franchement, ça se voit...
Ok, maintenant regarde un peu le code deroulé quand tu utilises Corba, Com, l'overhead des interfaces graphiques et des commandes utilisateurs ... ce n'est pas une indirection sur un objet qui va bouffer tes perfs.
Tu ne comprends donc rien. L'indirection obligatoire en Java fait qu'on ne peut pas économiser la mémoire et donc ça bouffe tes perfs même avec des usines à gaz comme Corba ou Swing (qui subissent elles aussi cette contrainte et donc sont encore plus des usines à gaz en Java que dans leur version C++). L'absence de l'équivalent des structs du C# en Java est une catastrophe en terme de performances à cause de la mémoire.
Ton probleme c'est que tu n'as qu'une vue locale de ce que tu developpes. Je suis d'accord avec toi que sur un algo bien precis il faut effectuer ce genre d'optimisation comme pour l'exemple que tu as cite. Mais d'une maniere generale, l'utilisation d'un formalisme de haut niveau tel que la programation distribuée ou par composants, les IHM, permettent un developpement plus rapide et de meilleur qualite au detriment des perfs (indirections, overhead inevitables)
Tu lis O1, c'est ça ? Je me demande comment tu utilises un formalisme de haut niveau alors que tu n'as rien compris à l'objet...
Je suis en effet très intolérant avec la connerie et très irrespecteux de celle-ci. Tu l'incarnes ici. Tu arrives dans ce thread et tu multiplies les posts débiles du genre :
- "C++ n'est pas objet car il ne supporte pas le typage dynamique" : n'importe quoi. Une telle déclaration prouve simplement que tu ne connais rien aux langages objets, en particulier certains des plus avancés comme Eiffel ou Objective Caml.
- "Dans un monde objet l'heritage n'a pas vraiment de sens" : désolé, mais là, ce n'est même plus n'importe quoi, c'est tout simplement débile
- "L'un des avantages est de ne plus avoir de table de fonctions virtuelles et de pouvoir ajouter a l'execution un nouvel objet. " : j'ai déjà répondu à ça, mais visiblement tu ne sais pas comment un modèle objet est implémenté (sur le hardware), donc ça ne sert à rien de continuer
- "De toute facon la notion d'objet, a mes yeux, n'est pas dependante du langage mais plutot de la facon dont le developpeur utilise les fonctionnalités du langage utilisé. Elles ne sont la que pour l'aider et formaliser syntaxiquement ce concept." : tu n'as encore rien compris, comme toutes les personnes qui prétendent faire de l'objet en C.
Bon, je m'arrête, ça suffira. Tu démontres pas ces posts que tu parles de choses que tu ne connais pas. Je n'ai aucun respect pour ça (soit dit en passant, tu m'indiques que je ne sais pas lire, ce qui n'est pas très respectueux non plus).
- l'absence de templates, on ne peut s'en sortir que de manière crade (classe Object).
Java 1.5 propose des templates bien plus intéressants et propres que ceux du C++.
les fonctions automatiquement virtuelles : impossible de faire de la vérif de pré/post condition derrière l'interface, qui est l'endroit où les faire (ça ne doit pas être laissé à la classe qui implémente).
Qu'est-ce que c'est que ce délire ? Tu as déjà entendu parler de final qui permet de faire exactement la même chose que l'absence de virtual en C++ ? Et quel est le rapport avec les pré et post conditions ?
l'absence des foncteurs
De quoi parle tu, des foncteurs de caml ?
pas de surcharge d'opérateurs
Très gênant, nous sommes d'accord.
pas d'héritage multiple (oui ça sert à faire des choses propres)
C'est sûr, quand on ne comprend rien à la conception objet, c'est très utile.
les destructeurs dont l'appel n'est pas garanti
Il n'y a pas de destructeurs, mais des finalizers dont le but n'est absolument pas le même. De toute manière, si tu as besoin des finalizers, c'est certainement que tu devrais programmer ton appli autrement.
A tout prendre, je préfère largement "les fonctions virtuelles" (lire "la liaison dynamique") par défaut, c'est bcp plus proche du raisonnement humain à mon avis. De plus, je trouve plus simple de dire quand la liaison dynamique doit s'arrêter que de dire tout le tps qu'elle doit avoir lieu
Parfaitement d'accord, d'autant qu'un bon compilateur (cf smalleiffel) est capable d'enlever lui-même l'aspect "virtuel" quand il peut démonntrer (si, si, il s'agit d'une preuve) qu'il n'en n'aura pas besoin à l'exécution. Mais bon, dès que quelqu'un te dit que les virtuels du C++ c'est super pour l'optimisation, tu dois détecter qu'il a dix ans de retard sur l'état de l'art en compilation des langages objets (et encore, 10 ans, je minimise). Les virtuels, c'est la plus grosse connerie du C++ avec l'absence de GC.
C'est sûr qu'ils sont vachement utilisés en C, il n'y a qu'a regarder dans gnome. Comme le C est intrinsèquement non sûr, on ne peux pas faire un GC parfaitement sûr pour ce langage, de même que pour le C++. Donc désolé, mais pour qu'un GC puisse (au moins en théorie) fonctionner parfaitement, il faut que le langage soit conçu pour.
Je sais lire la masse de conneries que tu as postées dans cette news. Toutes les applis Java que je connais sont pénalisées par une consommation de mémoire pléthorique. Avec une grosse quantité de mémoire, elles fonctionnent très bien, avec des performances très honorables. D'où vient cette consommation ? Du fait que tous les objets sont manipulés par référence (d'où l'occupation de 4 octets pour chaque objet au minimum) et que Object est bloated pour des raisons de conception.
Le problème de Java est que tu ne peux pas faire autrement : tu ne peux pas manipuler les objets par valeur, même quand ça permet d'économiser de la mémoire et des perfs. Donc, oui l'indirection coûte quelque chose, à la fois en occupation mémoire et en perfs. Mais tu appliques servilement les préceptes de mauvais profs, donc tu ne comprends rien. Dans mes cours, tu aurais des sales notes.
Tes profs sont des cons. Le coût perdu par l'indirection en Java est énorme car il participe de la mauvaise gestion de la mémoire des applis Java. Tout objet en Java est manipulé par référence. Oui, l'indirection elle-même ne coûte pas grand chose pour un objet. Mais quand tu scannes un tableau d'objets, tu n'as plus de localité en mémoire et ça peut donner des résultats catastrophiques à cause des accès "random" à la mémoire qui ne profitent pas du tout du cache. Un exemple : produit matriciel programmé en tenant compte de la localité du stockage peut être 100 fois plus rapide que le même produit matriciel programmé à la grand père, en ne tenant pas compte de la localité. Sur des tableaux d'objets, on obtient le même genre de perfs...
Je suis d'accord, le problème essentiel de Java est son occupation mémoire causée par les un java.lang.Object complètement bloated. Ceci étant, ce n'est pas une fatalité :
1) il existe des techniques pour virer le verrou nécessaire au synchronized. C'est implémenté dans SableVM (http://www.sablevm.org/(...)).
2) des langages objets plus vieux de Java (Eiffel et Sather) ont une notion d'objets passés par valeur (et uniquement par valeur) qui ressemblent aux structs du C et qui permettent de régler le problème poser par Integer. Comme le typage devient 100% statique avec ces objets, on peut s'arranger pour qu'ils occupent exactement la place mémoire nécessaire. Pour les petits objets type Integer, ou nombre complexe, c'est la fête.
Un objet même passé par valeur reste de toute manière beaucoup plus lent qu'un vrai type primitif "mappable" directement sur l'architecture de données du processeur.
Non, les tests de Sather et Eiffel prouvent le contraire. Un objet passé par valeur ne supporte pas l'héritage, il n'y a donc pas de table de méthodes "virtuelles" à la C++. Un int Eiffel est un objet, mais il est manipulé comme un int natif dans le code engendré.
Juste une petite remarque : quand on parle de troll, il ne s'agit pas des bestioles sympathiques du folklore nordique ou de leurs versions tolkienesque, mais d'un verbe anglais qui désigne une technique de pèche (cf http://info.astrian.net/jargon/terms/t/troll.html(...)). Je doute qu'on puisse marcher dans ses excréments.
A partir du moment ou tu souhaites considérer les types de base comme des objets, il faut accepter une perte de perf et ça quelque soit le langage.
C'est faux. Eiffel et Sather considèrent les types de base comme objet sans perte de performance. Pour ce faire, il faut distinguer deux catégories d'objets (comme en C#), ces objets passés par référence et des objets passés par valeurs. Les types de base sont des objets passés par valeur, ce qui élimine les problèmes d'occupation mémoire et d'efficacité induit par l'autoboxing.
Vector est avantageusement remplacé par les List, en version ArrayList. Vector est synchronized (thread safe) ce qui la rend lente comparée à ArrayList quand on n'a justement pas besoin de l'aspect synchronized.
Ta démonstration serait formidable si elle ne s'appuyait pas sur des erreurs factuelles importantes. Tout d'abord, les JVM libres existent, elles sont même assez nombreuses. Le problème est le JRE, c'est-à-dire l'ensemble constitué de la JVM et des classes de base. Or, ces classes de base sont en grande partie développée en Java, dans le JRE de Sun lui même. Quand IBM demande l'ouverture de Java, c'est bien du JRE qu'il s'agit et les développeurs Java sont parfaitement compétents pour participer à son développement (cf classpath, d'ailleurs).
De plus, il existe une JVM open source et entièrement (ou presque) écrite en Java. L'ironie du sort veut qu'elle soit justement écrite par IBM (cf http://www-124.ibm.com/developerworks/opensource/jikesrvm/(...)). Les divers échos que j'en ai eu sont qu'elle tourne plutôt efficacement, à condition, comme toujours en Java, d'avoir une mémoire conséquente.
L'un des avantages est de ne plus avoir de table de fonctions virtuelles et de pouvoir ajouter a l'execution un nouvel objet.
Ultra puissant, on remplace une table de fonctions virtuelles par un pointeur vers le type de l'objet. Quel gain remarquable !!! De toute manière, Java est typé à la compilation...
En fait, un truc ultra puissant de Java c'est que les vérifications pour la mémoire se font dynamiquement, à partir du .class. Tu peux charger une application compilée dans une sandbox et l'exécuter en contrôlant parfaitement son exécution en terme de droit d'accès aux ressources de la machine virtuelle. En fait, tu peux charger dans une même machine plusieurs applications et maîtriser parfaitement les communications entre elles. A ma connaissance, seul C# possède des fonctionnalités de ce genre. Les exemples que tu cites sont bons à partir du moment ou on dispose du source. Par contre, quand on produit un code exécutable, on ne peut plus vérifier grand chose sur celui-ci. En Java et en C#, un modèle de sécurité très évolué permet au contraire de contrôler parfaitement l'exécution d'un code compilé. L'aspect mémoire est une petite partie de ces fonctionnalités.
Ceci étant, tu as parfaitement raison pour memcheck86, mais je crois que ton interlocuteur faisait une "petite blague" sur l'utilisation mémoire de Java, un vrai problème...
-interface graphique certe gourmande en memoire mais identique quelque soit la plate forme
Ouai, sauf que c'est resté assez moche jusqu'à il y a peu. De plus, la consommation mémoire, c'est le problème majeur de Java et ça risque de ne pas changer tout de suite, pour de profondes raisons d'architecture interne (genre le lock contenu dans chaque objet et l'aspect très dynamique du système de type).
[^] # Re: Des utilisateurs heureux de Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 2.
[^] # Re: Des utilisateurs heureux de Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -1.
[^] # Re: Des utilisateurs heureux de Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 0.
Tu es formidable. Tu te rends compte que tu as au mieux mélangé un peu tout et hop, en avance, tu évacues toute contestation par une sympathique accusation de mauvaise foi. Pathétique.
Donc, si j'ai bien lu entre les lignes, tu proposes de créer une classe abstraite avec une méthode bidule non virtuelle qui contient des tests (pré/post conditions, etc.) et qui appelle une méthode bidule_interne qui est elle virtuelle et privée.
Effectivement, en Java, on ne peut pas faire exactement ça pour deux raisons :
1) l'absence d'héritage mutliple fait qu'on ne peut pas faire ça pour plusieurs classes abstraites
2) la méthode bidule_interne ne peut pas être private mais protected (franchement, ce n'est pas un drame)
Et oui, les primitives de contrôle d'accès de C++ sont plus riches que celles de Java et le langage supporte l'héritage multiple. Je n'ai jamais dit le contraire. Ceci étant, explique moi en quoi ceci démontre la différence entre le final de Java et le virtual de C++ et on verra qui est le plus de mauvaise foi.
[^] # Re: Des utilisateurs heureux de Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 1.
Oui, oui, bien sûr. Puisque je te dis que c'est la même techno que celle de GJ (ce sont les mêmes auteurs) qui est testé littéralement depuis des années !
Je vais même te donner un exemple plus plus simple que je ne pensais au départ : une classe qui implémente proprement plusieurs interfaces. C'est possible en C++, c'est impossible en Java (on ne peut le faire que pour une interface). Proprement, bien sûr, c'est à dire que l'interface inclue le code de vérification pré/post condition.
Quel est le rapport avec final/virtual ? Tu peux implémenter plusieurs interfaces avec une même classe en Java, puisque justement la notion d'interface est faite pour : il n'y a pas de corps de méthodes dans les interfaces. Donc, je suppose que tu veux dire qu'en C++ tu peux écrire plusieurs classes abstraites (mélangeant des méthodes implémentées et des en-têtes seuls) et en hériter. Nous sommes d'accord, c'est l'héritage multiple qui n'existe pas en Java. Je vois bien l'intérêt que tu trouves à ça, mais toujours pas le rapport avec final/virtual. Donc, si tu donnais un exemple concret, ça serait peut être idéal. Je vais finir par croire que tu te fous de moi.
Et toi tu ferais pas mal de lire (ou plus dur : réfléchir) avant de répondre. Tiens lis donc ma remarque initiale pour voir à quel point tu réponds à coté.
La technologie qui permet les foncteurs existe de façon nettemment plus puissante en Java. L'implémentation proprement dite existe sous forme d'une bibliothèque open source (cf http://jga.sourceforge.net/(...)).
C'est bete, des langages utilisent cet idiome. Celui que tu présente s'appelle plutot « bidouille pour compenser une faiblesse ».
Quelle puissance dans l'argumentation. Note bien que je n'ai pas dit que c'était un mauvais idiome, juste qu'il était incompatible avec les langages à GC.
[^] # Re: Des utilisateurs heureux de Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 2.
Java 1.5 est disponible en version beta, tu peux tester. La plupart des concepts derrière l'implémentation actuelle datent de gj, une extension de Java qui a au moins 5 ou 6 ans et qui est une technologie très éprouvée. C'est du concret.
final et non-virtual c'est pas la même chose. Ah, ça y ressemble de loin, dans le détail non.
Et si tu ne vois pas le rapport avec les pré/post conditions vérifiées dans une interface, ton commentaire suivant sur « comprendre la conception objet » est assez comique.
Oui, oui, bien sûr. Donne un exemple et on va voir. Si ton seul argument est que C++ perd le type d'un objet passé par valeur, nous sommes d'accord, il y a bien une différence entre non virtual et final, mais si tu arrives à défendre ça en terme de conception objet, je te tire mon chapeau.
Non des foncteurs de C++. Mais là j'ai dit que je n'étais pas sûr de l'absence d'équivalent. Si tu en vois...
Classes anonymes et interface. Tu connais bien Java, ça fait peur. Tu n'a pas pratiqué depuis la version 1.1 ?
Oui en faisant un destructeur (c'est le terme générique) que l'on est obligé d'appeler manuellement avant de supprimer la dernière référence. Super propre.
T'as tout compris, ça se sent. C'est clair que quand on supprime la dernière référence en Java, on a la super classe et on connaît bien le langage. Aller, je suis de bonne humeur (faut dire que tu es très drole), je t'explique. Si un objet accapare une ressource unique qui doit être relachée à un moment ou à un autre, tu peux utiliser le destructeur de l'objet en C++ pour lui faire relacher cette ressource : c'est un idiome de programmation C++ qui vaut ce qu'il vaut. Il est totalement incompatible avec la notion même de GC dans laquelle on ne sait jamais quand on objet va être détruit (ce qui est bien plus efficace en terme de gestion de la mémoire, d'ailleurs). En Java et en général dans les langages avec GC, tu ne peux pas utiliser cet idiome, donc tu programmes proprement avec un autre idiome. Par exemple, tu fabriques un objet qui prend comme paramètre du code à faire tourner (implémenter par une classe anonyme), qui récupère la ressource, exécute le code, puis relache la ressource.
De toute manière, si tu as vraiment besoin d'utiliser des ressources uniques critiques, en général tu as vraiment intérêt à faire du J2EE car le serveur d'application gère ces ressources à ta place de façon très efficace. Mais j'oubliais que Java ne sert qu'à faire du web, idiot que je suis.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 0.
C'est sûrement moins efficace, mais ridicule, je dois dire que je ne comprends pas pourquoi, d'autant que la STL est très complexe à cause de la gestion mémoire. Et puis bon, les templates c'est dans java 1.5 qui est déjà disponible en version beta...
« final » peut être une solution mais pas toujours, ce n'est pas exactement la même chose.
Pourrais-tu détailler pourquoi ? J'ai fait pas mal d'années de programmation C++ et je t'avoue que je ne vois pas à quoi tu peux bien faire référence.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 1.
Sinon, je t'avoue que la prose de Stroustrup ne m'intéresse absolument pas. Ce brave homme a montré depuis des années qui ne connaissait absolument rien à ce que la recherche a produit dans le domaine des langages de programmation et le résultat est C++, plein de bonne volonté et plein d'erreurs de conception. Ca m'arrache le coeur de l'avouer, mais Microsoft a bien compris le problème et a donc embaucher des gens compétents dans le domaine pour faire C#, et franchement, ça se voit...
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 0.
Tu ne comprends donc rien. L'indirection obligatoire en Java fait qu'on ne peut pas économiser la mémoire et donc ça bouffe tes perfs même avec des usines à gaz comme Corba ou Swing (qui subissent elles aussi cette contrainte et donc sont encore plus des usines à gaz en Java que dans leur version C++). L'absence de l'équivalent des structs du C# en Java est une catastrophe en terme de performances à cause de la mémoire.
Ton probleme c'est que tu n'as qu'une vue locale de ce que tu developpes. Je suis d'accord avec toi que sur un algo bien precis il faut effectuer ce genre d'optimisation comme pour l'exemple que tu as cite. Mais d'une maniere generale, l'utilisation d'un formalisme de haut niveau tel que la programation distribuée ou par composants, les IHM, permettent un developpement plus rapide et de meilleur qualite au detriment des perfs (indirections, overhead inevitables)
Tu lis O1, c'est ça ? Je me demande comment tu utilises un formalisme de haut niveau alors que tu n'as rien compris à l'objet...
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 1.
- "C++ n'est pas objet car il ne supporte pas le typage dynamique" : n'importe quoi. Une telle déclaration prouve simplement que tu ne connais rien aux langages objets, en particulier certains des plus avancés comme Eiffel ou Objective Caml.
- "Dans un monde objet l'heritage n'a pas vraiment de sens" : désolé, mais là, ce n'est même plus n'importe quoi, c'est tout simplement débile
- "L'un des avantages est de ne plus avoir de table de fonctions virtuelles et de pouvoir ajouter a l'execution un nouvel objet. " : j'ai déjà répondu à ça, mais visiblement tu ne sais pas comment un modèle objet est implémenté (sur le hardware), donc ça ne sert à rien de continuer
- "De toute facon la notion d'objet, a mes yeux, n'est pas dependante du langage mais plutot de la facon dont le developpeur utilise les fonctionnalités du langage utilisé. Elles ne sont la que pour l'aider et formaliser syntaxiquement ce concept." : tu n'as encore rien compris, comme toutes les personnes qui prétendent faire de l'objet en C.
Bon, je m'arrête, ça suffira. Tu démontres pas ces posts que tu parles de choses que tu ne connais pas. Je n'ai aucun respect pour ça (soit dit en passant, tu m'indiques que je ne sais pas lire, ce qui n'est pas très respectueux non plus).
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 1.
[^] # Re: Des utilisateurs heureux de Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 0.
Java 1.5 propose des templates bien plus intéressants et propres que ceux du C++.
les fonctions automatiquement virtuelles : impossible de faire de la vérif de pré/post condition derrière l'interface, qui est l'endroit où les faire (ça ne doit pas être laissé à la classe qui implémente).
Qu'est-ce que c'est que ce délire ? Tu as déjà entendu parler de final qui permet de faire exactement la même chose que l'absence de virtual en C++ ? Et quel est le rapport avec les pré et post conditions ?
l'absence des foncteurs
De quoi parle tu, des foncteurs de caml ?
pas de surcharge d'opérateurs
Très gênant, nous sommes d'accord.
pas d'héritage multiple (oui ça sert à faire des choses propres)
C'est sûr, quand on ne comprend rien à la conception objet, c'est très utile.
les destructeurs dont l'appel n'est pas garanti
Il n'y a pas de destructeurs, mais des finalizers dont le but n'est absolument pas le même. De toute manière, si tu as besoin des finalizers, c'est certainement que tu devrais programmer ton appli autrement.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 0.
Parfaitement d'accord, d'autant qu'un bon compilateur (cf smalleiffel) est capable d'enlever lui-même l'aspect "virtuel" quand il peut démonntrer (si, si, il s'agit d'une preuve) qu'il n'en n'aura pas besoin à l'exécution. Mais bon, dès que quelqu'un te dit que les virtuels du C++ c'est super pour l'optimisation, tu dois détecter qu'il a dix ans de retard sur l'état de l'art en compilation des langages objets (et encore, 10 ans, je minimise). Les virtuels, c'est la plus grosse connerie du C++ avec l'absence de GC.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 2.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 1.
Le problème de Java est que tu ne peux pas faire autrement : tu ne peux pas manipuler les objets par valeur, même quand ça permet d'économiser de la mémoire et des perfs. Donc, oui l'indirection coûte quelque chose, à la fois en occupation mémoire et en perfs. Mais tu appliques servilement les préceptes de mauvais profs, donc tu ne comprends rien. Dans mes cours, tu aurais des sales notes.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 3.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 2.
1) il existe des techniques pour virer le verrou nécessaire au synchronized. C'est implémenté dans SableVM (http://www.sablevm.org/(...)).
2) des langages objets plus vieux de Java (Eiffel et Sather) ont une notion d'objets passés par valeur (et uniquement par valeur) qui ressemblent aux structs du C et qui permettent de régler le problème poser par Integer. Comme le typage devient 100% statique avec ces objets, on peut s'arranger pour qu'ils occupent exactement la place mémoire nécessaire. Pour les petits objets type Integer, ou nombre complexe, c'est la fête.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 2.
Non, les tests de Sather et Eiffel prouvent le contraire. Un objet passé par valeur ne supporte pas l'héritage, il n'y a donc pas de table de méthodes "virtuelles" à la C++. Un int Eiffel est un objet, mais il est manipulé comme un int natif dans le code engendré.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 2.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 1.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 1.
C'est faux. Eiffel et Sather considèrent les types de base comme objet sans perte de performance. Pour ce faire, il faut distinguer deux catégories d'objets (comme en C#), ces objets passés par référence et des objets passés par valeurs. Les types de base sont des objets passés par valeur, ce qui élimine les problèmes d'occupation mémoire et d'efficacité induit par l'autoboxing.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 1.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 2.
De plus, il existe une JVM open source et entièrement (ou presque) écrite en Java. L'ironie du sort veut qu'elle soit justement écrite par IBM (cf http://www-124.ibm.com/developerworks/opensource/jikesrvm/(...)). Les divers échos que j'en ai eu sont qu'elle tourne plutôt efficacement, à condition, comme toujours en Java, d'avoir une mémoire conséquente.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -1.
Ultra puissant, on remplace une table de fonctions virtuelles par un pointeur vers le type de l'objet. Quel gain remarquable !!! De toute manière, Java est typé à la compilation...
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 3.
Ceci étant, tu as parfaitement raison pour memcheck86, mais je crois que ton interlocuteur faisait une "petite blague" sur l'utilisation mémoire de Java, un vrai problème...
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par boubou (site web personnel) . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 1.
Ouai, sauf que c'est resté assez moche jusqu'à il y a peu. De plus, la consommation mémoire, c'est le problème majeur de Java et ça risque de ne pas changer tout de suite, pour de profondes raisons d'architecture interne (genre le lock contenu dans chaque objet et l'aspect très dynamique du système de type).