Discussion :

[gorgonite]

Prenons un exemple : combien de temps pour coder une memory pool, surcharger les opérateurs new et delete, recoder les containers de base avec et le tout thread-proof (la gestion mémoire, pas forcement les containers) ? Il y en a pour des plombes alors que tout ça existe en java nativement.

définition de "nativement", stp... je crains qu'un puriste ne puisse être d'accord avec cela

après, trop de Javaistes semblent ignorer qu'il existe aussi des API C++... la différence entre une API standard (trop) grosse et plusieurs API plus spécialisées mises bout à bout pour répondre aux besoins du moment

[hegros]

après, trop de Javaistes semblent ignorer qu'il existe aussi des API C++... la différence entre une API standard (trop) grosse et plusieurs API plus spécialisées mises bout à bout pour répondre aux besoins du moment

augmentation de la dfficulté d'intégration, de configuration et technique pour l'un (puisqu'il faut assembler le tout), nativement en java on parle de ce qui est fournit en standard dans le sdk

[Alp]

A moins de s'être trompé de métier, il est _très_ simple de faire marcher une bibliothèque C++... Si tu penses avoir des soucis avec des noms, alors vive les namespaces et opérateurs de portée. Il ne faut pas non plus parler avec une méconnaissance du C++. Mais c'est très intéressant "d'affronter" les opinions !

[gorgonite]

augmentation de la dfficulté d'intégration, de configuration et technique pour l'un (puisqu'il faut assembler le tout), nativement en java on parle de ce qui est fournit en standard dans le sdk

nativement = fourni avec le sdk... effectivement ça défit toutes formes de vm


pour infos, dans une entreprise on ne passe pas sa vie à intégrer des bibliothèques. on le fait une fois, et on s'en ressert.

donc à moins que tu ne bosses dans une des "entreprises" dont les projets, perspectives d'avenir, politique RH presse-citron, etc sont tellement pathétiques que le turn-over a du mal à atteindre 6 mois, il est fort probable qu'on va penser plus loin que le sdk fourni en standard avec l'environnement de développement...
après si tu es dans la situation décrite précédemment... d'une part tu feras plus de l'assemblage de légo (niveau maternelle supérieure ) que de la conception à proprement, d'autre part il est clair qu'il ne faut pas demander à personnel plus de compétences qu'à un stagiaire lambda, et donc une sdk est déjà bien trop riche en fonctionnalités

[deadalnix]

Pour revenir sur le natif, ça aurait prêté a confusion si j'avais a un moment parlé de compilation. mais ici, on parle bien du mot natif, le vrai si j'ose dire, celui de la langue française et non le terme informatique.

[gorgonite]

Pour revenir sur le natif, ça aurait prêté a confusion si j'avais a un moment parlé de compilation. mais ici, on parle bien du mot natif, le vrai si j'ose dire, celui de la langue française et non le terme informatique.

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é

[hegros]

en c++ ou c en standard le sdk si j'ose dire c'est pas mieux sans compter comme j'ai dis la difficulté d'intégration et de configuration technique en ajoutant quelques composants

a priori il t'en faut beaucoup plus que du basique pour te faire une opinion, si tu veux comparer avec des solutions d'entreprise il existe déja des projets c++ et java donc avec les 2 ca marche, ton post est hors propos

[gorgonite]

en c++ ou c en standard le sdk si j'ose dire c'est pas mieux sans compter comme j'ai dis la difficulté d'intégration et de configuration technique en ajoutant quelques composants

a priori il t'en faut beaucoup plus que du basique pour te faire une opinion, si tu veux comparer avec des solutions d'entreprise il existe déja des projets c++ et java donc avec les 2 ca marche, ton post est hors propos

avec une phrase mieux structurée, l'argumentation serait sans doute plus claire... en gros, tu dis seulement que ce que tu avais dit était forcemment juste, ou tu apportes un peu plus d'explications ?

[LLB]

Mais disons la verite, qu'apres ton en programmant avec java? on ne sait rien de la memoire, meme graphiquement on ne sait rien de ce qui ce passe, on code juste on devient de machine a developper, et c'est ce que microsoft veut faire des gens avec ses versions de .net de plus en plus robotique. on veut nous transformer en robot.

Le but est juste d'augmenter la productivité en se concentrant sur les parties spécifiques de l'application. Je considère que tout bon développeur doit avoir un bon niveau en C, même s'il utilise d'autres langages par la suite. Pour ma part, j'ai utilisé énormément le C et le C++ pendant plusieurs années mais, en dehors des cas particuliers, je pense que d'autres langages sont plus adaptés la plupart du temps. Ces autres langages, quand ils sont bien faits, augmentent la productivité et réduisent le nombre de bugs (à niveau de compétence égal).

Bien sûr, mon message est assez général (comme le passage que j'ai cité) et je ne mets pas Java dans la catégorie "bon langage".

[fr1man]

C'est assez marrant cette guerre entre développeurs Java et C++.
On a l'impression que certains développeurs C++ se croient supérieurs ou sont persuadés que leur langage est meilleur parce qu'il est plus bas niveau (pointeur). Du côté des développeurs Java, on met en avant la portabilité ou le garbage collector pour démolir C++.
Je ne vois pas pourquoi il faudrait trouver un langage meilleur que l'autre. Ils s'adressent tout simplement à des types de projets différents.

On ne va pas réaliser un portail internet en cgi (c) ou un jeu dernier cri en JAVA, même si dans les deux cas, ça pourrait fonctionner.

[Alp]

en c++ ou c en standard le sdk si j'ose dire c'est pas mieux sans compter comme j'ai dis la difficulté d'intégration et de configuration technique en ajoutant quelques composants

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 ?
Personnellement, j'ai galéré en C++ avec des bibliothèques externes quand j'ai débuté en C++... J'avais 14 ou 15 ans et je ne savais pas encore comment marcher le système fichiers objets, fichiers bibliothèques, etc...

[hegros]

Je ne vois pas pourquoi il faudrait trouver un langage meilleur que l'autre. Ils s'adressent tout simplement à des types de projets différents.

Mieux encore ce n'est pas le langage de programmation qui fera du projet un échec ou une réussite. On utilise souvent un langage en entreprise pour raison historique, pour changer d'ére ou parce que le client l'exige.


Alp c'est juste une façon d'évaluer des risques entre 2 langages/technologies. Je n'ai cité que 3 critéres qui me semble pertinents pour comparer maintenant d'une typologie d'un projet à l'autre ou d'une expérience à l'autre se sera forcément différents. Loin de moi de généraliser tout pour Java ou tout pour C++

[lilington]

Je suis pas d'accord sur le fait qu'on ne sache rien de la mémoire. En effet on peut faire du java et ne rien savoir de la mémoire, mais on fera dans ce cas des développements minables.

J'aimerai bien un exemple qui montre que sous java on gere la memoire ou plus simplement qui montre que on a des informations sur ce que c'est que la memoire

[Furikawari]

Chaque référence a un objet est de la mémoire, si tu gères n'importe comment tes références (par exemple avec swing...) le GC ne saura plus ce qui est libérable ou non.

[lilington]

Le but est juste d'augmenter la productivité en se concentrant sur les parties spécifiques de l'application. Je considère que tout bon développeur doit avoir un bon niveau en C, même s'il utilise d'autres langages par la suite. Pour ma part, j'ai utilisé énormément le C et le C++ pendant plusieurs années mais, en dehors des cas particuliers, je pense que d'autres langages sont plus adaptés la plupart du temps. Ces autres langages, quand ils sont bien faits, augmentent la productivité et réduisent le nombre de bugs (à niveau de compétence égal).

Bien sûr, mon message est assez général (comme le passage que j'ai cité) et je ne mets pas Java dans la catégorie "bon langage".

ben comme je le disais le debat n'a donc plus son sens, je suppose que tout le monde sera d'accord que on compare deux langages qui ne sont pas vraiment en concurence, car pour deux publiques differents. l'un est serieusement oriente productivite l'autre te demande de tout gerer et de faire tres attentions si tu veux une application ultra puissante sinon on obtient le contraire de ce que l'on veut, un code C/C++ hyper lent bug et compagnie

[Alp]

lilington > ça c'était il y a 10 ans. Aujourd'hui, la donne a changé.
Tu peux écrire du C++ sans te préoccuper pour chaque ligne de l'allocation & compagnie.

Je te conseille de relire les posts de Luc Hermitte dans ce débat, principalement.
Mots clés : smart pointers, RAII, Boost, ...

[lilington]

Chaque référence a un objet est de la mémoire, si tu gères n'importe comment tes références (par exemple avec swing...) le GC ne saura plus ce qui est libérable ou non.

le tu me dis ce que java fait pour toi. que fait tu concretements pour etre sur que y a pas surexploitation de la memoire? en faite rien. tu dois juste faire confiance en Java et te dire temps que je n'exagere pas Java fait tout bien pour moi. en definitif tu sais rien de ce qui se passe sauf pour les hyper curieux qui iront se renseigner. ce qui ce passe avec C/C++ c'est que t'as pas le choix ou tu geres ou alors tu te plantes. c'est un avantage par rapport a java mais aussi un inconvenient car comme dis par d'autre c'est beaucoup de travail et qui ne garantie pas avoir un meilleur rendement qu'avec java

[lilington]

lilington > ça c'était il y a 10 ans. Aujourd'hui, la donne a changé.
Tu peux écrire du C++ sans te préoccuper pour chaque ligne de l'allocation & compagnie.

Je te conseille de relire les posts de Luc Hermitte dans ce débat, principalement.
Mots clés : smart pointers, RAII, Boost, ...

je le fairai c'est sur.

Mieux encore ce n'est pas le langage de programmation qui fera du projet un échec ou une réussite. On utilise souvent un langage en entreprise pour raison historique, pour changer d'ére ou parce que le client l'exige.


Alp c'est juste une façon d'évaluer des risques entre 2 langages/technologies. Je n'ai cité que 3 critéres qui me semble pertinents pour comparer maintenant d'une typologie d'un projet à l'autre ou d'une expérience à l'autre se sera forcément différents. Loin de moi de généraliser tout pour Java ou tout pour C++

a fond avec toi. mais meme si c'est pas le langage qui fait la reussite/l'echec faut reconnaitre que le choix du langage est tres important non pas pour la reussite du projet mais pour ce que l'on veut faire avec un projet reussit. plus clairement on peut faire la meme chose avec pratiquement tout les langages, et on dira qu'on a reussit mais le probleme c'est le comportement de l'application final. c'est en ca que C/C++ a une force, car ces languages permettent de faire la meme chose ou mieux que les autres mais a un tres fort prix (temps / debugage/ connaissance). prix si fort a payer que on prefera t'autres langages dans la messure du possible.

[Furikawari]

le tu me dis ce que java fait pour toi. que fait tu concretements pour etre sur que y a pas surexploitation de la memoire? en faite rien. tu dois juste faire confiance en Java et te dire temps que je n'exagere pas Java fait tout bien pour moi. en definitif tu sais rien de ce qui se passe sauf pour les hyper curieux qui iront se renseigner. ce qui ce passe avec C/C++ c'est que t'as pas le choix ou tu geres ou alors tu te plantes. c'est un avantage par rapport a java mais aussi un inconvenient car comme dis par d'autre c'est beaucoup de travail et qui ne garantie pas avoir un meilleur rendement qu'avec java

En java comme en C++ c'est TOI qui alloue tes objets, si tu alloues n'importe quoi, en java comme en C++ le résultat sera n'importe quoi. Rien à voir avec la présence/absence de GC.

[Uther]

En java comme en C++ c'est TOI qui alloue tes objets, si tu alloues n'importe quoi, en java comme en C++ le résultat sera n'importe quoi. Rien à voir avec la présence/absence de GC.

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.