Discussion :

[jblecanard]

Salut

Non mais c'est hallucinant l'état d'esprit qui règne ici.

Je suis le seul à blâmer ici, l'état d'esprit général est plutôt bon. Je suis désolé que tu te sois senti agressé, j'ai trouvé tes développements approximatifs malgré les explications claires qui ont été données (et pas spécialement par moi), ça a fait perdre patience à mon esprit cartésien, je reconnais. Je sais que ta participation part d'un intérêt louable et j'aurais dû me tenir. Je ne suis pas méchant, en vrai .

[Freem]

Je pense que "ne fait rien de trop dangereux ici" signifie "est incapable de se faire passer pour un autre" (spoof de la pile d'appels, etc.). Toutes les restrictions de ségrégation au sein d'un même processus (qui sont, elles, gérées à l'exécution comme du le dis) dépendent de ça.
Il appartient donc au compilateur de produire du code que .Net appelle "vérifiable" (mais c'est à l'environnement d'exécution que revient le fait de vérifier, comme tu l'as dit).

C'est d'ailleurs quelque chose que tous les OS fonts, avec plus ou moins de bonheur.

Par exemple, les systèmes type Unix interdisent à un utilisateur d'accéder aux fichiers des autres utilisateurs (pour windows, j'avoue mon manque de connaissance, il parait que ça a bougé depuis windows XP, mais je me suis arrêté a celui-ci).

Un autre exemple est celui ring. Le processeur supporte plusieurs ring, qui donnent chacun différents niveaux de droits aux programmes. Je ne connais pas tout sur ce sujet, juste que ça sert à protéger le matériel. C'est le genre de notions que l'on peut creuser en fouillant du côté des débogueurs ring 0, tels que softice ou rr0d, qui sont capables de déboguer un OS.

Un 3ème exemple, moins profond dans le système, est la gestion de la mémoire. Les applications MS-DOS donnaient un accès complètement libre à la mémoire, permettant même de modifier directement la mémoire graphique à grands coups de pointeurs. Ou la mémoire des autres programmes. Il me semble que ça s'appelle le mode réel.
On est ensuite passé (pour les windowsiens, à cette époque c'était le seul OS que je connaissais) a des systèmes hybrides: windows 9x, qui supportait les programmes en mode réel et les programmes en mode protégé: le mode protégé permettant à la fois une extension de la quantité de mémoire utilisable, l'usage d'instructions manipulant de plus grandes données, etc (on passe du 16 bit au 32 bit) et les OS ont appris des erreurs du passé en interdisant à un processus d'écrire dans la mémoire d'un autre, on ne vois donc que la mémoire réservée pour nous.

Au final, quand on cumule la protection de la mémoire des processus au fait de ne pouvoir accéder qu'aux fichiers de l'utilisateur du processus, on arrive à quelque chose de quand même très sécurisé, bien qu'il soit connu que Xorg (le logiciel permettant d'avoir des IHM sous linux) à des failles qui lui sont propres et permettent d'espionner d'autres applications.

Tout ça pour dire qu'il ne faut pas croire, mais C++ est très sécurisé... quand on à un OS qui l'est aussi.
Ce n'est pas au langage de sécuriser le système, mais bien au système de faire gaffe à ses miches tout seul, parce que sinon on pourrit les performances: chaque couche de contrôle diminue les performances. Une VM est moins performante qu'une machine physique (même si pour les soft/hard ware faits pour, la différence est faible) et un interpréteur est moins performant qu'une VM.

De même, la RTTI ralentis le C++ (quand on s'en sers), et le C++ n'est pas un langage fait juste pour faire des applis de bureau.
Il serait bien de ne pas l'oublier. Rajouter des contrôles spécifiques à un environnement va mécaniquement ralentir le programme, le rendre moins portable, et en plus risque de faire doublon.
Pire, imposer des choses va à l'encontre même de la philosophie du C++, qui est de ne payer que ce qu'on utilise.

[jblecanard]

Un autre exemple est celui ring. Le processeur supporte plusieurs ring, qui donnent chacun différents niveaux de droits aux programmes. Je ne connais pas tout sur ce sujet, juste que ça sert à protéger le matériel. C'est le genre de notions que l'on peut creuser en fouillant du côté des débogueurs ring 0, tels que softice ou rr0d, qui sont capables de déboguer un OS..

C'est utilisé notamment pour la virtualisation, c'est ce mécanisme qui permet de séparer et ordonnancer les OS et les superviseurs.

De même, la RTTI ralentis le C++ (quand on s'en sers)

Ha la grande méchante RTTI . Ca dépend vraiment de ce qu'on fait. Ce qu'il est important de savoir, c'est ce que le code écrit fait exactement. Un appel à typeid() a le même coût qu'un appel à une méthode virtuelle (c'est du RTTI). Un cross-cast dans une large et profonde structure de classe va coûter beaucoup plus cher (c'est aussi du RTTI). J'ai déjà vu des développeurs désactiver le RTTI au nom de cette lenteur pour au final le ré-implémenter (mal) eux-même avec des méthodes virtuelles, c'est quand même dommage.

[ymoreau]

Pour se situer dans le contexte, Pakkanen estime qu’un langage de script diffère d’un langage compilé comme C par les critères suivants :

• pas de gestion manuelle de la mémoire ;
• la syntaxe et les fonctionnalités complexes expressives peuvent être mises en œuvre en seulement quelques lignes de code ;
• des puissantes fonctions de manipulation de chaines ;
• une grande bibliothèque standard.

C'est quoi ces critères absurdes ?
Le 1er est aberrant : Java ne demande pas de gérer manuellement la mémoire, ça n'en fait pas un langage de script pour autant. "Sont pas malins, ils ont inventé JavaScript alors que Java c'est déjà du script"
Les 3 autres sont juste totalement subjectifs et ne caractérisent rien du tout. "Ah j'ai mis + de 5 lignes à faire ma fonctionnalité en Ruby ça n'est donc plus un langage de script"

[therwald]

Comme certains autres, je ne pense pas que la frontière soit parfaitement étanche. Le point majeur est probablement la possibilité d'exécuter directement les sources sans passer par une phase de compilation séparée (et ce indépendamment de l'existence éventuelle d'un traitement de type compilation au sein de l'interpréteur), mais à mes yeux un script est surtout caractérisé par le type d'application: une procédure.
La notion de script renvoie plutôt au déroulement d'un scénario unique, plutôt "moins complexe", plutôt "court" une fois et de bout en bout (aux arrêts sur erreur près), mais la frontière est sans doute assez subjective.
Reste que les langages fortement typés ont tendance à manquer de la souplesse généralement associée avec le développement et la maintenance des scripts.
(mais cette rigidité à mes yeux se transforme en avantage quand on développe une application plus conséquente (volume, complexité) dans la mesure où elle se transforme alors en garde-fou qui limite le risque d'erreur)

[dlandelle]

Pour moi un langage de script doit être simple, et accessible aux neuneus. Ce n'est pas le cas de ce morceau de code qui demande beaucoup de connaissances a priori, et la connaissance d'un paquet de librairies (presque autant d'include que de ligne de code).

Par contre, si on traite de la vidéo avec ce genre de langage, et qu'on fait de l'allocation implicite pour chaque pixel, ça va droit dans le mur.

Pour moi, la puissance de C++, c'est de faire du C dans tous les cas où les objets ne servent pas à grand chose (généricité, héritage, polymorphisme, visibilité, empaquetage, templates ...) c'est à dire dans la majorité des ces dès qu'on sort de l'informatique de "gestion".

[koala01]

Tu as une vision bien restrictive de la programmation orientée objets!!!

Tu pourrais parfaitement envisager de créer des jeux, des compilateurs, des applications de gestion ou de dessin et bien d'autres (auxquelles je ne pense pas pour l'instant) en ayant une approche orientée objets car tu y trouverais des avantages certains (dont, justement, les possibilités d'héritage et de polymorphisme, sans oublier une sécurité accrue en terme de typage).

Bien sur, cela nécessite d'avoir une approche orientée "services rendus" plutôt qu'une approche "data driven", mais les exemples ne manquent pas dans les trois domaines que je viens de citer

[Médinoc]

@Freem: Dans l'état actuel de Windows et Linux, tous les processus user-mode appartenant à un même utilisateur ont les même droits,* à moins d'être explicitement isolés sur une autre machine (qui peut être virtuelle).

Les machines virtuelles, langages de script etc. permettent d'isoler les droits de manière plus précise: Non seulement entre processus d'un même utilisateur, mais entre composants d'un même processus.

*Sous Windows il y a la notion de privilège qui change d'un processus à l'autre, mais un programme malveillant non-isolé pourra toujours lire et effacer les documents personnels de l'utilisateur qui l'exécute.
Il y a aussi la notion hybride de jeton d'accès restreint, qui "retire" à un processus son appartenance à un groupe et donc les droits d'accès qui vont avec. L'UAC de Vista est basé dessus;

[white_tentacle]

@Freem: Dans l'état actuel de Windows et Linux, tous les processus user-mode appartenant à un même utilisateur ont les même droits,* à moins d'être explicitement isolés sur une autre machine (qui peut être virtuelle).

Il me semble que c’est faux avec SELinux/AppArmor.