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
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
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)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
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++.
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.
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!!
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.
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
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.
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...
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.
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)
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
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..
Je répondais juste à ta note sur C (qui par ailleurs est HS dans ce thread )
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..
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...
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
Effet de mode peut-être... Je préfére coder en python que faire du Caml(je me comprend)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..
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é.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!!
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
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.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
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.
Partager