Discussion :

[Furikawari]

En même temps l'allocation pose rarement de problème. On voit facilement quand on a besoin d'une allocation. C'est la libération qui est problématique, si on libère trop tôt on risque le plantage, si on ne libère pas on risque la fuite mémoire.
C'est à ce niveau que le GC de java est efficace, ceci dit il faut quand même rester conscient qu'il ne faut pas garder de référence inutiles.

Il parlait de surexploitation de la mémoire, c'est pour ça que j'ai juste insisté sur la partie allocation qui pour le coup de change rien.

[m0sch]

Un avis d'un novice
Pour programmer sous C++ faut vraiment être courageux même pour les développeur avérés, Java c'est plus facile basé sur C++ pas de gestion de mémoire, pas de passage par reference ou adresse explicite, ceci est un avantage de Java, mais dans le developpement d'appli embarquées c'est C++ qui pourrait être plus utilisé car il donne une gestion de mémoire manuelle

[Luc Hermitte]

Un avis d'un novice
Pour programmer sous C++ faut vraiment être courageux même pour les développeur avérés, Java c'est plus facile basé sur C++ pas de gestion de mémoire, pas de passage par reference ou adresse explicite, ceci est un avantage de Java, mais dans le developpement d'appli embarquées c'est C++ qui pourrait être plus utilisé car il donne une gestion de mémoire manuelle

...
Ma réponse tient en 4 lettres: RAII.

[kpouer]

sauf que le sdk java n'est pas toujours de la JVM sun... nombre de jvm plus performantes existent et sont utilisées dans l'industriel (celle d'Esmertec pour les mobiles par exemple, celle d'IBM avec WebSphere, etc)
on ne peut donc pas parler de natif Java (à la rigueur d'API standard Sun)

et donc à moins de n'utiliser que les classes de bases de l'api sun, je vois mal comment tu vas faire pour intégrer ton projet avec des besoins clients un peu plus sioux... si ce n'est trimballé des jar à côté

Oui mais même s'il y a plein de JVM diverse et variées, le langage a ses spécifications et garantie certaines choses

En même temps l'allocation pose rarement de problème. On voit facilement quand on a besoin d'une allocation. C'est la libération qui est problématique, si on libère trop tôt on risque le plantage, si on ne libère pas on risque la fuite mémoire.
C'est à ce niveau que le GC de java est efficace, ceci dit il faut quand même rester conscient qu'il ne faut pas garder de référence inutiles.

Ba l'allocation pose des problèmes de performance, en c++ si tu passes tous tes objets non par pointeur mais par copie, ba tu vas consommer de la mémoire de manière idiote, en java c'est pareil, tu peux coder de manière idiote ou coder de manière intelligente, et si tu es idiot c'est pas le garbage collector qui te sauvera du désastre contrairement a ce que certains semblent croire ici

[gorgonite]

Oui mais même s'il y a plein de JVM diverse et variées, le langage a ses spécifications et garantie certaines choses

ayant déjà écrit une JVM, je pense en être un peu conscient... mais l'API Sun n'est pas totalement dans le standard ^^

Ba l'allocation pose des problèmes de performance, en c++ si tu passes tous tes objets non par pointeur mais par copie, ba tu vas consommer de la mémoire de manière idiote, en java c'est pareil, tu peux coder de manière idiote ou coder de manière intelligente, et si tu es idiot c'est pas le garbage collector qui te sauvera du désastre contrairement a ce que certains semblent croire ici

+1000
comme toujours, mieux vaut BIEN faire dans un langage dit moyen que se prendre pour un expert dans un langage exigeant et TOUT foirer

[Uther]

Ba l'allocation pose des problèmes de performance, en c++ si tu passes tous tes objets non par pointeur mais par copie, ba tu vas consommer de la mémoire de manière idiote, en java c'est pareil, tu peux coder de manière idiote ou coder de manière intelligente, et si tu es idiot c'est pas le garbage collector qui te sauvera du désastre contrairement a ce que certains semblent croire ici

C'est vrai qu'en en Java ce genre de pb ne se pose pas étant donné que tous les objets sont manipulés par référence. Un point fort de Java a mon avis est d'avoir réussi a faire disparaitre des éléments du C++ qui apportaient plus de complexité que d'intérêt(un peu comme l'héritage multiple)

Après bien sur un mauvais programme reste mauvais quelque soit le langage mais faire attention a ne pas garder de référence inutile en Java est infiniment plus simple que de se faire une gestion propre de la mémoire en C++.

[Alp]

Mais encore une fois, en C++, depuis des années maintenant, on a ce qu'il faut pour ne plus avoir à se prendre la tête avec la gestion de la mémoire, tout en pouvant être confiant sur la sureté du programme.

RAII, pointeurs intelligents, etc... Il y a pas mal de ressources là-dessus sur cpp.developpez.com si ça vous intéresse.

Par contre, comme pour tout langage, mieux on connaît son langage, mieux on connaît les outils qui y sont adjoints, et mieux ça se passe, évidemment.

[ac_wingless]

C'est quand même très curieux cette histoire récurrente de problème mémoire en C++. Franchement, il y a bien des problèmes en C++, mais la gestion mémoire n'en fait pas partie. Ça fait au moins 5 ans que je n'ai pas eu de crash client pour des histoires de mémoire.
Par contre, des problèmes de productivité, oui! C++ est bien trop compliqué à compiler, les intellisense ne marchent pas (du tout, ou pas aussi bien que sous d'autres langages), la complexité des templates aboutit à des librairies non portables bien qu'indispensables comme Boost, etc. Le fait que C++ autorise, voire encourage presque (cf. Boost) la programmation pédante voire non maintenable, alors que Java l'interdit, est à mon avis bien plus significatif des problèmes rencontrés dans le monde réel.

Je me demande bien l'intérêt de cette discussion à ce stade. Ça tourne toujours autour des même lieux communs.

Pour enfoncer le clou une bonne fois pour toutes: nous avons dans l'équipe trois jeunes programmeurs C++ qui ont été formés par Java. Après quelques soucis avec eux, nous avons ajouté à nos conventions de codage l'interdiction d'utiliser new sans passer par l'accord par email du chef de projet (souvent moi). Depuis, nous n'avons strictement aucun problème (sans doute du au fait que leur formation Java les immunise contre les horreurs genre pointeurs et tableaux natifs, qui sont avant tout un problème C, et non C++).
Ces programmeurs anciennement Java se plaignent surtout des templates complexes, de la lourdeur du processus de compilation, du manque de simplicité et de portabilité de Boost, et plus généralement du manque de librairies. Pas des problèmes de gestion mémoire!!

[m0sch]

Avis d'un novice
Je pense qu'on peut rencontrer aussi des problèmes d'accés à la mémoire sous JAVA, des fois un utilisateur accède à un objet pour le modifier l'autre y accéde pour le supprimer... d'ou la nécessité des design pattern comme Spring mashin etc... , et donc avec cela JAVA devient difficile et trop complexe pour les développeurs avec ces frameworks, le language est facile mais les frameworks waaw, ça devient vraiment chaud, un framework qui nécessite au moin 2 mois pour le comprendre à 60%.( peut être car je suis pas assez intélligent je généralise pas xD).
Java en tant que language je crois qu'il est abordable, mais ces frameWorks, moi personnellement je pense que c'est assez exagéré... je hais même si je developpe dessus sans cesse.

[koala01]

C'est quand même très curieux cette histoire récurrente de problème mémoire en C++. Franchement, il y a bien des problèmes en C++, mais la gestion mémoire n'en fait pas partie. Ça fait au moins 5 ans que je n'ai pas eu de crash client pour des histoires de mémoire.
Par contre, des problèmes de productivité, oui! C++ est bien trop compliqué à compiler, les intellisense ne marchent pas (du tout, ou pas aussi bien que sous d'autres langages), la complexité des templates aboutit à des librairies non portables bien qu'indispensables comme Boost, etc. Le fait que C++

<snip>

On ne peut pas laisser dire que boost ne soit pas portable... pas dans sa version actuelle en tout cas (meme cela a pu etre le cas dans les version antérieurs)...

Le problème ne vient d'ailleurs pas de boost mais bel et bien des compilateurs qui ne respectent parfois la norme que de manière très approximative (bien qu'il faille admettre que d'aucuns ont fait de sérieux progrès en la matière) et qui, pour certains, présentaient même ce non respect de la norme comme argument de vente ...

Le succès de boost aidant, il est de plus en plus facile de trouver la personne qui utilise un compilateur "différent" qui ne respecte pas un point particulier de la norme, et donc de trouver la manière d'y remédier

A l'heure actuelle, s'il reste des incompatibilités, c'est au niveau de la compilation des bibliothèques dynamiques elles-mêmes car il reste impossible d'utiliser une dll sous linux ou un *.so sous windows

[ac_wingless]

On ne peut pas laisser dire que boost ne soit pas portable... pas dans sa version actuelle en tout cas (meme cela a pu etre le cas dans les version antérieurs)...

On peut au contraire dire que c'est un des deux problèmes fondamentaux de Boost, bien sûr pas à cause de Boost, mais à cause des compilateurs, et on revient à un souci intrinsèque à C++ (la complexité du langage et sa difficulté de compilation). Boost est portable de MSVC à gcc (à condition d'avoir des générations de compilateurs de même époque). Mais on ne peut pas laisser dire que Boost est portable en C++ parce que ça marche sur la dernière version de 2 compilateurs!

Pour ce qui est du reste des environnements (cf. le bas de cette page), Boost ne marche pas de façon professionnelle. Or, le reste, c'est quand même beaucoup beaucoup de domaines! Par exemple, un domaine où le C++ brille particulièrement (l'embarqué) est complètement et totalement hermétique à Boost. C'est quand même dommage de revenir à Java dans ce domaine pour cause de manque de librairies essentielles.

[koala01]

Non, ce qui est dommage, c'est qu'il ait fallu attendre aux alentours de 2005 pour que de grands fournisseurs de compilateurs se décident à essayer de respecter une norme datant de... 1998 (ils n'ont jamais mis que 8 ans pour s'y décider )

A partir de là, tu as beau essayer de respecter la norme du mieux que tu le puisse, il reste difficile de faire des miracles, et il faut admettre qu'un "certain temps" soit nécessaire afin d'assurer la compatibilité qui aurait du être assurée du seul fait du suivi de la norme...

Mais, dans l'ensemble, on est loin des seules dernières versions de visual C++ et de Gcc: les tests effectués allant de VisualC++ à Sun C++, en passant par les compilateur intel, ibm, HP, borland et Gcc, dans un nombre de versions augmentant sans cesse...

[ac_wingless]

les tests effectués allant de VisualC++ à Sun C++, en passant par les compilateur intel, ibm, HP, borland et Gcc, dans un nombre de versions augmentant sans cesse...

Ces versions ne marchent pas (à l'exception notable de gcc bien sûr). Je vous prie de les tester avant de vous avancer. On dispose de vagues équivalences sur à peu près la moitié aux deux tiers, avec des pertes de fonctionnalités, des erreurs dès que des modules un peu difficiles sont utilisés (c'est le principe de Boost que de réutiliser ses formidables outils autant que possible).

Je mets au défi une entreprise de lancer un projet industriel portable mettant en œuvre des composants aussi basiques que Regex, Interprocess, ou Serialization. Même la toute dernière version de Borland (2009) qui pourtant se vante de livrer Boost 1.35 d'origine, est pratiquement inutilisable en dehors de quelques petits modules de bases. Or, ces choses et bien d'autres sont totalement acquises en environnement Java.

[hegros]

Je ne vois pas d'ou tu sors ces difficultés, sincèrement.

Tu peux illustrer avec ton expérience ou celle de tes collègues ?

Oui Alp avec des projets qui utilise les MFC. Le couplage avec la couche UI c'est manifestement plus complexe qu'en Java... Il existe Qt maintenant aussi mais bon premiére expérience premier blocage, une autre expérience avec DCOM+ pareil blocage.


En C il faut regarder GTK qui est bien sympa mais voyez le degré d'intégration (installation d'une sorte de runtime) et la difficulté technique pour les options de compilation (en tout cas pour un débutant/moyen)

[souviron34]

En C il faut regarder GTK qui est bien sympa mais voyez le degré d'intégration (installation d'une sorte de runtime) et la difficulté technique pour les options de compilation (en tout cas pour un débutant/moyen)

Il y a Motif

-I /usr/X11/Motif

c'est pas trop dur comme option de compil...

Je ne comprend d'ailleurs pas pourquoi tout le monde ces dernières années s'est préciipité sur Qt ou GTK ou wxWidgets, alors que Motif avait mis 20 ans à peaufiner ses widgets, avec une doc irréprochable, et un User Guide parfait, ainsi qu'une table des matières sensationnelle..

M'enfin.. encore un vieux ronchon qui ne voit pas forcément l'intérêt du progrès

[hegros]

Il y a Motif

-I /usr/X11/Motif

c'est pas trop dur comme option de compil...

oui mais rappelle toi sur ce post même tu disais que le test comparatif (qui donnait java plus rapide) était faussé parce que justement les options n'étaient pas bien réglées...

Pour xmotif c'est peut-être parce qu'en entreprise on tends à utiliser des RAD en tout cas des outils et environnement de développement customisé.

Puis il ne me semble pas l'avoir croisé sur la page outils et bibliothéques pour le C/C++, pour son enseignement c'est pareil cela doit se faire rare..

[souviron34]

oui mais rappelle toi sur ce post même tu disais que le test comparatif (qui donnait java plus rapide) était faussé parce que justement les options n'étaient pas bien réglées...

Je répondais juste à ta note sur C (qui par ailleurs est HS dans ce thread )

Pour xmotif c'est peut-être parce qu'en entreprise on tends à utiliser des RAD en tout cas des outils et environnement de développement customisé.

C'est sans doute une bonne part de la vérité, car Architect ou UIMX ne produisent pas du bon code, et n'empêchent pas d'avoir à plonger dans les différentes couches (3 au minimum) dès que l'on veut faire quelque chose de subtil.

Cependant, il suffit de voir les forums GTK et Qt pour se rendre compte que c'est exactement pareil sur ce dernier point (et c'est normal).

Je pense comme toi que c'est plutôt l'interface de ces outils qui est mal concue, et qui ne les a jamais fait utiliser à grande échelle..

Puis il ne me semble pas l'avoir croisé sur la page outils et bibliothéques pour le C/C++, pour son enseignement c'est pareil cela doit se faire rare..

Absolument. J'avais été pressenti pour me charger de la rubrique ici, mais quelques difficultés ne m'ont pas permis de le faire.

En ce qui concerne l'utilisation et l'enseignement, je pense que cela a beaucoup à voir avec justement le passage à grande échelle à Linux et l'arrivée massive sur un marché "ouvert" de gens venant du monde M$ où VC++ était à peu près le seul outil avec Delphi (et anciennement avec VB).

Mais cela n'est que mon humble avis..

Maintenant, je me retire du débat, puisque c'était HS...

[rakakabe]

J'ai pas tout lu mais je me permets de dire mon avis sur le sujet.

C++ ou Java ?
c'est comme si on dit : "Chéri(e), je dois faire la course, laquelle des 2 caisses me proposes-tu? la Formule 1 ou le monospace ?". Et tout le monde se plante sur le sens du mot Course : aller au marche ou faire une competition automobile.

A mon avis, la question devrait-t-etre reformulee comme suit : si t'as un pb a resoudre lequel des 2 langages convient mieux ?

NB (Juste pour rire : Geek vs. mr tout le monde) : 1. Un - pour Java : je peux pas faire un truc du genre :
class T inherits Singleton<T>
2. Un - pour C++ : je dois redemarrer souvent a cause de ce satané fuite de memoire dans mon programme, et qui n'est pas portable en plus

[ZeRevo]

Je ne comprend d'ailleurs pas pourquoi tout le monde ces dernières années s'est préciipité sur Qt ou GTK ou wxWidgets, alors que Motif avait mis 20 ans à peaufiner ses widgets, avec une doc irréprochable, et un User Guide parfait, ainsi qu'une table des matières sensationnelle..

Effet de mode peut-être... Je préfére coder en python que faire du Caml(je me comprend)

Ces programmeurs anciennement Java se plaignent surtout des templates complexes, de la lourdeur du processus de compilation, du manque de simplicité et de portabilité de Boost, et plus généralement du manque de librairies. Pas des problèmes de gestion mémoire!!

En java (j2ee) c'est pas forcément mieux, on passe énormément de temps à configurer les outils de développement (maven2, serveur d'intégration, ...). Les problèmes de lourdeur de processus de compilation sont inévitables pour les grosses applications. Il est toutefois préférable de découper ses outils en modules/plugins pour améliorer la productivité.

De toute manière un langage c'est juste un outil, le principal c'est de le maitriser et de ce côté là on a souvent des surprises

[Uther]

Je ne comprend d'ailleurs pas pourquoi tout le monde ces dernières années s'est préciipité sur Qt ou GTK ou wxWidgets, alors que Motif avait mis 20 ans à peaufiner ses widgets, avec une doc irréprochable, et un User Guide parfait, ainsi qu'une table des matières sensationnelle..

M'enfin.. encore un vieux ronchon qui ne voit pas forcément l'intérêt du progrès

La première réaction que j'ai eu en voyant une appli motif ainsi que tous ceux que je connais est : "Qu'est ce que c'est moche". Je ne connais pas bien Motif, il a surement des qualités mais le look est tellement repoussant que c'est rédhibitoire pour pas mal de monde.