Bon déjà shared_ptr<> c'est certes bien mais ça n'est sûrement pas un ramasse miettes complet (c'est un peut comme si tu comparais un moteur de voiture avec une voiture complète). Il faut toujours se préoccuper de problèmes comme la rule of three, se demander si on veut passer les objets par copie ou par référence. Il faut aussi gérer les .hpp et .cpp, se casser la tête parce qu'on doit faire des forward déclaration de classes si on a des dépendances circulaires. L'héritage en C++ n'est pas aussi simple qu'en Java : il faut se préoccupper de déclarer ses méthodes virtual (et ses destructeurs hein pour éviter les fuites) , regarder comment on caste les shared_ptr<> si on en utilise. Sans compter les cas où les exceptions se marient moyennement bien avec la gestion manuelle de la mémoire. Je pourrais continuer comme ça pendant des heures.
Bref, coder en C++, c'est dur. Bien plus dur que coder en Java. On devrait coder en C++ uniquement quand on a besoin du gain de performance apporté.
Tu dis que ne pas gérer la mémoire à la main, c'est masquer les problèmes. Certes, mais c'est bien le sens de ce qu'on fait en informatique depuis 30 ans, non ? Le C masque l'assembleur et le fait que mon processeur à des registres et qu'il faut aller chercher des trucs de la mémoire pour les mettre dans des registres. Même chose pour les systèmes d'exploitations qui masquent le matériel et offre des API unifiées.
Et honnêtement une application en C++ a mille fois plus de chances de fuire qu'une application codée en Java. Certes l'application Java utilisera certainement plus de mémoire à la base, mais le ramasse-miette limite franchement les erreurs de programmation.
Concernant les bibliothèques Java utilisant de manière excessivement les annotations, tu n'es pas obligé de les utiliser.
[^] # Re: J'en pense que
Posté par X345 . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 9. Dernière modification le 25 octobre 2013 à 16:32.
Merci, tu ensoleilles mon vendredi :-)
Bon déjà
shared_ptr<>c'est certes bien mais ça n'est sûrement pas un ramasse miettes complet (c'est un peut comme si tu comparais un moteur de voiture avec une voiture complète). Il faut toujours se préoccuper de problèmes comme la rule of three , se demander si on veut passer les objets par copie ou par référence. Il faut aussi gérer les .hpp et .cpp, se casser la tête parce qu'on doit faire des forward déclaration de classes si on a des dépendances circulaires. L'héritage en C++ n'est pas aussi simple qu'en Java : il faut se préoccupper de déclarer ses méthodesvirtual(et ses destructeurs hein pour éviter les fuites) , regarder comment on caste lesshared_ptr<>si on en utilise. Sans compter les cas où les exceptions se marient moyennement bien avec la gestion manuelle de la mémoire. Je pourrais continuer comme ça pendant des heures.Bref, coder en C++, c'est dur. Bien plus dur que coder en Java. On devrait coder en C++ uniquement quand on a besoin du gain de performance apporté.
Tu dis que ne pas gérer la mémoire à la main, c'est masquer les problèmes. Certes, mais c'est bien le sens de ce qu'on fait en informatique depuis 30 ans, non ? Le C masque l'assembleur et le fait que mon processeur à des registres et qu'il faut aller chercher des trucs de la mémoire pour les mettre dans des registres. Même chose pour les systèmes d'exploitations qui masquent le matériel et offre des API unifiées.
Et honnêtement une application en C++ a mille fois plus de chances de fuire qu'une application codée en Java. Certes l'application Java utilisera certainement plus de mémoire à la base, mais le ramasse-miette limite franchement les erreurs de programmation.
Concernant les bibliothèques Java utilisant de manière excessivement les annotations, tu n'es pas obligé de les utiliser.