Discussion :

[xololol]

Vous me parlez de fonctions, moi je vous parle du langage...

Oui, mais qui utiliserait un langage sans les fonctionnalités qui lui sont propres?

De plus, ce n'est pas à la machine de savoir ce que fait le programmeur, s'il ne réfléchis pas et fais n'importe quoi, alors le programme fait de même, elles n'ont pas de cerveaux les machines, juste une mécanique avalant des instructions préconçues....

Une chose que les gens ont du mal à comprendre en abordant le C/C++ après avoir fait du Java est sa permissivité.... Le C/C++ permets de tout faire.... branche une cafetière à ton PC, et tu pourrais dire que le C/C++ fais le café...

Seulement cette liberté de programmation demande une plus grande réflexion de la part du programmeur.

Ce n'est pas une raison pour dire que le C/C++ n'est pas sécurisé, il permets de faire tout ce que la machine sait faire, (ne me dites pas le contraire, pk la JVM s'appuie sur C/C++ et sur des OS fait en C/C++).

Ce qui induit donc que les newbies qui ne réfléchissent pas plus loin que le bout de leur nez et veulent faire du C++ parce que li, parce que là, produiront des failles.

Mais ces failles ne sont que le reflet de l'incompétence du développeur en question, pour preuve tout les programmes open sources écrits en C/C++ finissent par voir leurs failles disparaître au fil du temps.

Je le répète : Java et C/C++ n'ont pas le même domaine d'application, et chacun des deux trouvent sa raison d'être, sinon le C/C++ ou le java aurait disparu, le monde informatique ne s'encombra que rarement de choses inutiles et superflues.

Reste au développeur de savoir lequel utiliser pour le résultat qu'il veut obtenir de son programme.

[pseudocode]

Exemple parfait de ce que xololol disait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

crois moi que les développeurs qui sont "aware" de la sécurité utilisent les fonctions qui ne permettent pas le buffer overflow

Ton exemple crashe, pas parceque le langage est mauvais, mais parceque l'auteur est mauvais ,c'est exactement le genre de code qu'aucun programmeur de niveau profesionnel n'ecrirait....

Quant aux char * , ils sont beaucoup trop utiles pour etre enlevés.

Suffit de savoir les utiliser de maniere safe( ça s'apprend), pour ne jamais laisser une seule possibilité d'overflow...

Bon, alors une fois pour toute: UNE APPLICATION BIEN PROGRAMMEE NE PLANTE PAS, QUELQUESOIT LE LANGAGE.

Maintenant, il y a des langages ou il est FACILE de faire du mauvais code, d'autre ou c'est plus compliqué. "Personnellement" "je" "moi meme" trouve qu'il est plus FACILE de faire un bufferoverflow en C/C++ qu'en Java.

Maintenant, vous me dite qu'en C/C++ il ya des "regles" et un "savoir faire" a acquerir pour eviter ce genre d'erreur. Je vous crois.

En Java c'est géré par le langage, il n'y a donc pas de "regles" ou de "savoir faire"a acquerir pour eviter ces erreurs.

Ce qui me fait conclure (mais j'ai peut-etre tord, comme d'hab) qu'il y a moins de risque de bufferoverflow en Java qu'en C/C++. Donc, pour ce qui est du cas tres particulier (mais commun) de la sécurité face au bufferoverflow: avantage Java.

Je le répète : Java et C/C++ n'ont pas le même domaine d'application, et chacun des deux trouvent sa raison d'être, sinon le C/C++ ou le java aurait disparu, le monde informatique ne s'encombra que rarement de choses inutiles et superflues.

Reste au développeur de savoir lequel utiliser pour le résultat qu'il veut obtenir de son programme.

C'est justement la question: Quelle sont donc ces regles qui font preferer Java a C/C++ pour le développement d'un programme.

[Kujara]

Bon, alors une fois pour toute: UNE APPLICATION BIEN PROGRAMMEE NE PLANTE PAS, QUELQUESOIT LE LANGAGE.

Oui oui, on est d'accord. Mes excuses si ce n'etait pas clair dans mes messages ou si je ne t'ai pas bien compris.

Maintenant, il y a des langages ou il est FACILE de faire du mauvais code, d'autre ou c'est plus compliqué. "Personnellement" "je" "moi meme" trouve qu'il est plus FACILE de faire un bufferoverflow en C/C++ qu'en Java.

Maintenant, vous me dite qu'en C/C++ il ya des "regles" et un "savoir faire" a acquerir pour eviter ce genre d'erreur. Je vous crois.

En Java c'est géré par le langage, il n'y a donc pas de "regles" ou de "savoir faire"a acquerir pour eviter ces erreurs.

Ce qui me fait conclure (mais j'ai peut-etre tord, comme d'hab) qu'il y a moins de risque de bufferoverflow en Java qu'en C/C++. Donc, pour ce qui est du cas tres particulier (mais commun) de la sécurité face au bufferoverflow: avantage Java.

Oui, avantage Java si le programmeur ne connais pas les fameuses "regles".
Sinon, equivalent puisque pas d'overflow sur aucun des 2.

[adiGuba]

Oui, avantage Java si le programmeur ne connais pas les fameuses "regles".
Sinon, equivalent puisque pas d'overflow sur aucun des 2.

Ce qu'il veut dire sur ce cas précis c'est qu'en C/C++ un erreur de programmation de type bufferoverflow pose un problème de sécurité car elle peut être utilisée pour exécuter un code arbitraire.

En Java une tel erreur de programmation génèrera une exception de type OutOfBoundsException sans possibilité d'injection de code...

a++

[xololol]

Maintenant, il y a des langages ou il est FACILE de faire du mauvais code, d'autre ou c'est plus compliqué. "Personnellement" "je" "moi meme" trouve qu'il est plus FACILE de faire un bufferoverflow en C/C++ qu'en Java.

Et l'on n'a pas dis, ni ne diras le contraire.

Mais faire du mauvais code, c'est aussi et surtout avoir une mauvaise algorithmie, et une mauvaise rigueur de prog.

Et ce n'est pas le langage, quel qu'il soit, qui fera l'algorithmie à la place du développeur...

Donc on en revient au même point : être rigoureux (un minimum), réfléchir avant de taper du code comme un fou, et penser à la place de la machine, qui ne le fera jamais pour vous !!!

Et pour ça osef (on s'en fichtre) Java ou C/C++.

[pseudocode]

Ce qu'il veut dire sur ce cas précis c'est qu'en C/C++ un erreur de programmation de type bufferoverflow pose un problème de sécurité car elle peut être utilisée pour exécuter un code arbitraire.

En Java une tel erreur de programmation génèrera une exception de type OutOfBoundsException sans possibilité d'injection de code...

a++

Oui tout a fait. C'etait pas du tout marqué dans mes messages (), mais l'erreur bufferoverflow en elle meme ne me derange pas trop: ca arrete le programme aussi bien en C++ (segfault) qu'en Java (RuntimeEx).

C'etait evidement le risque d'une injection de code qui m'interesse, pour estimer la sécurité ("S") de l'application.

[xololol]

C'est justement la question: Quelle sont donc ces regles qui font preferer Java a C/C++ pour le développement d'un programme.

Il n'y a pas à préférer un langage vis-à-vis de l'autre, vous vous trompez de débat là...

Il ont chacun leur domaine d'application.
Il ont chacun leur domaine d'application.
Il ont chacun leur domaine d'application.
Il ont chacun leur domaine d'application.

Vous l'avez lu la phrase, là?

Choisir un langage par rapport à un autre juste pour les facilités de programmation qu'il apporte n'est pas un choix viable...

Certaines applications ne peuvent tout simplement pas se faire en Java.

Exemple : un serveur devant gérer 5000 à 10000 client simultanément, de façon optimisé, en occupant le moins possible les ressources... Essaies donc en Java... (mais je le redis : je n'est absolument rien contre le java que j'apprécie particulièrement d'ailleurs)

Seulement, le java et le C/C++ ne joue pas dans la même cours, c'est tout...

[Jean-Marc.Bourguet]

Ceci n'est pas possible en Java : un objet n'est détruit qu'à partir du moment où il n'existe plus aucune référence vers ce dernier

Equivalent dans un langage avec GC: on remplace par null ou un pointeur vers un objet approprie toutes les references connues a cet objet et on en oublie une.

Là je suis bien d'accord avec toi. Le GC apporte deux limitations très gênante à mon avis :

• Une taille maximum de mémoire allouable qui ne dépasse pas les 4Go, voir moins sur certains système (comme Windows) à cause des spécificité du GC (qui alloue la mémoire d'un bloc).

C'est pas une limite des GC. J'utilise un langage avec GC dans des process de plus de 4G.

• L'obligation de spécifier une taille maximum au démarrage de l'application, qui ne pourra pas être modifié ni dépassé pendant l'exécution. Et comme la valeur par défaut est assez petite (64 Mo il me semble) c'est assez chiant à gérer pour des applications qui doivent traiter des quantité de données variables... (quoiqu'il me semble que cette
  limitation n'existe pas sur la JVM d'IBM).

Je ne sais pas si la limitation existe ou pas pour la JVM d'IBM, je sais que j'utilise aussi un GC qui ne l'a pas.

Après une attaque en règle de fanboys de Java, je vois maintenant beaucoup de mauvaise foi de la part d'adepte du C++,

Mauvaise foi de certain au singulier, dois-je me sentir vise? J'ai annonce la couleur (voir le titre du message). Et d'un autre cote, j'ai aussi donne la bonne reponse au probleme. Et j'ai l'impression que je vais devoir vous souffler d'autres arguments parce que vous n'avez toujours pas sorti les plus convainquant.

c'est bien triste comme thread je trouve. Par exemple l'exemple de réflexion est particulièrement ridicule : il suffit d'utiliser le bon security manager pour interdire ce genre de chose,

C'est moi qui ai sorti les deux.

et de toute façon on ne rencontre pratiquement jamais un code comme celui-ci en production.

J'espere bien. Outre l'aspect trollesque, c'etait plus pour montrer que Java n'etait pas aussi sur sans precaution que d'aucuns le pretendent. Rien de plus. Et surtout pas le point suivant:

Expliquer ensuite que cet exemple est pour montrer qu'un plantage est préférable à un comportement incorrect silencieux...

Cette affirmation (un plantage est préférable à un comportement incorrect silencieux) je la maintient. Mais ne l'utilise dans ce contexte qu'au sujet du GC. Et encore, c'est pour remettre les pendules a l'heure, je suis globalement partisant des GC. Simplement c'est pour moi un outil ayant aussi ses limitations et ses problemes

Evidemment que c'est préférable ! Néanmoins un programmeur C++ qui critique le Java pour des comportements incorrects silencieux c'est l'hôpital qui se moque de la charité ! Et encore je suis poli !

Ai-je emis quelque part une opinion quelconque sur les merites relatifs des deux langages? J'en doute (ah si, j'ai ecrit que java etait probablement plus adapte a l'enseignement aux debutants complet). Je suis sur par contre d'avoir ecrit que je ne connaissais pas Java assez pour emettre la dessus un jugement pertinent.

que je sache, le GC permet d'éviter pas mal de problèmes de ce côté là

Les GC permettent d'eviter a avoir a implementer une solution d'ownership partage. C'est tout. Ce n'est pas rien. Les weak pointer permettent de resoudre la plupart des cas que auxquels j'ai fais allusion (allez, je vous refile encore un argument que j'attendais que vous me sortiez, je ne sais plus qui disait que quand on est incapable de ternir les deux cotes d'une discussion technique, c'est qu'on ne connait pas le sujet assez bien pour y participer), mais malheureusement il n'y en a pas dans le langage avec GC que j'utilise. Et bien sur pour les utiliser, il faut analyser correctement le probleme de la gestion de la memoire; ca va un peu a l'encontre de l'argument que le GC permet d'eviter de s'en occuper.

(je sais, je sais, les bons programmeurs C++ ne gèrent pas leur mémoire vraiment à la main, ils utilisent des smart/auto/... pointers, de la RAII, etc, néanmoins si on n'a pas besoin du gain de performance qu'amène le C++, n'est-il pas plus simple de simplement utiliser un GC).

Et pourquoi est-ce que je suis pour l'introduction d'un GC en C++?

Alors l'argument comme quoi les memory leak en Java sont très génant mais les mêmes en C++ absolument pas parce qu'ils sont faciles à détecter (contrairement aux mêmes en Java, de qui se moque-t-on ?)

,

http://www.developpez.net/forums/sho...&postcount=743

Euh... le C/C++ existe depuis bien plus longtemps que le java, et lorsque que les premiers compilateurs C ont vu le jour, la sécurité n'avait pas de raison d'être... le net n'étant pas démocratisé à l'époque,

Le net n'existait pas encore. Les reseaux locaux non plus.

[Jean-Marc.Bourguet]

La seule personne que je connais et dont j'ai confiance en la capacite de commenter sur le sujet de R pour les deux langages est nettement en faveur du C++ par rapport au Java qu'il a pratique. Le langage a evolue depuis je crois, ce qui peut avoir changer le contexte.

Je pense que le "buffer overflow" a fait plus de mal en matiere de sécurité que les fonctionnalités exotiques de java. Tellement de mal qu'il a généré son propre eco-système: analyseur dynamique, analyseur statique, libraire sécurisé (strcpy_s), modifs OS/hardware (DEP)...

Je mettrai plutot avantage Java sur le "R". Mais ce n'est que mon avis...

De memoire, son raisonnement etait que Java fournissait de base une serie d'outils mais que le C++ permettait de se batir de meilleurs outils que ceux disponibles en Java.

[xololol]

Oui tout a fait. C'etait pas du tout marqué dans mes messages (), mais l'erreur bufferoverflow en elle meme ne me derange pas trop: ca arrete le programme aussi bien en C++ (segfault) qu'en Java (RuntimeEx).

Hum...

Un buffer overflow ne tue pas un programme C/C++...

Un buffer overflow va écrire sur des emplacements mémoires qui n'apartiennent pas (n'ont pas été alloués) pour le buffer en question, il écrit donc à ce moment là sur d'autre objets, tableaux, ou variables en mémoire.

Le programme plantera lorsqu'il essaiera par la suite d'accéder aux zones mémoire corrompus par l'overflow (par exemple, un 0 écrit sur un pointeur stocké dans une structure, qui aménera un appel de fonction d'objet sur l'adresse NULL, et bam crash)

Le cas décrit ici est le comportement obtenu avec de petits overflow, un gros buffer overflow pourrait crasher de suite, en effet.

Ainsi donc il faut être plus rigoureux en C/C++ qu'en Java, c'est un fait. Mais est-ce un mal?

[adiGuba]

C'est pas une limite des GC. J'utilise un langage avec GC dans des process de plus de 4G.

On est d'accord : je parlais bien sûr du GC de la JVM et pas des GC en général
Mais c'est vrai que j'aurais dû le préciser !

a++

[Jean-Marc.Bourguet]

Ainsi donc il faut être plus rigoureux en C/C++ qu'en Java, c'est un fait.

Il faut la meme rigueur partout. En C, elle necessite plus d'effort que dans les deux autres langages et en plus la connaissance d'un folklore impressionnant. Je ne suis pas sur qu'il faille significativement plus d'effort au total en C++ qu'en Java une fois ses briques de base faites.

Mais est-ce un mal?

Oui. Les gens sont faillibles. Tout ce qui est detecte automatiquement est un bien.

[adiGuba]

Je ne suis pas sur qu'il faille significativement plus d'effort au total en C++ qu'en Java une fois ses briques de base faites.

Par contre, et malgré l'apparente proximité de ces deux langages, ces "briques de bases" sont assez différentes et on ne passe pas aussi facilement de l'un à l'autre que ce qu'on pourrait croire...

Pour moi un programme Java ne se code pas de la même manière qu'un programme C++, car malgré le fait que ce soit deux langages OO, ils en ont une approche très différente...

Les gens sont faillibles. Tout ce qui est detecte automatiquement est un bien.

+1
Auquel on peut rajouter la "fainéantise" avec des codes fait à la va-vite avec plein des commentaires "A FAIRE" ou "A CORRIGER"... et qui reste des années comme cela...

a++

[pseudocode]

Pour moi un programme Java ne se code pas de la même manière qu'un programme C++, car malgré le fait que ce soit deux langages OO, ils en ont une approche très différente...

Non. C++ est un langage multiparadigme, et c'est la un point interessant. Ca lui donne plus de "puissance", mais aussi plus de "complexité".

C'est une difference entre Java et C++ bien plus importante a mon sens que les considerations techniques (jit/aot, gc/manuel, ...). Le fait de pouvoir "switcher" de paradigme a tout moment implique une bonne connaissance des paradigmes et une grande rigueur dans le design du programme.

N'avoir que le seul paradigme OO est une limitation pour Java. D'un autre coté, cela permet de limiter les solutions possibles face a un probleme... et donc moins de chance d'en choisir une mauvaise.

[super_navide]

en C++

exist-il un moyen aussi facile qu'en java ( c'est a dire implémenté l'interface Serializable ) pour pouvoir serializer un objet ??????


exist-il un moyen de faire aussi facilement qu'en java des java.lang.reflect.Proxy

[Jedai]

Je te comprends pas vraiment, c'est pas si évident. Comment est-ce que tu fais pour trouver l'origine de ton comportement incorrect silencieux si tu n'as pas un moindre indice du dysfonctionnement de ton programme ?
Ma réponse est hors débat, mais stratégiquement, qu'on soit professionnel ou pas, ne cherche-t-on pas à éliminer tous les obstacles à notre objectif ?

Tu sembles m'avoir compris de travers dans les deux cas... Je disais d'une part qu'il était parfaitement évident qu'un plantage soit préférable à un comportement incorrect silencieux mais que le C++ était difficilement en position de critiquer Java sur ce point vu qu'il était bien plus fréquent d'avoir des comportements incorrects silencieux en C++ qu'en Java (à compétences égales).

Dans le deuxième cas, je prêchais l'utilité du GC pour se libérer d'une gestion mémoire manuelle susceptible d'erreur, ou lourde, que ce soit en C++ ou en Java d'ailleurs. N'es-tu pas de cette opinion ?

Mauvaise foi de certain au singulier, dois-je me sentir vise? J'ai annonce la couleur (voir le titre du message). Et d'un autre cote, j'ai aussi donne la bonne reponse au probleme. Et j'ai l'impression que je vais devoir vous souffler d'autres arguments parce que vous n'avez toujours pas sorti les plus convainquant.

Hum.. Désolé, le "adepte" aurait dû être au pluriel, c'est corrigé, je ne vous visais pas en particulier, mais plutôt l'escalade de mauvaise foi qui s'est faite en se basant sur cet exemple ou à côté.
Je n'ai pas l'intention de sortir des arguments techniques en faveur de Java (surtout parce que je n'aime pas du tout ce langage et que je préfèrerais plutôt C++ si j'avais à choisir entre les deux), mais plutôt de démonter des arguments qui ne tiennent pas debout (pas vraiment par vous, au contraire) et de dénoncer l'argument "tout dépend du programmeur" (qui est vrai, mais la question se pose plutôt dans le cas où les programmeurs sont de compétences égales).

--
Jedaï

[pseudocode]

Je n'ai pas l'intention de sortir des arguments techniques en faveur de Java (surtout parce que je n'aime pas du tout ce langage et que je préfèrerais plutôt C++ si j'avais à choisir entre les deux),

Yes, pareil. Je prefere la confortable puissance du C++, meme si je conseille pas ce langage pour debuter. L'ordre "C", puis "Java" et enfin "C++" me semble plus naturel. D'abord voir les 2 paradigmes imperatif et OO avant de plonger dans le multiparadigme et de melanger allègrement le char* et le std::string.

Mais ce n'est pas parceque je prefere le C++ que je ne trouve pas d'avantage a Java. Perso, je trouve un code Java toujours plus lisible/simple qu'un code C++. La syntaxe C++ est vraiment tres lourde, et il faut vraiment faire des efforts pour suivre la logique de programmation de certains codeurs.

[Kujara]

en C++

exist-il un moyen aussi facile qu'en java ( c'est a dire implémenté l'interface Serializable ) pour pouvoir serializer un objet ??????

Boost.Serialize

exist-il un moyen de faire aussi facilement qu'en java des java.lang.reflect.Proxy

Je ne connais pas, explique a quoi ça sert ?

[super_navide]

Boost.Serialize néssécite implementation de la méthode void serialize(Archive & ar, const unsigned int version)
en Java il faut juste implémenter l'interface Serializable
donc moin de boulot...

Explication a l'adresse :

http://java.sun.com/j2se/1.4.2/docs/...ect/Proxy.html

[xololol]

Boost.Serialize néssécite implementation de la méthode void serialize(Archive & ar, const unsigned int version)
en Java il faut juste implémenter l'interface Serializable
donc moin de boulot...[/url]

Et en quoi il y a moins de boulot, entre implémenter une interface en Java, et implémenter une classe abstraite (équivalent d'une interface) en C/C++? Parce que là, soit j'ai loupé un truc, soit on parle pas de la même chose...