[naïf] C++ et W.W.W.

Henri de Solages wrote:

Tu peux développer tes cgi en C++. Ca consiste à écrire ton
code HTML généré sur std::cout. Le serveur s'occupe du
reste.

Avec les wchar et wstring, peut-on écrire tous les caractères
Unicode ?

Comme l'a dit James c'est plutôt la nature compilée de C++
qui rend la chose fastidieuse et donc peu répandue. Les
poids lourds sont des langages de script (Perl, Python,
...). On référence directement le fichier source dans l'URL,
et ça marche.

"Langage de script" signifie langage interprétés par le
client, c'est ça ?

Je ne crois pas qu'il y a une définition officielle. En général,
j'entends un langage interprété directement, sans passer par
l'intermédiaire d'un compilateur. (En fait, je crois que
beaucoup de langages de script compilent en un Byte code en
interne.)

Parmi les langages de script, je distinguerais bien ceux qui
s'imbriquent dans le texte de la page, genre JSP (et je crois
PHP), et ceux plus général qui travaille en dehors de la page,
genre Perl ou Python (qui servent également à beaucoup d'autres
chose).

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

adeba...@club-internet.fr wrote:

Fred wrote:

Egalement, on ne voit pas vraiment l'intérêt de compiler un
language Web: pour pouvoir le modifier rapidement et
simplement, et ne pas avoir de problèmes de portabilités,
l'interprété est Roi.

Cet argument me semble fallacieux quand on parle de
"programmation Web" (oh, le beau terme commercial fourre-tout
qui ne veut rien dire!!)

Ça veut dire plutôt plusieurs choses à la fois, non ?

côté serveur : Tu connais l'architecture de ton serveur Web
(enfin, il faut espérer), et ton appli ne sera jamais déployée
que sur ce serveur, donc l'interprété n'apporte rien de ce
point de vue en "portabilité".

Ça dépend. Si tu travailles dans une grosse boîte qui herberge
son site sur ses propres machines, oui. Si tu dépends d'un
herbergeur externe, en revanche, tu dépends de son architecture.
Alors, il faut prendre en compte plusieurs choses :

-- Typiquement, il ne garantit pas son architecture. Donc, mon
herbergeur en Allemagne utilisait un parc de machines SGI.
Mais rien ne me dit qu'il n'est pas en train aujourd'hui de
migrer vers Linux sur PC. En revanche, il me garantissait la
présence de Perl.

-- Normallement, tu ne peux pas faire un rlogin et développer
chez l'herberger -- il faut développer l'« exécutable » chez
toi, puis l'installer tout fait. Pour le Perl ou le Python,
où l'« executable » est ton source, et que c'est identique
quelque soit l'architecture, aucun problème. Mais si le
herbergeur tourne sur CGI, et tu n'as accès que des Sparc et
des Linux, comment fais-tu pour compiler et tester ?

Ce qui me semble par contre plus juste, c'est que c'est
beaucoup plus facile pour le serveur Web de se prémunir contre
du code mal écrit dans un langage interprété (PHP, Perl, ASP,
etc...), que en C++ (où on peut toujours crasher le processus
avec un pointeur foireux).

Que ce soit du Perl ou du C++, les scripts CGI tournent dans un
processus à part. En cas d'erreur dans le programme, tu (ou
plutôt celui qui visite la page) reçois ce qui a été fait. Dans
le cas de PHP ou de JSP, je crois qu'il y a un interpréteur pour
tout le monde. Tu réussis à trouver une faille dans
l'interpréteur, et le faire planter, et plus aucune page ne
marche. (En revanche, dans la mesure où ces environements ont
été conçus pour ça, ils ont des contrôles supplémentaires. Donc,
par exemple, typiquement tu ne peux pas faire un chdir plus bas
que ta racine. Alors qu'en C++... Il faut qu'ils aient établi
les droits bien comme il faut.)

Pour la stabilité du serveur, il vaut donc mieux un langage
qui interdise de se tirer une balle dans le pied.

C'est plus compliqué que ça, quand même, et la stabilité du
serveur ne dépend pas de la correction des programmes qu'il
invoque.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

kanze wrote:

Que ce soit du Perl ou du C++, les scripts CGI tournent dans un
processus à part. En cas d'erreur dans le programme, tu (ou
plutôt celui qui visite la page) reçois ce qui a été fait.

Il y a de moins en moins de serveurs Web qui lancent des processus
séparés type CGI pour le code côté serveur, à cause de la
surcharge pour le système de créer tous ces processus à durée de
vie très courte.

Il me semble même me souvenir qu'il y a quelques années, c'était
l'une des évolutions majeures d'Apache qu'en il est passé du modèle
CGI avec processus séparés à un modèle multithread où le code est
executé dans le processus du serveur lui-même (bien sûr, ca suppose
que la plate-forme propose des threads, ou alors il faut les émuler).

Dans
le cas de PHP ou de JSP, je crois qu'il y a un interpréteur pour
tout le monde.
Oui, qui généralement tourne directement dans le processus serveur

(le plus souvent sur un pool de threads, ce qui permets de controler
les ressources utilisées)

Tu réussis à trouver une faille dans
l'interpréteur, et le faire planter, et plus aucune page ne
marche.
C'est vrai aussi, mais je n'ai pas souvenir d'avoir jamais vu de tels

"exploits". Aujourd'hui, on sait relativement bien faire une "sand-box"
qui contrôle de manière fiable l'environnement d'execution d'un
langage interprété.

Pour la stabilité du serveur, il vaut donc mieux un langage
qui interdise de se tirer une balle dans le pied.

C'est plus compliqué que ça, quand même, et la stabilité du
serveur ne dépend pas de la correction des programmes qu'il
invoque.
Si le langage est executé dans le processus du serveur Web (ce qui est

souvent le cas pour des raisons de performances), alors si, c'est lié.

Note : On pourrait aussi executer du C++ directement dans le processus
serveur avec des librairies dynamiques.

Arnaud

On 15 Sep 2005 07:06:58 -0700, "kanze" <kanze@gabi-soft.fr>:

"Langage de script" signifie langage interprétés par le
client, c'est ça ?

Je dirais qu'un langage de script est un langage où tout est chaîne de
caractères -- y compris le code et les fonctions.

Exemple : un "Hello world!" (tordu) en PHP

<?php

function foo42()
{
echo "Hello world!";
}

$code1= '$a= 42;';

eval ($code1);
$nom_fonction= "foo$a";
$nom_fonction();

?>

Parmi les langages de script, je distinguerais bien ceux qui
s'imbriquent dans le texte de la page, genre JSP (et je crois
PHP)

PHP a les deux approches : il peut servir, comme Perl, de langage
totalement indépendant d'HTML (je m'en sers d'ailleurs beaucoup pour
faire des traitements sur certains fichiers textes, traitements
généralement pénibles à faire en C++), ou être intégré à une page
web :

<html><body>2 + 2 = <?php echo 2+2 ?></body></html>

adebaene@club-internet.fr wrote:

kanze wrote:

Que ce soit du Perl ou du C++, les scripts CGI tournent dans
un processus à part. En cas d'erreur dans le programme, tu
(ou plutôt celui qui visite la page) reçois ce qui a été
fait.

Il y a de moins en moins de serveurs Web qui lancent des
processus séparés type CGI pour le code côté serveur, à cause
de la surcharge pour le système de créer tous ces processus à
durée de vie très courte.

Il y a de moins en moins de sites qui se servent de CGI:-).

Dans le cas de Perl, évidemment, il n'y a pas de problème à
integrer Perl comme « bibliothèque » dans le processus du
serveur@; il faut s'arranger pour que ce que Perl considère les
entrées/sorties standard arrivent où on veut, mais ce n'est pas
la fin du monde.

Dans le cas d'un programme CGI écrit en C++, c'est autre chose.
Et un des principes du CGI, c'est qu'on peut le faire en
n'importe quel langage -- c'est un protocol entre deux
programmes, et non un langage.

En ce qui concerne les ressources, c'est vrai que lancer un
nouveau processus à chaque requête coûte cher. Mais
réinterpréter un programme en ASCII aussi.

Il me semble même me souvenir qu'il y a quelques années,
c'était l'une des évolutions majeures d'Apache qu'en il est
passé du modèle CGI avec processus séparés à un modèle
multithread où le code est executé dans le processus du
serveur lui-même (bien sûr, ca suppose que la plate-forme
propose des threads, ou alors il faut les émuler).

En supposant que le CGI était bien en Perl, et non un exécutable
quelconque, je suppose. (Je crois que Python offre les mêmes
possibilités de Perl ici.)

Je ne sais pas s'il concerne le CGI, mais je sais que des
serveurs commerciaux se vantent même de garder la forme
intermédiaire que l'interpréteur exécute réelement, de façon à
ce que la source ne soit lue et interprétée qu'une seule fois.

Dans le cas de PHP ou de JSP, je crois qu'il y a un
interpréteur pour tout le monde.

Oui, qui généralement tourne directement dans le processus
serveur (le plus souvent sur un pool de threads, ce qui
permets de controler les ressources utilisées)

Apache et WebSphere, au moins, integre aussi un JVM, de façon à
ce que le Java s'exécute aussi dans le même processus. D'après
mes souvenirs, d'ailleurs, la combinaison JSP/Java prévoit même
des variables dont la durée de vie dépasse la requête -- on n'a
pas besoin d'aller à la base de données à chaque requête HTTL
pour savoir où on en est dans la transaction.

Tu réussis à trouver une faille dans l'interpréteur, et le
faire planter, et plus aucune page ne marche.

C'est vrai aussi, mais je n'ai pas souvenir d'avoir jamais vu
de tels "exploits". Aujourd'hui, on sait relativement bien
faire une "sand-box" qui contrôle de manière fiable
l'environnement d'execution d'un langage interprété.

Pour une attaque visée, il faut bien s'inscrire au près du
fournisseur, pour avoir des pages de Web. C'est bien moins
anonyme qu'une attaque à travers l'Internet.

Sinon, évidemment, il faudrait y tomber par hazard. Chose que je
suis certain s'est déjà passé, par ci ou par là, et qui a
probablement donné lieu à des corrections dans la VM concernée.
(Je sais que j'ai déjà eu des core dump du jrt. Pourquoi est-ce
qu'il serait plus fiable integré dans un serveur de Web.)

Pour la stabilité du serveur, il vaut donc mieux un
langage qui interdise de se tirer une balle dans le pied.

C'est plus compliqué que ça, quand même, et la stabilité du
serveur ne dépend pas de la correction des programmes qu'il
invoque.

Si le langage est executé dans le processus du serveur Web (ce
qui est souvent le cas pour des raisons de performances),
alors si, c'est lié.

Note : On pourrait aussi executer du C++ directement dans le
processus serveur avec des librairies dynamiques.

Mais là, évidemment, c'est vraiment se mettre à la merci de la
qualité des programmes fournis.

En fait, si mes souvenirs sont exactes, même dans le cas de
Java, Apache utilise un processus à part pour la machine
virtuelle qui exécute les programmes JSP. C'est un processus qui
est lancé au démarrage du système, qui est toujours là, et qui
est commun à toutes les requêtes. Mais c'est un processus à part
quand même, et si perchance il disparaît, on le rédémarre, sans
que le serveur même en soit autrement perturbé.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

"Langage de script" signifie langage interprétés par le
client, c'est ça ?

Je dirais qu'un langage de script est un langage où tout est chaîne de
caractères -- y compris le code et les fonctions.

Pour moi, un langage de scripts c'est un langage où le redistribuable
c'est le fichier source (script = manuscrit...).

--
Aurélien Regat-Barrel

Aurelien Regat-Barrel wrote:

"Langage de script" signifie langage interprétés par le
client, c'est ça ?

Je dirais qu'un langage de script est un langage où tout est
chaîne de caractères -- y compris le code et les fonctions.

Pour moi, un langage de scripts c'est un langage où le
redistribuable c'est le fichier source (script =
manuscrit...).

Je suis bien d'accord avec ta définition : quand on parle des
langage de scripts, c'est un langage où le seul support du
programme est la source -- il n'y a pas d'autre exécutable.

Étymologiquement parlant, en revanche, je crois que la
signification de script (en anglais) qui a joué est celui de
scénario. Le rapprochement de « script » à l'écriture proprement
dite (comme dans manuscrit) est plutôt savant. Je crois que
l'idée, c'est que le script ici joue le même rôle qu'un script
de cinéma -- il dit à l'acteur (ici, l'ordinateur) ce qu'il doit
faire.

De ce côté, on a une autre caractèristique des langages de
script -- ils servent en général pour invoquer des
fonctionnalités d'autres programmes. Si des langages plus
récents, comme Perl ou Python, s'en éloigne, c'est bien le cas
des scripts de shell, où tout le véritable travail est fait par
des programmes invoqués par ces scripts.

(Si je ne me trompe pas, le nom vient du monde de Unix, et
s'appliquait bien au début aux scripts de shell. Or, le shell
servait surtout au départ comme programme interactif. Quand on
remplace les repliques improvisées genre comedia dell'arte avec
une dialogue écrit, on a un « script ».)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Fri, 16 Sep 2005 10:32:33 +0200, Aurelien Regat-Barrel
<nospam.aregatba@yahoo.fr>:

Pour moi, un langage de scripts c'est un langage où le redistribuable
c'est le fichier source (script = manuscrit...).

PHP est généralement interprété, mais peut être compilé[*]. Pourtant
ça reste le même langage.

À une époque, je programmais en Basic, et le fichier "redistribuable"
était le fichier source, .bas. Mais il existait un
"pseudo-compilateur", qui permettait de mettre le source et
l'interpréteur dans le même .exe. Pourtant, là encore, ça reste le
même langage.


[*] <http://www.roadsend.com/home/index.php?SMC=1> par exemple

Fabien LE LEZ wrote:

On Fri, 16 Sep 2005 10:32:33 +0200, Aurelien Regat-Barrel
<nospam.aregatba@yahoo.fr>:

Pour moi, un langage de scripts c'est un langage où le
redistribuable c'est le fichier source (script =
manuscrit...).

PHP est généralement interprété, mais peut être compilé[*].
Pourtant ça reste le même langage.

Je me démande si le PHP est un langage scripté, dans le sens
classique.

À une époque, je programmais en Basic, et le fichier
"redistribuable" était le fichier source, .bas. Mais il
existait un "pseudo-compilateur", qui permettait de mettre le
source et l'interpréteur dans le même .exe. Pourtant, là
encore, ça reste le même langage.

Je n'ai jamais entendu parler de Basic comme un langage scripté.

En fait, je me démande si la signification n'est pas en trait
d'évoluer. Au départ, je crois bien que le caractèristique qui
faisait qu'on parlait de scripts, c'est que le langage servait
surtout en interactif ; une caractèristique secondaire, c'était
peut-être que le langage servait plus à invoquer d'autres
commandes qu'à d'autres choses.

Déjà avec Perl, cette deuxième caractèristique s'attenuait. Et
si les premières utilisations de Perl, c'était bien des
« one-liner », comme on dit, où le « programme » était donné sur
la ligne de commande, je ne connais personne qui se sert de Perl
comme un shell, en y restant en interactif. Selon la définition
classique, je ne crois pas non plus que Perl soit un langage de
script. Mais j'ai l'impression assez forte que cette définition
a évoluée, pour devenir quelque chose de très imprécise, où
comme on a déjà dit ici, l'important, c'est qu'on exécute à
partir des sources, sans compilation préalable, et que donc ce
sont les sources qu'on distribue chez les utilisateurs.

N'empêche que si je dis à un collègue que je vais écrire un
script pour faire quelque chose, on entend bien un script de
shell : soit Bourne shell, soit ksh. (Mais ça tient peut-être de
l'environement : on utilise très peu de Perl, et pas du tout de
Python ni des langages de génération des pages de Web.)

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

PHP est généralement interprété, mais peut être compilé[*].
Pourtant ça reste le même langage.

Je me démande si le PHP est un langage scripté, dans le sens
classique.

À une époque, je programmais en Basic, et le fichier
"redistribuable" était le fichier source, .bas. Mais il
existait un "pseudo-compilateur", qui permettait de mettre le
source et l'interpréteur dans le même .exe. Pourtant, là
encore, ça reste le même langage.

On trouve ça pour à peu près tous les langages de script je crois. Même
les .bat ont leur compilateur. A l'inverse, on trouve des interpréteurs
de C/C++ (CINT, ...).
Il n'empêche, je pense, que si tu redistribues ton programme PHP sous
forme compilée, tu redistribues un banal exe et non pas un script PHP.
Un script PHP peut être compilé en un exe. Ca ne fait pas de ce dernier
un script PHP, AMHA. Pour moi, si tu fournis un script à un client, ce
dernier doit être capable de l'éditer directement. En clair, le script =
le code source. Que tu te serves d'un langage de script pour générer un
programme compilé, c'est autre chose.

Je n'ai jamais entendu parler de Basic comme un langage scripté.

Y'a le vb script sous Windows.

--
Aurélien Regat-Barrel