Discussion :

[OmbreHardcore]

En C++, les tableaux dynamiques et associatifs existent en standard (je pense aux std::map et std::vector).

Autant pour moi, mes connaissances en C++ sont TRES légères. Je viens du monde PHP à la base, et c'est lorsque j'ai souhaité me mettre au C/C++ que j'ai découvert le D... Par contre, en D, les tableaux associatifs/dynamiques sont intégrés au langage même (ils font partie de la syntaxe de base comme en PHP), pas dans la bibliothèque standard comme ça semble être le cas en C++.

Suis pas tout à fait d'acord car ce qui d'après moi fait la force de java: haut niveau de standardisation des bibliothèques, diversité et richesse des frameworks, IDE, et applications open sources en général..
Tout cela est je crois pour le moment presque absent dans le D.

D est un langage assez jeune, et qui n'a pas l'appui commercial et marketing d'une grosse boîte. Il est donc normal que les outils dédiés au D soient encore assez rare. C'est encore un langage très confidentiel : j'en ai entendu parlé il y a seulement quelques semaines...

Mais je tiens toutefois à préciser que la communauté D est très active et qu'il y a suffisamment d'outils disponibles pour envisager son emploi. Je vous invite à consulter le site http://www.dsource.org qui fournit déjà un beau panel de projets exclusivement consacrés au D.

Pour être plus précis, ces projets ont retenu mon attention :
- Descent, un plug-in Eclipse basé sur JDT. Pas aussi complet que JDT, mais largement suffisant pour coder avec confort (et puis, Eclipse est mon IDE préféré !). Le principal est là : coloration/validation syntaxique et intégration d'un debugger.
- Tango, une bibliothèque d'exécution (runtime library) qui se veut être la remplaçante de Phobos (la bibliothèque standard, suffisante mais indigne d'un tel langage).
- Tioport et DWT qui sont des portages respectifs de Java Standard Edition et de Standard Widget Toolkit (SWT). Ces bibliothèques laissent entrevoir de nombreuses adaptations futures des bibliothèques Java.

Je pense donc que le débat sur le choix entre C++ et Java devrait être élargit.

[millie]

Je pense donc que le débat sur le choix entre C++ et Java devrait être élargit.

Le débat concerne uniquement les langages Java et C++. Si tu souhaites discuter sur le langage D, je t'invite à rejoindre la discussion suivante : Que pensez-vous du langage D ?

[bountykiller]

aujourd,hui, le marché peut nous apporter quelques reponses concernant le debat C++/java.

la plupart des grands comptes se munissent d'application java, le marché de l'informatique en france est gravement porté sur le java et tous ses frameworks.
aujourd'hui le marché pousse à l'innovation ce qui est une des caracteristiques du monde java , on ne peut recenser combien de produit opensource et de frameworks sorte chaque jour dans le monde java.mais quand est il du C++, à part dans la recherche je ne vois plus l'interet de coder en C++, car aujourdhui dans un monde regi par le profit, la rapidité n'est plus la priorité(surtout que java tend a rattraper le C++ a ce niveau la) mais à la maintenabilité et la portabilité, les grands comptes cherchent surtt le gain d'argent dans leur developpement d'application, et il est clair quand terme de maintenabilité et d'evolution, aujourdhui java regne en maitre. D'ailleurs meme les universités et les ecoles d'ingenieur n'enseigne plus vraiment le C++ ce qui est un signe non?

JE NE SUIS PAS D'ACCORD (au moins comme ça c'est clair )
Personnellement, je n'attends de voir ce que le marché décide pour me faire un avis quand à la qualité d'un langage de programmation. Et surtout, le fait qu'un langage soit largement répendu ne signifie pas pour moi qu'il est meilleur qu'un autre (du moins, pas du point de vue technique).
J'admet qu'actuellement java joui d'un soutien plus important et que de nombreux projets et frameworks, notament open source, sont basés dessus. J'admet également que, de ce fait, java puisse être plus rentable que c++ pour certains projets. Cela étant dis, je continue de considérer le c++ comme un langage plus puissant et plus évolué que java, et je ne peux que déplorer le fait qu'il y est actuellement moins de projet basés sur le c++ qu'il n'y en a basé sur java.
J'irai même plus loin en me demandant si le problème ne vient pas du fait que c++ est un langage issu d'un consortium, et n'a dès lors pas de société qui le pousse réellement en avant contrairement au java avec Sun, ou encore au .Net avec Microsoft (par exemple).

[epsilon68]

je pense que le Java est plus utilisé dans les sociétés de services ou les projets ont une durée de vie de 1-2 ans.

pour les gros logiciels (plusieurs années de durée de vie), ca reste du C++

[Jean-Marc.Bourguet]

pour les gros logiciels (plusieurs années de durée de vie), ca reste du C++

Les gros logiciels sur lesquels j'ai travaille, c'etait a chaque fois un melange de langages. Generalement, les plus vieilles couches sont en C et en Fortran. La plus recente en C++. Sans parler de langages d'extensions genre TCL/dialecte de lisp.

J'ai vu des projets qui ont utilise du Java dans ce cadre, mais ils en sont revenus/en train de revenir et donc reecrit en C++ ce qui l'avait ete au depart en Java.

Je me mefie beaucoup des effets de perspective. Ce n'est pas parce qu'autour de soi tout le monde a un meme comportement -- ou pire qu'on detecte une tendance plus ou moins claire -- que c'est universel. On a tendance a frequenter que des gens qui ont les memes interets.

La pratique est a mon sens plus diversifiee qu'on le pense. Par exemple le premier gros projet sur lequel j'ai travaille etait totalement ecrit dans un langage quasiment inconnu (MAINSAIL); il y avait en projet de passer au C++, mais ca ne s'est jamais fait (la boite a ete rachetee et le projet arrete, le langage n'ayant pas ete a ma connaissance un facteur).

[souviron34]

Je ne pratique ni l'un ni l'autre, quoique j'ai un peu regardé Java puisque je suis beaucoup sur les IHM. mais donc je n'interviendrais pas dans ce débat, mais juste j'approuve absolument ce que vient de dire Jean-Marc, et en particulier :

...
Je me mefie beaucoup des effets de perspective. Ce n'est pas parce qu'autour de soi tout le monde a un meme comportement -- ou pire qu'on detecte une tendance plus ou moins claire -- que c'est universel. On a tendance a frequenter que des gens qui ont les memes interets.
..

Je me souviens qu'en 1986 quand je suis rentré dans l'industrie les jeunes tout frais sortis des formations d'informatique ne juraient que par Pascal, et qu'il me fallait me battre pour dire qu'on pouvait faire en Fortran ou en C.

Et pourtant , à l'époque, que ce soit les formations ou du coup les embauches de jeunes ne sélectionnaient que par le Pascal.

Et, qu'en est-il 20 ans plus tard ?

Qui travaille aujourdhui sur le portage ou la mantenance d'une appli en Pascal ???

J'avoue que j'ai un peu la même attitude vis-à-vis des .net, c#, C++, et autres du même acabit... Peut-être le temps me donnera-t-il tort, mais à l'heure actuelle je suis prêt à parier que l'on assiste au même phénomène...

[davcha]

J'avoue que j'ai un peu la même attitude vis-à-vis des .net, c#, C++, et autres du même acabit... Peut-être le temps me donnera-t-il tort, mais à l'heure actuelle je suis prêt à parier que l'on assiste au même phénomène...

Tu veux dire que l'engouement actuel pour les environnements managés est similaire (c'est à dire s'explique de la même façon) que l'engouement pour Pascal en 86 ?

Si c'est le cas, j'aimerais bien savoir ce qu'apporte pascal exactement comparé au C...
Ce que je veux dire, c'est que les environnements managés, que ce soit .NET ou Java, ou encore les langages orientés objets, comme C++... Tout ceci a apporté quelque chose (parfois pas que du bon, ok :p) par rapport à ce qu'on avait avant.
En revanche, Pascal... Je le vois plus comme une alternative au C, non ?

En clair, l'engouement pour pascal en 86 était peut-être davantage dû à un effet de mode, alors que l'engouement pour les environnements managés - même si ces environnements subissent quand même un effet de mode (normal...) - s'explique peut-être davantage parce qu'ils apportent un vrai plus, par rapport à ce qu'on avait avant...

Non ?

[souviron34]

Etant scientifique de formation, je suis élevé avec le doute...

Et par conséquent je doute fortement quand on me dit "LA solution, c'est ça"...

Quel que soit le "ça".

En gros, je ne conteste pas que des outils puissent aider, ce dont je doute c'est que l'on y voie la solution générale.. Des IHM (et j'en ai fabriqué un certain nombre...) qui marchent très bien, des programmes qui marchent très bien, sont / ont été faites(faits) avec juste un éditeur de texte....

Si on est bon, on est bon quel que soit l'outil. Réciproquement si on est mauvais...

Ce que je pense dans le fond c'est que ces environnements "managés" comme tu les appelles permettent de prétendre que n'importe qui peut faire des programmes/des IHM.. Or, il suffit de voir les interventions sur ce site pour s'apercevoir que pour beaucoup, ils manipulent, oui, mais ils ne SAVENT PAS ce qu'ils manipulent...

Donc je ne sais pas si c'est un bien......

[MODE=1/2 troll]
En grande partie à mon avis c'est surtout que ça permet de prendre des bacs+2 ou bacs au lieu d'ingénieurs, et donc de moins les payer....
[/MODE =1/2 troll]

Quant au Pascal, je le citais juste comme exemple de mode et de ce que "la communauté informatique" n'est pas une référence... Toutes les écoles ne juraient que par ça, on ne trouvait pas un jeune qui connaisse autre chose, et .... pofffffff ...

[Mat.M]

[MODE=1/2 troll]
En grande partie à mon avis c'est surtout que ça permet de prendre des bacs+2 ou bacs au lieu d'ingénieurs, et donc de moins les payer....
[/MODE =1/2 troll]
.

il y a quelques temps j'avais affirmé que Java était le langage par excellence pour les projets délocalisés et d'outsourcing ( comme le devient .NET d'ailleurs ) ce qui avait déclenché quelques polémiques

[kisitomomotene]

Etant scientifique de formation, je suis élevé avec le doute...

Et par conséquent je doute fortement quand on me dit "LA solution, c'est ça"...

Quel que soit le "ça".

En gros, je ne conteste pas que des outils puissent aider, ce dont je doute c'est que l'on y voie la solution générale.. Des IHM (et j'en ai fabriqué un certain nombre...) qui marchent très bien, des programmes qui marchent très bien, sont / ont été faites(faits) avec juste un éditeur de texte....

Si on est bon, on est bon quel que soit l'outil. Réciproquement si on est mauvais...

Mais les environnements actuels augmentent la productivité. Avec un editeur de texte, on peut bien obtenir des bons résultats, mais si la machine peut effectuer certaine tâche rebarbative à notre place, je trouve que c'est du progrès, et cela n'a rien à voir avec le fait qu'on soit bon programmeur ou mauvais.

[kpouer]

Tout a fait d'accord avec Millie, lors des études (école d'ingé comme université) on apprend surtout a réfléchir et a s'adapter. De toute facon faut se dire qu'une bonne partie de ce qu'on apprend devient vite obsolète, on apprend le C++ ou le java, mais dans 10 ans, qui sait si ces langages n'auront pas été dépassés, remplacés et ne serviront plus que sur des marchés de niche ou de vieux projets comme le cobol aujourd'hui ...
de toute facon j'ai jamais vu un jeune diplomé qui soit vraiment bon a sa sortie d'école. Ce qui fait qu'il est bon, c'est en général pas ses connaissances mais plutot sa curiosité, son ingéniosité et sa capacité d'adaptation

[epsilon68]

suite au projet java tournant sur une sun,
j'ai recemment été tres ennuyé par son occupation mémoire...

j'avais en gros une boucle sur une grosse liste de fichiers, et a chaque tour de boucle, je mettais en memoire le fichier... sauf que la memoire montait jusqu'a exploser. J'ai resolu le probleme en utilisant un stringbuffer.... heureusement que ca a marché !!! je tourne a 40Mo maintenant alors que 128 Mo ne suffisait pas ...

en C++ je n'aurais jamais eu ce probleme !
la memoire deterministe me manque beaucoup !

le garbage a quand meme beaucoup de probleme a liberer vite les objets. Alors maintenant je commence quand meme à vraiment douter de ces capacités...

sinon je suis plus que d'accord avec le post precedent.

[kpouer]

suite au projet java tournant sur une sun,
j'ai recemment été tres ennuyé par son occupation mémoire...

j'avais en gros une boucle sur une grosse liste de fichiers, et a chaque tour de boucle, je mettais en memoire le fichier... sauf que la memoire montait jusqu'a exploser. J'ai resolu le probleme en utilisant un stringbuffer.... heureusement que ca a marché !!! je tourne a 40Mo maintenant alors que 128 Mo ne suffisait pas ...

en C++ je n'aurais jamais eu ce probleme !
la memoire deterministe me manque beaucoup !

le garbage a quand meme beaucoup de probleme a liberer vite les objets. Alors maintenant je commence quand meme à vraiment douter de ces capacités...

sinon je suis plus que d'accord avec le post precedent.

Oui, ton problème est simplement du a une mauvaise utilisation du langage java. Tu dois mieux connaitre le C++ et effectivement tu t'es fait avoir en java sur un truc qui ne t'aurai pas posé de problème. A l'inverse quelqu'un connaissant bien java aurait réussi son coup alors qu'en c++ il aurait peut être eu des fuites mémoires. Bref il faut connaitre les astuces de chaque langage.
D'ailleurs tu n'as pas du y gagner qu'en mémoire mais aussi en vitesse car il y a pas photo entre un StringBuffer (ou un StringBuilder) et une concaténation de Strings.

[epsilon68]

D'ailleurs tu n'as pas du y gagner qu'en mémoire mais aussi en vitesse car il y a pas photo entre un StringBuffer (ou un StringBuilder) et une concaténation de Strings.

ce n'est pas la difference de StringBuilder et concatenation de String.
C'est la reutilisation d'un buffer qui fait que c'est bon maintenant.

Merci de me dire que je connais mal le Java
honnetement je ne pense pas, mais bon ...

Aussi je voulais dire que dans mon cas j'ai eu de la chance de "pouvoir" utiliser un StringBuffer, parce que si dans mon traitement il aurait fallu un String, j'étais fichu !

Comme quoi il manque de toute facon une liberation memoire déterministe.

[kpouer]

A vrai dire j'ai du mal a comprendre ce que tu entends par "jusqu'à exploser". un OutOfMemory ? A ce moment c'est étonnant car a priori si cette erreur est levée, c'est qu'il n'y a réellement aucun objet collectable a ce moment là. Si c'est juste que l'utilisation mémoire augmente trop a ton gout, c'est je pense du a un choix de java qui est de privilégier les performances et donc de ne collecter que si c'est réellement nécéssaire. Sinon je ne voulais pas être désagréable sur tes compétences en java, je voulais juste dire qu'on progresse tous les jours.
A propos du StringBuffer encore, en principe si tu lui fais un toString() tu auras ta String que tu aurais pu utiliser aussi si tu en avais eu besoin plutot qu'un StringBuffer, et cela n'aurait pas occupé beaucoup de mémoire car elle utilise le même char[]que le StringBuffer (tant que le StringBuffer n'est pas modifié, a ce moment son char[] est dupliqué, il est même parfois conseillé de réinstantier les StringBuffer car leur taille ne peut jamais diminuer)

[epsilon68]

c'est je pense du a un choix de java qui est de privilégier les performances et donc de ne collecter que si c'est réellement nécéssaire.

c'est ce que je dis, il manque une methode deterministe pour liberer la memoire

Sinon je ne voulais pas être désagréable sur tes compétences en java, je voulais juste dire qu'on progresse tous les jours.

attention de ne pas sous-estimer les gens

en principe si tu lui fais un toString() tu auras ta String que tu aurais pu utiliser aussi si tu en avais eu besoin plutot qu'un StringBuffer, et cela n'aurait pas occupé beaucoup de mémoire car elle utilise le même char[]que le StringBuffer

d'accord mais ce n'est pas garanti
(je ne l'ai cependant pas testé sur le server sun et il faut toujours se mefier des details à l'implementation)

public String toString()

Converts to a string representing the data in this string buffer. A new String object is allocated and initialized to contain the character sequence currently represented by this string buffer. This String is then returned. Subsequent changes to the string buffer do not affect the contents of the String.

Implementation advice: This method can be coded so as to create a new String object without allocating new memory to hold a copy of the character sequence. Instead, the string can share the memory used by the string buffer. Any subsequent operation that alters the content or capacity of the string buffer must then make a copy of the internal buffer at that time. This strategy is effective for reducing the amount of memory allocated by a string concatenation operation when it is implemented using a string buffer.

[kpouer]

d'accord mais ce n'est pas garanti
(je ne l'ai cependant pas testé sur le server sun et il faut toujours se mefier des details à l'implementation)

Tiens ben d'ailleurs t'as raison de te méfier car visiblement mon information était incomplète je viens de m'en rendre compte. Ce que j'ai dit était vrai jusqu'à Java 1.4, mais depuis 1.5 une copie est systématiquement faite en cas de toString() sur un StringBuffer ou un StringBuilder pour des questions de synchronisation
http://bugs.sun.com/bugdatabase/view...bug_id=6219959
Il a été envisagé de maintenir le fait de partager le char[]entre la String et le StringBuffer seulement mais ils disent que le StringBuffer sera de moins en moins utilisé au profit du StringBuilder donc c'est se casser la tête pour pas beaucoup de gain niveau maintenance.

[epsilon68]

Merci !

en plus, pour mon cas c'est encore un cas simple que je pouvais resoudre, mais si il y a avait des structures plus complexes etc, je n'aurais surement pas pu le modifier. Le garbage collector, quoi qu'on en dise, pose un probleme dans ces cas.

a+

[the-gtm]

C'est sûr, et c'est pour ça que les développeurs Java ne font que des programmes simples et passent leur temps à maudir le garbage collector qui leur complique tellement la vie...

[JPDMJC]

Le ramasse-miettes pose problème ?
Avant de dire qu'il pose soucis, il faudrait peut être se renseigner sur celui-ci. Vous saurez ainsi qu'en lançant une appli Java, vous pouvez passer ENORMEMENT de paramètres, et régler entièrement le garbage collector, et même plein d'autres choses !!
SVP, ne dites plus que le garbage collector est difficile à utiliser, lisez un peu et maitrisez le, tout simplement. Comme diraient mes tant regrettés profs : "c'est marqué dans la doc".


@the-gtm :
tu dis : "C'est sûr, et c'est pour ça que les développeurs Java ne font que des programmes simples et passent leur temps à maudir le garbage collector qui leur complique tellement la vie..."

--> Non mais il faut arrêter le chichon là hein Le garbage collector, c'est comme l'informatique : un informaticien compétent, curieux et prêt à s'investir saura l'utiliser. L'autre, celui qui ne regarde pas plus loin que le bout de son nez aura effectivement des souci et dira "pouaha, c'est nul".
Enfin, où diable as-tu vu qu'on ne faisant que des softs simples avec Java ?? On ne doit pas parler de la même dimension.