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.