Discussion :

[Jean-Marc.Bourguet]

Non. Pour moi ce qui est etonnant c'est qu'un programmeur utilise la reflection pour modifier une variable locale.

Bis repetita:

La surete de Java est presentee comme une garantie contre des attaques malicieuses. Ne pas proteger des entrees en C++, c'est de l'incompetance. Ne pas proteger des litteraux en Java, c'en est aussi ?

Oui Java est plus sur que C++. Mais C++ n'est pas vendu avec des arguements de securite. Et le trou me semble gros. Et mal connu. Et c'est moi qui ait du indiquer comment le boucher dans cette discussion.

De toutes facon, ca ne m'interesse pas de savoir si un "mauvais" programme Java est plus dangereux qu'un "mauvais" programme C++ sur une echelle ou le crash est preferable à la modification des literraux.

J'aimerais bien savoir les criteres qui te font preferer un fonctionnement incorrect silentieux a un crash.

Ce qui m'interesse nettement plus, c'est de savoir si un "bon" programme Java est qualitativement meilleur qu'un "bon" programme C++. Par exemple en utilisant les attributs qualités du FURPSE (Functionality, Usability, Reliability, Performance, System Maintainability, Evolutivity).

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.

[xololol]

Hum...

Je n'ai jamais dis que le java n'avait pas sa raison d'être, mais arrêter de comparer le java et le C++, ils n'ont ni le même domaine d'applications, ni la même raison d'être.

Un programme client simple (connecté à un serveur ou non), peut aisément être fait en java... pour ce qui est des applications qui gérent de gros volumes de données, et doivent faire de la performance avant tout, on choisira du C++.

Bref, ne dites pas "C++ est mieux que... parce que..." ni "java est mieux que... parce que...", cela est absurde... Il faut d'abord savoir de quel type d'application on parle, et ensuite du niveau de fiabilité et de performance que l'on attends du programme en question...

De toute façon, le plus important en programmation est une bonne algorithmie, le langage n'est que secondaire (et vous ne me ferez pas dire le contraire), après le choix du langage dépendra de ce que l'on attends de l'application. Un calcul scientifique lourd partagé sur un réseau de machines ne sera codé en java que par un inculte. Un programme ne faisant que de la lecture vidéo ou audio par exemple sera très bien fait en java, sans trop de mal (en C++ aussi, mais bon...).

Quant à la reflectivité.... à part pour de l'IA (et encore, une IA qui fait ce qu'elle veut comme elle veut, je trouve ça dangereux, mais c'est un avis purement personnelle), je ne vois pas trop l'intérêt, en tout cas, cela ne m'a jamais manqué en C++, et si l'on a une bonne algorithmie, je ne pense pas que cela soit vraiment utile...

[Jean-Marc.Bourguet]

Pour avoir appris le C avant le java, puis être repassé au C++ pour des raisons professionnelles, je peux te dire que ce n'est pas rendre service au débutant que de ne pas lui apprendre les concepts de gestions de mémoire (base de la programmation)...

Le probleme n'est pas d'apprendre ou de ne pas apprendre. C'est l'ordre d'apprentissage. Il est des choses qu'il vaut mieux maitriser avant d'autres. Et se taper des pointeurs avant d'avoir compris ce qu'est une variable, c'est pas le mieux. C'est a cause de ca que je prefererais enseigner le C++ a des debutants plutot que le C. Et il est d'autres langages que je prefererais au C++ (Ada pour commencer; Java peut-etre --- je ne le connais pas assez -- et si j'avais reellement le choix, un langage dynamique, scheme par exemple). Mais bon, je n'ai jamais enseigne la programmation a des debutants, je ne suis pas sur d'etre competant pour commenter reellement (j'ai enseigne des langages a des gens ayant deja une certaine experience; ca me rend toujours mieux place que ceux qui n'ont que leur experience personnelle)

Meme symptomes, sauf qu'en c++ tu peux creer un outil pour detecter les leaks, apres quoi, ça prends 15 secondes a trouver

Il n'y aurais pas d'outils en Java capable d'analyser les allocations memoire faites par un programme? Je ne le crois pas.

[pseudocode]

Ouch....
Tu confonds runtime engine et runtime library.
(...)
Bref, pas de runtime engine en c++ bien sur.....

ok, si tu veux. Appelons ca "runtime environement" et tout le monde sera content.

Le java, lui, necessite la JVM installé puisque c'est du code "controllé" et non directement executé sur le proc.

[ironic]
non, c'est clair qu'un programme Java n'est pas directement executé sur un processeur... le processeur c'est "has been" et completement obsolete. un programme Java est directement executé dans le clavier (et parfois en parallele dans la souris pour décharger le clavier).
[/ironic]

Ok, la chaine de compilation/execution est differente en Java et en C++. C'est d'ailleur de la que viennent les differences de fonctionalités et de performances entre les deux langages. Ce point la etant clarifié, on pourrait peut-etre avancer...
-Fonctionalités ?
-Simplicité ?
-Sécurité ?
-Performance: avantage au C++
-Maintenabilité ?
-Evolutivité ?

[adiGuba]

Oui Java est plus sur que C++. Mais C++ n'est pas vendu avec des arguements de securite.

Ces arguments concernent l'exécution à distance (via une applet et surtout Java Web Start) où les applications sont limitées dans leurs traitements (sauf si elles sont signé et autorisé par l'utilisateur). Ce code-ci provoquerait des SecurityException que ce soit lors de l'accès aux champs (getDeclaredField()) ou lorsque tu tentes de les modifier (setAccessible() et set()).

En local c'est normal qu'une application ait tous les droits...

J'aimerais bien savoir les criteres qui te font preferer un fonctionnement incorrect silentieux a un crash.

Mais il n'y a pas vraiment de comportement silencieux en Java

Quant à la reflectivité.... [...], je ne vois pas trop l'intérêt, en tout cas, cela ne m'a jamais manqué en C++, et si l'on a une bonne algorithmie, je ne pense pas que cela soit vraiment utile...

La réflectivité permet de développer des outils vraiment générique, par exemple pour faire du mapping objet<->XML (XStream) ou objet<->BD (EoD SQL) ou encore de l'injection de donnée (Fuse).

Bien sûr il est toujours possible de faire autrement, mais c'est franchement sympathique

a++

[xololol]

Et se taper des pointeurs avant d'avoir compris ce qu'est une variable, c'est pas le mieux. C'est a cause de ca que je prefererais enseigner le C++ a des debutants plutot que le C.

Oui, bien sûr, mais premièrement, je n'ai pas choisi le C pour apprendre, on me l'a imposé (et oui en cours, on choisit rarement, lol).
Et je n'ai pas dis qu'il fallait apprendre les pointeurs avant les variables, on peut faire des ptits programmes "Hello, world" sans pointeurs en C... Donc faux débat... Mais le C/C++ est plus complet dans son approche de l'architecture machine, et excusez moi d'être un puriste, mais je pense que pour programmer correctement, avoir qq notions d'assembleur, de registre mémoire (processeur) et d'adressage n'est pas un luxe, au moins pour comprendre mieux ce qu'il se passe en machine...

Beaucoup de "programmeurs" amateurs font leurs programme sans se soucier de tout cela (et ça marchera pareil bien sûr), mais la programmation, ce n'est pas de la magie, hein !!!! Faut comprendre ce que l'on fait un minimum (même si un niveau d'ingénieur en architecture processeur n'est pas nécessaire, évidemment)...

Imaginez un chimiste qui ne connaisse pas la structure de l'atome...

[Jean-Marc.Bourguet]

Heu... Au contraire je trouve cela bien plus sûr en Java...
Je n'ai pas vraiment d'expérience du C++ mais j'ai fait beaucoup de C, et il n'est pas rare qu'une erreur ait un comportement aléatoire et ne plante pas forcément (en particulier sur un buffer-overflow).

Il n'y a pas vraiment de comportements silencieusement incorrects en Java... mais c'est généralement sanctionné par une exception

Bug typique chez moi. On detruit un objet. Une reference est gardee quelque part.

C++: Crash/Comportement aleatoire/... breakpoint sur acces memoire/purify, fix.

GC (lisp chez moi, mais Java serait la meme chose): comportement errone identique partout, beaucoup plus difficile a detecter. Et on a 10 x moins de Lisp.

(Note il y a des avantages au comportement avec GC, en particulier en ce qui concerne la securite.)

Et comme tu l'a dit toi même cela peut être bloqué par un SecurityManager afin d'éviter que du code "inconnu" (comme un plugin par exemple) ne puisse mettre en péril ton application...

Oui, c'est dommage que ce soit moi qui ait du signaler le probleme et la solution. Pas particulierement ici mais ailleurs.

Par contre l'API de réflection apporte vraiment un gros plus à Java et permet vraiment beaucoup de chose sympa

Pas reellement d'avis la dessus. Ca resoud des problemes que je n'ai pas. Par contre, j'ai besoin de process avec plus de 4G de memoire -- un collegue cherchait une machine avec 32 G recemment. On n'a explique que ca eliminait Java d'office.

[Jean-Marc.Bourguet]

on peut faire des ptits programmes "Hello, world" sans pointeurs en C...

Code :

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

1
2
putc('H'); putc('e');...

[pseudocode]

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...

[xololol]

Code :

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

1
2
putc('H'); putc('e');...

Code :

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

1
2
3
4
5
6
7
#include <stdio.h>
int main ()
{
	char oin[] = "Hello world";
	printf ("%s", oin);
}

D'accord, ya un pointeur planqué, mais on est pas obligé de le dire au débutant lol...

[adiGuba]

Bug typique chez moi. On detruit un objet. Une reference est gardee quelque part.

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

Oui, c'est dommage que ce soit moi qui ait du signaler le probleme et la solution. Pas particulierement ici mais ailleurs.

Oui je veux bien croire que ceci est particulièrement méconnu... mais comme point méconnu du langage il y a bien pire sur le forum Java je te rassure

Par contre, j'ai besoin de process avec plus de 4G de memoire -- un collegue cherchait une machine avec 32 G recemment. On n'a explique que ca eliminait Java d'office.

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).
• 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).

a++

[Jedai]

Quant au FURPSE, tout cela dépend du PROGRAMMEUR, et non du langage de prog... c'est une légende urbaine ça....

Mais bien sûr, d'ailleurs on se demande bien pourquoi on s'embête à coder en autre chose que de l'assembleur...

Après une attaque en règle de fanboys de Java, je vois maintenant beaucoup de mauvaise foi de la part d'adeptes du C++, 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, et de toute façon on ne rencontre pratiquement jamais un code comme celui-ci en production. Expliquer ensuite que cet exemple est pour montrer qu'un plantage est préférable à un comportement incorrect silencieux...
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 !
Et personnellement je préfère encore un programme qui ne plante pas et se comporte correctement, et que je sache, le GC permet d'éviter pas mal de problèmes de ce côté là (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).

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 ?), c'est très drôle : sommes nous en train de choisir un langage pour débutant ? Je croyais que ce forum était consacré aux professionnels ?

--
Jedaï

[xololol]

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...

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, les seuls vrais hacker devait disposer d'un matériel assez cher et rare pour l'époque, et donc la plupart du temps les gens avec ce genre de matos était les chercheurs, universitaires, etc, pour lesquels la dimension sécurité ne représenté rien à l'époque, puisque le concept de hacking est apparu après...

Lorsque le java a vu le jour, 90% des failles de sécurités de C/C++ était bouché ou connu, ce qui fait que les développeurs de la JVM n'ont eu qu'a implémenter les solutions déjà trouver avant pour la plupart.

Depuis, il me semble que justement gràce à son pléthore de fonctions securisées (strnlen, etc) le C/C++ a largement rattrapé son retard en matière de sécurité, et que tout bon développeur utiliseras les fonctions connues pour être sécurisées, et non les deprecated...

Donc pour le R, je dirais que cela dépend surtout du programmeur, et non du langage en lui-même... (comme pour le reste d'ailleurs)...

[xololol]

Mais bien sûr, d'ailleurs on se demande bien pourquoi on s'embête à coder en autre chose que de l'assembleur...

C'est vrai que je me suis mal exprimé, j'aurais dû mettre :
Quant au FURPSE, tout cela dépend avant tout du programmeur, et ensuite du langage...

Ce que je voulais dire par là, c'est qu'il est facile de pondre un code imbuvable, illisible, non maintenable, et ce peut importe le langage, autant en assembleur qu'en C/C++ qu'en Java... donc bof.

[pseudocode]

Lorsque le java a vu le jour, 90% des failles de sécurités de C/C++ était bouché ou connu, ce qui fait que les développeurs de la JVM n'ont eu qu'a implémenter les solutions déjà trouver avant pour la plupart.

Je ne parlais pas de l'implementation de la JVM, mais de l'implémentation d'une application Java.

C'est tres dur de faire un "buffer overflow" non catché en LANGAGE Java.

Alors que c'est toujours aussi simple de faire un "buffer overflow" en LANGAGE C/C++, malgrés toutes les evolutions du langage.

Etant donné le nombre de failles/crash qui sont dus a ce probleme, je ne comprend pas que le langage C/C++ n'ai pas évolué de ce coté la.

[gorgonite]

Etant donné le nombre de failles/crash qui sont dus a ce probleme, je ne comprend pas que le langage C/C++ n'ai pas évolué de ce coté la.

il a évolué, mais il semblerait que trop peu de personnes utilisent les bonnes fonctions

[xololol]

J
C'est tres dur de faire un "buffer overflow" non catché en LANGAGE Java.

Effectivement, et cela dépend directement de l'implémentation de la JVM et des packages associés...
Quant au buffer overflow en C/C++, crois moi que les développeurs qui sont "aware" de la sécurité utilisent les fonctions qui ne permettent pas le buffer overflow, et que donc le C/C++ a évolué de ce côté, et encore heureux pour la JVM qui est codé en C++ (hum....)

[pseudocode]

il a évolué, mais il semblerait que trop peu de personnes utilisent les bonnes fonctions

Quant au buffer overflow en C/C++, crois moi que les développeurs qui sont "aware" de la sécurité utilisent les fonctions qui ne permettent pas le buffer overflow (...)

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

Code C :

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

1
2
3
4
5
6
7
8
9
10
 
char str[] = "Hello world.";
try
    {
        str[12]='!';
    }
catch (bufferoverflow &ex)
    {
        cout << "Ouch!" << endl;
    }

Faut-il bannir l'utilisation de char[]/char* en C++ et utiliser seulement la STL ?

[HanLee]

Expliquer ensuite que cet exemple est pour montrer qu'un plantage est préférable à un comportement incorrect silencieux...
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 !

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 ?

Naïvement : le plantage permet de se rendre compte tout de suite qu'il y a un problème à partir d'un moment précis, et il suffit souvent de remonter un peu dans le temps pour comprendre.
Si ce plantage n'avait pas eu lieu, alors on se serait rendu compte du comportement bizarre surement bien longtemps après, ce qui rend d'autant plus difficile de trouver la source du problème.

Mais peut-être que tu penses à autre chose.

-----

Après, les problèmes de dangling pointers, il faudrait trouver un exemple où la solution ne se résume pas à un bête GC ou bien un pointeur intelligent.

Peut-être en programmation graphique (DirectX), où l'on est tout le temps amené à libérer et réallouer de manière déterministe les ressources graphiques.

Et personnellement je préfère encore un programme qui ne plante pas et se comporte correctement, et que je sache, le GC permet d'éviter pas mal de problèmes de ce côté là (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).

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 ?), c'est très drôle : sommes nous en train de choisir un langage pour débutant ? Je croyais que ce forum était consacré aux professionnels ?

--
Jedaï

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 ?

[Kujara]

Faut-il bannir l'utilisation de char[]/char* en C++ et utiliser seulement la STL ?

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...

le GC permet d'éviter pas mal de problèmes de ce côté là (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).

En quoi le GC est limité au Java ? 8)

Ca existe forcement, des gestionnaires de mémoire pour c++.

J'en utilise pas, mais j'imagine que c'est juste une librairie a inclure, et elle gere la mémoire. Suffirait d'appeler ses fonctions plutot que new / delete de base.

Bref, un memory Pool en plus avancé.