L'introspection n'est pas possible en C++. Et c'est certainement l'une des features les plus puissantes de Java/C#. Et il n'y a pratiquement pas une librairie en Java qui ne l'utilise pas d'une manière ou d'une autre.Envoyé par Alp
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
L'introspection n'est pas possible en C++. Et c'est certainement l'une des features les plus puissantes de Java/C#. Et il n'y a pratiquement pas une librairie en Java qui ne l'utilise pas d'une manière ou d'une autre.
On peut l'approcher, comme je l'ai mentionné plus haut.
Mais c'est fichtrement complexe et pas aussi abouti que si ç'avait été de base.
Après avoir fait quelques années de C++ et un peu plus de 2 ans de Java, je trouve que ce n'est pas tant le langage lui-même que tout l'écosystème qu'il y a autour qui rend la plateforme (nettement) plus productive: les IDE surpuissants, les API comme s'il en pleuvait (il y en a trop). En faisant un peu de veille, on trouve des librairies et des outils intéressants tous les jours, par exemple la librairie de messagerie Kilim, découverte aujourd'hui au détour d'un Google Tech Talk, qui surpasse en performance les agents d'Erlang, ou encore Terracotta, une couche qui permet de faire du clustering de JVM, où N JVM tournant sur N serveurs sont vues comme une seule par une appli. Comme rappelé par le créateur de Terracotta, c'est rendu possible parce qu'au départ, la spec de la JVM est excellente (ce qui n'est pas forcément le cas de la spec du langage lui-même).
Un autre truc que j'aime avec les langages tournant sur machine virtuelle, c'est la possibilité d'utiliser plusieurs langages en même temps. On peut ainsi intégrer très facilement un interpréteur ou un compilo dans son programme. Si je trouve Java trop limité, je peux faire du Scala (un langage fonctionnel objet aussi rapide que le Java) ou du JRuby, par ex, et ils accèderont à toutes les libs Java et à mes classes compilées tout aussi simplement qu'à partir de Java.
Ça veut dire : pas particulièrement rapide ce que tu viens de dire
Ok ok c'est un peu trollesque... mais pas complètement faux -_-
Bah, tout dépend de ce que l'on cherche à faire, bien entendu. Perso, je dirais que le temps où le Java était lent est à peu près révolu. Bien sûr, il reste plus lent que C++, D, voire Object Pascal, mais pour bcp d'applications:
- les gens sont près à sacrifier une partie des performances pour une facilité de développement accrue,
- la JVM facilite le développement multithread, ce qui est un avantage très important aujourd'hui
- la performance finale de l'appli est plus dépendante de la façon dont elle est codée que du langage sous-jacent. En Java, les API visent l'optimisation à grande échelle (on préférera une archi scalable), et non l'optimisation locale.
Le style de développement Java est finalement très différent de celui du C++. D'un point de vue conception, je constate qu'un gros projet Java reste plus facilement sous contrôle qu'un gros projet en C++, - une raison de plus pour laquelle les entreprises en sont particulièrement friandes -. En revanche, en Java, on a un peu trop tendance à user et abuser de solutions complexes et de patterns en tout genre sans trop se soucier de l'impact négatif sur les perfs que provoque l'accumulation d'indirections et de dizaines d'appels de fonctions empilés, là où en C++, ça reste bcp plus raisonnable. Cette tendance est flagrante dans les applis JEE sur serveurs d'applications. Mais si on fait une appli en "pur Java", codé à la mimine comme on le ferait en C++, en évitant de cumuler les API en tout genre, on peut avoir des perfs tout-à-fait respectables.
En revanche, Java est tjrs aussi consommateur de ressources, et ça, j'ai l'impression que ça n'est pas près de changer.
Ce débat me fait penser au débat sur les jeux vidéos et les graphismes. Est-ce que les belles images font qu'un jeu est mieux qu'un autre ? non et bien c'est pareil avec la rapidité d'un programme, on s'en fou un peu du moment que c'est raisonnable sauf dans les applications qui demandent une optimisation de la consommation des ressources.
Ha bien non en s'en fou pas de la rapidité d'un programme !
Lorsque j'utilise une application faite en Java, je ressent vraiment une grosse différence comparé au programme faire en C ou C++.
Avec des temps de démarrage long, et surtout une consommation mémoire démesuré !
Il n'y a pas a pinailler la dessus, les programmes fait en Java sont long au démarrage, un peu moins rapide et surtout utilise ENORMEMENT plus de mémoire !
Ca peu avoir plus ou moins d'impact suivant la grandeur du projet, mais ca reste un inconvénient !
En ce qui concerne la mémoire c'est un peu plus compliqué que celà. De fait il est vrai que java consomme plus de mémoire, mais la conso mémoire montrée dans les outils de monitoring en ce qui concerne java n'est pas forcément la conso réelle. EN effet la VM alloue un espace mémoire spécifique minimal qui sera utilisé par l'application. L'applicaiton java peu de fait utiliser moins de mémoire que ce qui est annoncé au niveau de la table des process sous linux ou du gestionnaire des tâches sous windows. Tout dépend de configuré l'appli au démarrage. Bon ensuite pour des monstres du genre eclipse ou netbeans c'est une autre histoire, mais là on entre dans l'artillerie lourde. Mais il est plus que fréquent qu'une appli java consomme moins de mémoire que firefox qui, si je ne m'abuse, est codé en C/C++ et était (dans sa version 2 en particulier) un vrai gouffre à mémoire (bon pour la 3 ça s'est amélioré, mais çà reste au dessus d'une appli java standard).
faudrait avoir un navigateur web aussi complet codé en Java pour pouvoir comparer... parce que honnetement un demineur en Java consomme moins que Firefox qui est en C++, mais j'ai un doute sur la valeur du test
La dessus on est d'accord, mais je pensait plus à une appli genre client SQL qui n'est pas forcément légère (SQuirrel ou ce genre d'applis qui consomment un tant soit peu quand même)faudrait avoir un navigateur web aussi complet codé en Java pour pouvoir comparer... parce que honnetement un demineur en Java consomme moins que Firefox qui est en C++, mais j'ai un doute sur la valeur du test
L'interface graphique de firefox est en XUL, en plus... Ca aide pas côté perfs.
et pourquoi???
perso, je développe des applis en XUL (extension firefox ou appli xulrunner), et je n'ai pas de problème de perfs... si l'on utilise les composants XPCom intelligemment, et qu'on évite de faire du JS pour les morceaux critiques, ça marche plus bien
Par rapport à une appli C++ sans XUL, ça aide pas.
Plus clair ?
Si le c++ est si bien, si rapide, si c'est vraiment le must, pourquoi alors toutes les applications ne sont pas codée en C++ ?
Une des raisons principales est sa "complexité" (certains arrivent à s'y faire et l'adore, d'autres non). Il s'avère aussi que l'on a en général plus de code à écrire que dans un langage tel que Python par exemple.
Il faut bien comprendre qu'un langage de programmation n'est jamais que l'expression de l'idée qu'une (ou plusieurs) personne(s) se fait de ce que devrait être le moyen de comprendre d'un ordinateur.
L'optique du C++ peut se résumer à peu près en quelques points:
- être compatible "aussi facilement que possible" avec le code C
- apporter "aussi peu" de restrictions que possible
- laisser l'utilisateur libre de ses choix (en ce compris la liberté de faire une c...
), et libre de "payer" le cout des méthodes qu'il permet ou non
- Sans doute l'un ou l'autre que j'aurais oublié...
L'optique de java a été différente, et pourrait se résumer à quelques points également:
Comme il ne faut pas oublier que, dans des conditions identiques (machine, OS, ...) pour effectuer quelque chose de strictement identique, au final, il faudra utiliser exactement la même suite d'instructions processeurs, ces points de vue fondamentalement différents vont impliquer une manière de programmer fondamentalement différente... Et sans doute intéresser des personnes au caractère fondamentalement différent.
- tout est objet
- le système gère la mémoire
- tout est constant
- tout est d'office "thread safe"
- sans doute l'un ou l'autre que j'ai oublié
Du point de vue du programmeur, qui n'est malgré tout qu'un homme, le choix personnel du langage (donc en dehors de toute contrainte "imposée" par une autre personne) se fera en effet en grande partie en fonction des responsabilités qu'il décide de prendre et de celle qu'il décide de "déléguer" au langage lui-même, et ce choix ne pourra être que purement subjectif.
Du point de vue du responsable du choix d'un langage de programmation, soit nous avons affaire à un programmeur "expérimenté" qui aura alors tendance à imposer le langage qu'il préfère, soit nous avons affaire à une personne n'ayant pas d'avis personnel (sans doute parce que cela ne fait pas vraiment partie de ses préoccupations) et qui se laissera influencer par les effets d'annonce, la communication qui se fait au sujet des langages (vraisemblablement sans savoir déterminer ce qui est vrai du faux) ou... pourquoi pas, par un "extrémiste" ou l'autre qui lui aura soufflé que "tel langage est le meilleur que j'ai jamais connu".
Au final, et ainsi que je l'ai signalé depuis bien longtemps, on se rend compte que l'appréciation que l'on peut faire d'un langage sera toujours très subjective et que ce qui sera ressenti comme un avantage par certains peut être ressenti comme un inconvénient par d'autres, et inversement...
Ce n'est que pour cette seule raison que tous les langages (car le débat pourrait s'étendre à l'ensemble des langages) fédèrent un certains nombre d'aficionados et un certain nombre d'opposants.
Une chose est sure, un programmeur "engagé" dans la préférence "à tout prix" d'un langage créera toujours un code plus correct et efficace dans le langage qu'il maitrise que dans le langage qu'il considère comme "moins bon"...
J'ai envie de dire que maintenant, pour le C++, ya 2 écoles.
L'avant STL/Qt/Boost, et l'après.
Avec la 2e école, on s'y fait très très bien avec le C++.
Euh tout n'est pas objet dans java (types primitifs, et on peut même envisager de faire du pseudo procédural si on utilise du statique dans tout les sens.
Tout est constant: que veux tu dire par là?
Tout est d'office thread safe: ou pas, AWT et Swing (les toolkits graphiques) ne le dont pas, pas plus qu'un bon nombre de collections et ainsi de suite, sinon pourquoi aurait on l'API de concurrence, les mots clefs synchronize & cie?
salut,l'avantage de java c'est la portabilité,plus simple,le graphisme,et pour l'inconvegnent c'est qu'il na pas la gestion des pointeurs et il'est résever au web seulement,pour le c++ son avantage c'est les pointeurs est il'est réserver pour les OS mais malheuresement il n'st pas universel.
salut,le c ou c++ est la base de tous les OS,java c'est pour les le web et c ou c++ c'est pour les system d'exploitation.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager