Discussion :

[super_navide]

pour revenir a c++ vs java
toutes les fonctionnalité suivantes sont absente de C++ ou présente mais de façon non standard ou par bidouillage


modifier code d'une méthode pendant l'execution
appeler une méthode dont le nom est connu que pendant l'execution du programme
modifier la valeur d'un attribut dont le nom est connu que pendant l'execution du programme
référence faible
objet proxy
génération de classe à la volé
serialization générique
introspection
class anonyme
thread built-in
anotation
portabilité
qualité et nombre des EDIS
swing
garbage collector
api de debug
bibliothéque gestion collection String etc... standard le
gestion des sockets

[super_navide]

a oui j'oubliai le merveilleux site de sun avec des docs précise et plein d'exemple
et aussi developpez.com

[gorgonite]

modifier code d'une méthode pendant l'execution

c'est possible en Java ???

objet proxy

corba ne marche pas en c++, ça se saurait

swing

y a pas java non plus en c++
mais y a du c en java

api de debug

ça reste à prouver...

bibliothéque gestion collection String

précises...

gestion des sockets

y a des sockets en c++, mais vu que le langage est plus bas niveau, on dépend un peu plus du système (win32 api, ou sockets unix), mais il existe des classes qui abstrairont cela

[gorgonite]

a oui j'oubliai le merveilleux site de sun avec des docs précise et plein d'exemple

ben la msdn le fait pour vc++
et la stl est largement documenté pour le c++ en général

et aussi developpez.com

précises... à moins que ce ne soit qu'un sacarsme

[kpouer]

c'est possible en Java ???

Euh en debug tu peux faire du hotswap, mais je sais pas si c'est de ca qu'il veut parler.

y a pas java non plus en c++
mais y a du c en java

D'ou la supériorité de java
Tu as aussi du Ruby, du python, du javascript

précises...

Je pense qu'il veut dire que java est livré avec des api variées et performantes pour gérer les Strings, les listes, les map qui conviennent a 90% des usages.
Ces api existent peut être aussi en C++, mais ne sont pas standard malheureusement.

y a des sockets en c++, mais vu que le langage est plus bas niveau, on dépend un peu plus du système (win32 api, ou sockets unix), mais il existe des classes qui abstrairont cela

C'est justement l'avantage de java : avoir des api standard d'abstraction pour bon nombre de choses, xml, base de données, ce qui fait que tu peux changer l'implémentation ton code est toujours valide, et aussi que n'importe quel codeur java peut relire ton code et le comprendre sans avoir a apprendre une nouvelle api

[gorgonite]

ben quitte à surcharger le code, il existe des librairies adéquates et standards en c++ pour faire de même... et je pense que si tout le monde apprenait à se servir correctement de la STL, il n'y aurait pas besoin de vouloir toujours réinventer la roue


ensuite, si Java est un système vérouillé par Sun, qui peut donc assurer une cohérence de ce qu'il propose dans ces JDK, cela restera vrai si l'on s'en tient à un éditeur de compilateur c++ donné...

[super_navide]

précises... à moins que ce ne soit qu'un sacarsme

developpez offre je trouve de meilleur et plus de tutorieux pour java

en C++ la MFC est en concurrence directe avec la STL


en java il y a 1 framework portable pour les IHMs il y a swing/awt puis c'est tous
en c++ il y a wxWidgets QT GTK++ etc...

c'est un vrai bazard ca part dans tous les sens (comme linux d'ailleurs )

en java il y a un socle qui grossit et qui est maitrisé et qui permet de faire bcp de chose

[gorgonite]

D'ou la supériorité de java
Tu as aussi du Ruby, du python, du javascript

tu n'as pas du comprendre ma remarque...
on se moque du nombre de langage utilisable via java, ou qui compile sur la JVM.... sinon on dirait que .Net écrase à plat de coutures Java, et on s'arrêterait là

[kpouer]

ben quitte à surcharger le code, il existe des librairies adéquates et standards en c++ pour faire de même... et je pense que si tout le monde apprenait à se servir correctement de la STL, il n'y aurait pas besoin de vouloir toujours réinventer la roue


ensuite, si Java est un système vérouillé par Sun, qui peut donc assurer une cohérence de ce qu'il propose dans ces JDK, cela restera vrai si l'on s'en tient à un éditeur de compilateur c++ donné...

La force de Sun est surtout d'avoir apporté une api extrêmement complète dans énormément de domaines, et je crois pas qu'il y ait quelqu'un qui ait proposé une api aussi large et cohérente (a part peut être .NET), mais aussi totalement multiplateforme

[gorgonite]

developpez offre je trouve de meilleur et plus de tutorieux pour java

ben c'est juste que les contributeurs java sont plus nombreux, ou plus actifs, ou plus bavards... choisis la version qui t'arrange

en C++ la MFC est en concurrence directe avec la STL

il existe pleins de librairies java qui concurrencent celles de Sun, mais on est pas obligé de les utiliser... tout comme avec la MFC

en java il y a 1 framework portable pour les IHMs il y a swing/awt puis c'est tous
en c++ il y a wxWidgets QT GTK++ etc...

et SWT, c'est du flan ?

c'est un vrai bazard ca part dans tous les sens (comme linux d'ailleurs )

si par bazard, tu entends qu'il est possible à chacun de devenir expert sans pourtant utiliser les trucs des autres... pourquoi pas. mais cela ne sera-il pas aussi le cas de Java dès que Sun aura (enfin) libéré le code source sous une vraie licence libre


ps: ne mèles pas Linux à ce débat, sinon ça va dégénérer

[gorgonite]

La force de Sun est surtout d'avoir apporté une api extrêmement complète dans énormément de domaines, et je crois pas qu'il y ait quelqu'un qui ait proposé une api aussi large et cohérente (a part peut être .NET), mais aussi totalement multiplateforme

ben d'autres API existent en c++ et peuvent concurrencer celle de Sun
le fait de dire qu'elles sont totalement multi-plateformes me fait sourire... je pense que plus de plate-forme sont supportées par les divers compilo c++ respectant la norme que par les portages de la JVM par Sun

[Jean-Marc.Bourguet]

Je pense qu'il veut dire que java est livré avec des api variées et performantes pour gérer les Strings, les listes, les map qui conviennent a 90% des usages.
Ces api existent peut être aussi en C++, mais ne sont pas standard malheureusement.

Mince... on a oublie de me dire qu'on les avait enlevees?

C'est justement l'avantage de java : avoir des api standard d'abstraction pour bon nombre de choses, xml, base de données, ce qui fait que tu peux changer l'implémentation ton code est toujours valide, et aussi que n'importe quel codeur java peut relire ton code et le comprendre sans avoir a apprendre une nouvelle api

Je suis d'accord que c'est un avantage. C'est d'ailleurs avoir fait qu'un nouveau langage sans une bibliotheque importante n'est plus reellement envisagable est un des deux apports principaux de Java a mon avis (le deuxieme etant d'avoir rendu le GC mainstream).

Mais il ne faut pas oublier les problemes qu'une standardisation prematuree posent (le C++ ayant les problemes d'une standardisation trop tardive): on se retrouve avec des scories dont on ne peut pas reellement se debarasser parce qu'on n'a pas la structure correcte du premier coup (si j'ai bien suivit, Java a deux interfaces graphiques standard, 2 systemes d'IO, 2 systemes de conteneurs, ...)

[super_navide]

Euh en debug tu peux faire du hotswap, mais je sais pas si c'est de ca qu'il veut parler.




D'ou la supériorité de java
Tu as aussi du Ruby, du python, du javascript



Je pense qu'il veut dire que java est livré avec des api variées et performantes pour gérer les Strings, les listes, les map qui conviennent a 90% des usages.
Ces api existent peut être aussi en C++, mais ne sont pas standard malheureusement.



C'est justement l'avantage de java : avoir des api standard d'abstraction pour bon nombre de choses, xml, base de données, ce qui fait que tu peux changer l'implémentation ton code est toujours valide, et aussi que n'importe quel codeur java peut relire ton code et le comprendre sans avoir a apprendre une nouvelle api

c'est le package instrumentation qui permet de modifier une méthode pendant l'execution et de faire plein d'autre chose que j'ai pas trop regarder

objet proxy je parle la classe Proxy en java qui permet d'intercepter les appel de méthode

[kpouer]

ben d'autres API existent en c++ et peuvent concurrencer celle de Sun
le fait de dire qu'elles sont totalement multi-plateformes me fait sourire... je pense que plus de plate-forme sont supportées par les divers compilo c++ respectant la norme que par les portages de la JVM par Sun

Tu as des apis en C++ qui t'apportent du sql, xml, socket, gestion io, de strings, de collections en même temps ?
Ou tu en as une pour le sql, une pour le xml, une pour le socket, et a chaque fois que tu veux faire un truc nouveau tu vas chercher la bonne api a utiliser ?

Sinon pour SWT, oui je dirais que c'est du flan, clairement je trouve le concept mauvais.
Et il est vrai qu'une standardisation trop précoce a conduit a avoir 2 api pour faire des GUI, mais est ce que c'est vraiment un problème ?
L'une évolue, l'autre pas, on utilise la nouvelle et l'autre reste là pour les besoins de compatibilité, c'est pas si grave non ?

[super_navide]

il y a aussi Java Platform Debugger Architecture (JPDA) une api pour faire un programme en java pour debugger un autre programme java

[gorgonite]

Tu as des apis en C++ qui t'apportent du sql, xml, socket, gestion io, de strings, de collections en même temps ?
Ou tu en as une pour le sql, une pour le xml, une pour le socket, et a chaque fois que tu veux faire un truc nouveau tu vas chercher la bonne api a utiliser ?

il existe des api qui gèrent la majorité de ces points....
io, collection et string sont déjà dans la STL... donc pas besoin d'aller chercher plus loin
en ce qui concerne le XML, il manque aussi pas mal chez Sun... et on va chercher des bouts chez apache (en autre le xi:include)

en ce qui concerne le nombre d'api... celles de Sun ont beau être cachées, il s'agit de projets différents, qui ne sont pas systématiquement tous mis à jour dans la J2SE fourni

Sinon pour SWT, oui je dirais que c'est du flan, clairement je trouve le concept mauvais.

tu en parleras aux gens d'eclipse... c'est à mon avis, le seul moyen de faire des GUI efficace sous Java

Et il est vrai qu'une standardisation trop précoce a conduit a avoir 2 api pour faire des GUI, mais est ce que c'est vraiment un problème ?
L'une évolue, l'autre pas, on utilise la nouvelle et l'autre reste là pour les besoins de compatibilité, c'est pas si grave non ?

ben ça contredit surtout ce que vous affirmiez avant...

[kpouer]

tu en parleras aux gens d'eclipse... c'est à mon avis, le seul moyen de faire des GUI efficace sous Java

Bof je vois pas vraiment pourquoi. On trouve des softs en Swing bien plus performants qu'Eclipse. Alors peut être qu'Eclipse est un mauvais ambassadeur de Swing.
D'ailleurs j'utilise pas Eclipse (pourtant j'ai essayé). J'ai eu le malheur d'essayer Intellij Idea avant Eclipse, et après avoir essayé ca on reviendrait pour rien au monde a un autre IDE. Comme je dis toujours, tant qu'a pas utiliser Idea pour faire du java, autant utiliser notepad.

ben ça contredit surtout ce que vous affirmiez avant...

J'ai du mal a voir en quoi ca contredit. Il y a 2 api donc on s'en sort pas pour choisir ?
Ben le mec qui hésite entre faire de l'AWT ou du Swing, je lui conseille de changer de métier ...

[super_navide]

il y a point que j'aime pas dans java c'est le poid des EDI comme netbeans 100 Mo en mémoire c'est bcp

les EDIS C++ sont il plus léger ???

[adiGuba]

on se retrouve avec des scories dont on ne peut pas reellement se debarasser parce qu'on n'a pas la structure correcte du premier coup (si j'ai bien suivit, Java a deux interfaces graphiques standard, 2 systemes d'IO, 2 systemes de conteneurs, ...)

En effet c'est un problème intéressant que tu soulèves là, et la solution n'est pas forcément évidente si on veut conserver un tant soit peu de compatibilité ascendante...

D'ailleurs on retrouve logiquement le même problème dans .NET (les templates ont aboutis à la création d'une nouvelle API de collections), mais plus généralement dans toutes les librairies...


Je ne pense pas qu'il existe un langage qui apporte une solution élégante à ce problème tout en conservant une compatibilité ascendante...

(cela sort un peu du débat mais c'est très pertinent je trouve )

c'est à mon avis, le seul moyen de faire des GUI efficace sous Java

Swing permet aussi de faire des GUI efficace... il suffit de ne pas programmer comme un porc


a++

[gorgonite]

Swing permet aussi de faire des GUI efficace... il suffit de ne pas programmer comme un porc

merci je retiens...