[debutant] Premier programme en C++, qu'en pensez-vous?
54 réponses
Beware
Bonjour,
J'ai depuis une grosse semaine commenc=E9 =E0 apprendre le C++. Je
l'apprends de mani=E8re autonome (ce qui n'est pas totalement une
excuse). Pour ce fait, je suis les tutos pour C++ du site du zero.
J'ai donc utilis=E9 leur exemple de (tr=E9s tr=E9s) petit RPG, mais qui me
permet de manipuler certains concept de base en C++.
Pour en revenir donc =E0 ce message, je voudrais demander aux
connaisseurs qui peuvent et surtout qui veulent si il pouvait jeter un
oeil =E0 mon code pour me dire tout ce qu'il ne va pas et que par
cons=E9quent je devrais am=E9liorer (ou carr=E9ment changer :) )
Merci =E0 eux.
L'ensemble des fichiers sont disponibles =E0 cette adresse :
http://beware007.free.fr/Projet_C++/rpg/
Au revoir
PS : Je pr=E9cise que j'ai cod=E9 sous C::B et sous Linux.
Faut il implementer dans chacune des classes que l'on code et ce évidement si l'on ne s'en sert pas : - le desctructeur, - le constructeur par copie, - l'opérateur d'assignation ?
Les implémenter non, mais les expliciter souvent.
En cas d'héritage, public, et autres entités je pars par défaut sur : - destructeur virtuel public, - opérateur d'affectation désactivé - constructeur de copie désactivé -- ou alors protégé et accompagn é d'une fonction virtuelle de clonage pour les rares cas où j'ai besoin de duplication sur des objets polymorphes
En cas d'objet valeur, soit je les définis en fonction de la présence de ressource brute dans la classe. Soit je mets un commentaire comme quoi les attributs de la classe me permettent de ne pas les définir. Et en cas de ressources encapsulées dans des "capsules" RAII, seul le destructeur échappe à sa définition explicite, mais pas à un commentaire pour signaler que son absence est normale en fonction des attributs courants de la classe.
-- Luc Hermitte
On 30 juil, 16:17, Beware <mathieu.hed...@gmail.com> wrote:
Faut il implementer dans chacune des classes que l'on code et ce
évidement si l'on ne s'en sert pas :
- le desctructeur,
- le constructeur par copie,
- l'opérateur d'assignation ?
Les implémenter non, mais les expliciter souvent.
En cas d'héritage, public, et autres entités je pars par défaut sur :
- destructeur virtuel public,
- opérateur d'affectation désactivé
- constructeur de copie désactivé -- ou alors protégé et accompagn é
d'une fonction virtuelle de clonage pour les rares cas où j'ai besoin
de duplication sur des objets polymorphes
En cas d'objet valeur, soit je les définis en fonction de la présence
de ressource brute dans la classe. Soit je mets un commentaire comme
quoi les attributs de la classe me permettent de ne pas les définir.
Et en cas de ressources encapsulées dans des "capsules" RAII, seul le
destructeur échappe à sa définition explicite, mais pas à un
commentaire pour signaler que son absence est normale en fonction des
attributs courants de la classe.
Faut il implementer dans chacune des classes que l'on code et ce évidement si l'on ne s'en sert pas : - le desctructeur, - le constructeur par copie, - l'opérateur d'assignation ?
Les implémenter non, mais les expliciter souvent.
En cas d'héritage, public, et autres entités je pars par défaut sur : - destructeur virtuel public, - opérateur d'affectation désactivé - constructeur de copie désactivé -- ou alors protégé et accompagn é d'une fonction virtuelle de clonage pour les rares cas où j'ai besoin de duplication sur des objets polymorphes
En cas d'objet valeur, soit je les définis en fonction de la présence de ressource brute dans la classe. Soit je mets un commentaire comme quoi les attributs de la classe me permettent de ne pas les définir. Et en cas de ressources encapsulées dans des "capsules" RAII, seul le destructeur échappe à sa définition explicite, mais pas à un commentaire pour signaler que son absence est normale en fonction des attributs courants de la classe.
-- Luc Hermitte
Jean-Marc Bourguet
Luc Hermitte writes:
On 30 juil, 16:17, Beware wrote:
Faut il implementer dans chacune des classes que l'on code et ce évidement si l'on ne s'en sert pas : - le desctructeur, - le constructeur par copie, - l'opérateur d'assignation ?
Les implémenter non, mais les expliciter souvent.
En cas d'héritage, public, et autres entités je pars par défaut sur : - destructeur virtuel public, - opérateur d'affectation désactivé - constructeur de copie désactivé -- ou alors protégé et accompagné d'une fonction virtuelle de clonage pour les rares cas où j'ai besoin de duplication sur des objets polymorphes
En cas d'objet valeur, soit je les définis en fonction de la présence de ressource brute dans la classe. Soit je mets un commentaire comme quoi les attributs de la classe me permettent de ne pas les définir.
Je suis peut-être distrait, mais cette alternative me semble antinomique avec l'idée de valeur.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Luc Hermitte <luc.hermitte@gmail.com> writes:
On 30 juil, 16:17, Beware <mathieu.hed...@gmail.com> wrote:
Faut il implementer dans chacune des classes que l'on code et ce
évidement si l'on ne s'en sert pas :
- le desctructeur,
- le constructeur par copie,
- l'opérateur d'assignation ?
Les implémenter non, mais les expliciter souvent.
En cas d'héritage, public, et autres entités je pars par défaut sur :
- destructeur virtuel public,
- opérateur d'affectation désactivé
- constructeur de copie désactivé -- ou alors protégé et accompagné
d'une fonction virtuelle de clonage pour les rares cas où j'ai besoin
de duplication sur des objets polymorphes
En cas d'objet valeur, soit je les définis en fonction de la présence
de ressource brute dans la classe. Soit je mets un commentaire comme
quoi les attributs de la classe me permettent de ne pas les définir.
Je suis peut-être distrait, mais cette alternative me semble antinomique
avec l'idée de valeur.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Faut il implementer dans chacune des classes que l'on code et ce évidement si l'on ne s'en sert pas : - le desctructeur, - le constructeur par copie, - l'opérateur d'assignation ?
Les implémenter non, mais les expliciter souvent.
En cas d'héritage, public, et autres entités je pars par défaut sur : - destructeur virtuel public, - opérateur d'affectation désactivé - constructeur de copie désactivé -- ou alors protégé et accompagné d'une fonction virtuelle de clonage pour les rares cas où j'ai besoin de duplication sur des objets polymorphes
En cas d'objet valeur, soit je les définis en fonction de la présence de ressource brute dans la classe. Soit je mets un commentaire comme quoi les attributs de la classe me permettent de ne pas les définir.
Je suis peut-être distrait, mais cette alternative me semble antinomique avec l'idée de valeur.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
James Kanze
On Jul 30, 7:21 pm, Jean-Marc Bourguet wrote:
Luc Hermitte writes: > On 30 juil, 16:17, Beware wrote: >> Faut il implementer dans chacune des classes que l'on code et ce >> évidement si l'on ne s'en sert pas : >> - le desctructeur, >> - le constructeur par copie, >> - l'opérateur d'assignation ?
> Les implémenter non, mais les expliciter souvent.
> En cas d'héritage, public, et autres entités je pars par > défaut sur : > - destructeur virtuel public, > - opérateur d'affectation désactivé > - constructeur de copie désactivé -- ou alors protégé et > accompagné d'une fonction virtuelle de clonage pour les > rares cas où j'ai besoin de duplication sur des objets > polymorphes
> En cas d'objet valeur, soit je les définis en fonction de la > présence de ressource brute dans la classe. Soit je mets un > commentaire comme quoi les attributs de la classe me > permettent de ne pas les définir.
Je suis peut-être distrait, mais cette alternative me semble antinomique avec l'idée de valeur.
Dans quel sens ? Ou est-ce que tu as simplement mal lu la dernière phrase ? (J'ai dû le relire plusiers fois moi-même avant de l'avoir compris. En gros, ce qu'il dit, c'est qu'il met un commentaire, à la place de la fonction en question, si la version générée automatiquement par le compilateur fait l'affaire.)
-- James Kanze (GABI Software) email: 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 Jul 30, 7:21 pm, Jean-Marc Bourguet <j...@bourguet.org> wrote:
Luc Hermitte <luc.hermi...@gmail.com> writes:
> On 30 juil, 16:17, Beware <mathieu.hed...@gmail.com> wrote:
>> Faut il implementer dans chacune des classes que l'on code et ce
>> évidement si l'on ne s'en sert pas :
>> - le desctructeur,
>> - le constructeur par copie,
>> - l'opérateur d'assignation ?
> Les implémenter non, mais les expliciter souvent.
> En cas d'héritage, public, et autres entités je pars par
> défaut sur :
> - destructeur virtuel public,
> - opérateur d'affectation désactivé
> - constructeur de copie désactivé -- ou alors protégé et
> accompagné d'une fonction virtuelle de clonage pour les
> rares cas où j'ai besoin de duplication sur des objets
> polymorphes
> En cas d'objet valeur, soit je les définis en fonction de la
> présence de ressource brute dans la classe. Soit je mets un
> commentaire comme quoi les attributs de la classe me
> permettent de ne pas les définir.
Je suis peut-être distrait, mais cette alternative me semble
antinomique avec l'idée de valeur.
Dans quel sens ? Ou est-ce que tu as simplement mal lu la
dernière phrase ? (J'ai dû le relire plusiers fois moi-même
avant de l'avoir compris. En gros, ce qu'il dit, c'est qu'il
met un commentaire, à la place de la fonction en question, si la
version générée automatiquement par le compilateur fait
l'affaire.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
Luc Hermitte writes: > On 30 juil, 16:17, Beware wrote: >> Faut il implementer dans chacune des classes que l'on code et ce >> évidement si l'on ne s'en sert pas : >> - le desctructeur, >> - le constructeur par copie, >> - l'opérateur d'assignation ?
> Les implémenter non, mais les expliciter souvent.
> En cas d'héritage, public, et autres entités je pars par > défaut sur : > - destructeur virtuel public, > - opérateur d'affectation désactivé > - constructeur de copie désactivé -- ou alors protégé et > accompagné d'une fonction virtuelle de clonage pour les > rares cas où j'ai besoin de duplication sur des objets > polymorphes
> En cas d'objet valeur, soit je les définis en fonction de la > présence de ressource brute dans la classe. Soit je mets un > commentaire comme quoi les attributs de la classe me > permettent de ne pas les définir.
Je suis peut-être distrait, mais cette alternative me semble antinomique avec l'idée de valeur.
Dans quel sens ? Ou est-ce que tu as simplement mal lu la dernière phrase ? (J'ai dû le relire plusiers fois moi-même avant de l'avoir compris. En gros, ce qu'il dit, c'est qu'il met un commentaire, à la place de la fonction en question, si la version générée automatiquement par le compilateur fait l'affaire.)
-- James Kanze (GABI Software) email: 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
Jean-Marc Bourguet
James Kanze writes:
On Jul 30, 7:21 pm, Jean-Marc Bourguet wrote:
Luc Hermitte writes: > On 30 juil, 16:17, Beware wrote: >> Faut il implementer dans chacune des classes que l'on code et ce >> évidement si l'on ne s'en sert pas : >> - le desctructeur, >> - le constructeur par copie, >> - l'opérateur d'assignation ?
> Les implémenter non, mais les expliciter souvent.
> En cas d'héritage, public, et autres entités je pars par > défaut sur : > - destructeur virtuel public, > - opérateur d'affectation désactivé > - constructeur de copie désactivé -- ou alors protégé et > accompagné d'une fonction virtuelle de clonage pour les > rares cas où j'ai besoin de duplication sur des objets > polymorphes
> En cas d'objet valeur, soit je les définis en fonction de la > présence de ressource brute dans la classe. Soit je mets un > commentaire comme quoi les attributs de la classe me > permettent de ne pas les définir.
Je suis peut-être distrait, mais cette alternative me semble antinomique avec l'idée de valeur.
Dans quel sens ? Ou est-ce que tu as simplement mal lu la dernière phrase ?
Exact.
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
James Kanze <james.kanze@gmail.com> writes:
On Jul 30, 7:21 pm, Jean-Marc Bourguet <j...@bourguet.org> wrote:
Luc Hermitte <luc.hermi...@gmail.com> writes:
> On 30 juil, 16:17, Beware <mathieu.hed...@gmail.com> wrote:
>> Faut il implementer dans chacune des classes que l'on code et ce
>> évidement si l'on ne s'en sert pas :
>> - le desctructeur,
>> - le constructeur par copie,
>> - l'opérateur d'assignation ?
> Les implémenter non, mais les expliciter souvent.
> En cas d'héritage, public, et autres entités je pars par
> défaut sur :
> - destructeur virtuel public,
> - opérateur d'affectation désactivé
> - constructeur de copie désactivé -- ou alors protégé et
> accompagné d'une fonction virtuelle de clonage pour les
> rares cas où j'ai besoin de duplication sur des objets
> polymorphes
> En cas d'objet valeur, soit je les définis en fonction de la
> présence de ressource brute dans la classe. Soit je mets un
> commentaire comme quoi les attributs de la classe me
> permettent de ne pas les définir.
Je suis peut-être distrait, mais cette alternative me semble
antinomique avec l'idée de valeur.
Dans quel sens ? Ou est-ce que tu as simplement mal lu la
dernière phrase ?
Exact.
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Luc Hermitte writes: > On 30 juil, 16:17, Beware wrote: >> Faut il implementer dans chacune des classes que l'on code et ce >> évidement si l'on ne s'en sert pas : >> - le desctructeur, >> - le constructeur par copie, >> - l'opérateur d'assignation ?
> Les implémenter non, mais les expliciter souvent.
> En cas d'héritage, public, et autres entités je pars par > défaut sur : > - destructeur virtuel public, > - opérateur d'affectation désactivé > - constructeur de copie désactivé -- ou alors protégé et > accompagné d'une fonction virtuelle de clonage pour les > rares cas où j'ai besoin de duplication sur des objets > polymorphes
> En cas d'objet valeur, soit je les définis en fonction de la > présence de ressource brute dans la classe. Soit je mets un > commentaire comme quoi les attributs de la classe me > permettent de ne pas les définir.
Je suis peut-être distrait, mais cette alternative me semble antinomique avec l'idée de valeur.
Dans quel sens ? Ou est-ce que tu as simplement mal lu la dernière phrase ?
Exact.
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Luc Hermitte
On 30 juil, 21:56, James Kanze wrote:
On Jul 30, 7:21 pm, Jean-Marc Bourguet wrote: [...] > > En cas d'objet valeur, soit je les définis en fonction de la > > présence de ressource brute dans la classe. Soit je mets un > > commentaire comme quoi les attributs de la classe me > > permettent de ne pas les définir. > Je suis peut-être distrait, mais cette alternative me semble > antinomique avec l'idée de valeur.
Dans quel sens ? Ou est-ce que tu as simplement mal lu la dernière phrase ? (J'ai dû le relire plusieurs fois moi-même avant de l'avoir comprise. En gros, ce qu'il dit, c'est qu'il met un commentaire, à la place de la fonction en question, si la version générée automatiquement par le compilateur fait l'affaire.)
Oui c'est ça. Désolé pour la tournure alambiquée de ma phrase ^^'.
-- Luc Hermitte
On 30 juil, 21:56, James Kanze <james.ka...@gmail.com> wrote:
On Jul 30, 7:21 pm, Jean-Marc Bourguet <j...@bourguet.org> wrote:
[...]
> > En cas d'objet valeur, soit je les définis en fonction de la
> > présence de ressource brute dans la classe. Soit je mets un
> > commentaire comme quoi les attributs de la classe me
> > permettent de ne pas les définir.
> Je suis peut-être distrait, mais cette alternative me semble
> antinomique avec l'idée de valeur.
Dans quel sens ? Ou est-ce que tu as simplement mal lu la
dernière phrase ? (J'ai dû le relire plusieurs fois moi-même
avant de l'avoir comprise. En gros, ce qu'il dit, c'est qu'il
met un commentaire, à la place de la fonction en question, si la
version générée automatiquement par le compilateur fait
l'affaire.)
Oui c'est ça.
Désolé pour la tournure alambiquée de ma phrase ^^'.
On Jul 30, 7:21 pm, Jean-Marc Bourguet wrote: [...] > > En cas d'objet valeur, soit je les définis en fonction de la > > présence de ressource brute dans la classe. Soit je mets un > > commentaire comme quoi les attributs de la classe me > > permettent de ne pas les définir. > Je suis peut-être distrait, mais cette alternative me semble > antinomique avec l'idée de valeur.
Dans quel sens ? Ou est-ce que tu as simplement mal lu la dernière phrase ? (J'ai dû le relire plusieurs fois moi-même avant de l'avoir comprise. En gros, ce qu'il dit, c'est qu'il met un commentaire, à la place de la fonction en question, si la version générée automatiquement par le compilateur fait l'affaire.)
Oui c'est ça. Désolé pour la tournure alambiquée de ma phrase ^^'.
-- Luc Hermitte
jerome
"Luc Hermitte" a écrit dans le message de news:
On 28 juil, 20:17, Antoine wrote:
Hum ... cela doit faire un moment que tu n'y as plus mis les pieds. Mais un sacré moment alors.
Je viens d'y faire un tour : c'est pire que ça : on se croirait à la maternelle et c'est effectivement d'une nullité technique....
"Luc Hermitte" <luc.hermitte@gmail.com> a écrit dans le message de news:
a26ce2a0-566b-4a01-abc8-0a81a401e38f@j32g2000yqh.googlegroups.com...
On 28 juil, 20:17, Antoine <to...@gmail.com> wrote:
Hum ... cela doit faire un moment que tu n'y as plus mis les pieds.
Mais un sacré moment alors.
Je viens d'y faire un tour : c'est pire que ça : on se croirait à la
maternelle et c'est effectivement d'une nullité technique....
"Gabriel Dos Reis" a écrit dans le message de news:
OK. À l'évidence, j'ai peu d'expérience des sites ados :-)
Lu aujourd'hui sur un de ces sites : " attention ! une application cliente ne DOIT PAS se connecter à une base de données sur un serveur distant... "
Les bras m'en tombent...
Au moins, si personne ne le faisait, ça éviterait certains cas de piratage de données ;-)
pjb
"jerome" writes:
"Gabriel Dos Reis" a écrit dans le message de news:
OK. À l'évidence, j'ai peu d'expérience des sites ados :-)
Lu aujourd'hui sur un de ces sites : " attention ! une application cliente ne DOIT PAS se connecter à une base de données sur un serveur distant... "
Les bras m'en tombent...
Non non, serrieusement, c'est aussi conseillé par Greenspun (qui a quand même réussi à faire fortune en programmant des sites web).
La raison est la suivante: les serveurs RDBMS ont un degré zéro de sécurité, ils sont restés (en tout cas en 1998 quand Greenspun a écrit son livre http://www.amazon.com/Philip-Alexs-Guide-Web-Publishing/dp/1558605347 ) sur un mode intranet, et pas Internet. En gros, ils permettent l'accès à n'importe quel ordinateur du moment qu'il a un nom de compte et un mot de passe, et comme il y a des couples (nom de compte, mot de passe) bien connus configurés par défaut, et qu'il passent en clair dans les protocoles client/serveur de ces base de données, et que sinon, de toutes façons ils se retrouvent en clair dans les applications clients, il vaut mieux laisser le RDBMS derrière le firewall, et donc interndir aux applications clientes de se connecter à une base de données sur un serveur distant (sur Internet).
En plus, la gestion des droits d'accès à l'intérieur des RDBMS est trop grossière: elle se fait verticalement, au niveau des tables, alors qu'on ne voudrait permettre à un utilisateur que l'accès en écriture à ses propres données, c'est à dire aux rangées qui le concerne. Ceci les RDBMS ne le gèrent pas eux mêmes.
C'est donc aux applications de le gérer, et pour ces questions de sécurité, ces applications ne peuvent pas être distribuées sur Internet, elles doivent fonctionner près du RDBMS (eg. dans le serveur web, derrière le firewall).
-- __Pascal Bourguignon__
"jerome" <jer@st.com> writes:
"Gabriel Dos Reis" <gdr@cs.tamu.edu> a écrit dans le message de news:
87k51shbww.fsf@gauss.cs.tamu.edu...
OK. À l'évidence, j'ai peu d'expérience des sites ados :-)
Lu aujourd'hui sur un de ces sites :
" attention ! une application cliente ne DOIT PAS se connecter à une base de
données sur un serveur distant... "
Les bras m'en tombent...
Non non, serrieusement, c'est aussi conseillé par Greenspun (qui a
quand même réussi à faire fortune en programmant des sites web).
La raison est la suivante: les serveurs RDBMS ont un degré zéro de
sécurité, ils sont restés (en tout cas en 1998 quand Greenspun a écrit
son livre
http://www.amazon.com/Philip-Alexs-Guide-Web-Publishing/dp/1558605347
) sur un mode intranet, et pas Internet. En gros, ils permettent
l'accès à n'importe quel ordinateur du moment qu'il a un nom de compte
et un mot de passe, et comme il y a des couples (nom de compte, mot de
passe) bien connus configurés par défaut, et qu'il passent en clair
dans les protocoles client/serveur de ces base de données, et que
sinon, de toutes façons ils se retrouvent en clair dans les
applications clients, il vaut mieux laisser le RDBMS derrière le
firewall, et donc interndir aux applications clientes de se connecter
à une base de données sur un serveur distant (sur Internet).
En plus, la gestion des droits d'accès à l'intérieur des RDBMS est
trop grossière: elle se fait verticalement, au niveau des tables,
alors qu'on ne voudrait permettre à un utilisateur que l'accès en
écriture à ses propres données, c'est à dire aux rangées qui le
concerne. Ceci les RDBMS ne le gèrent pas eux mêmes.
C'est donc aux applications de le gérer, et pour ces questions de
sécurité, ces applications ne peuvent pas être distribuées sur
Internet, elles doivent fonctionner près du RDBMS (eg. dans le serveur
web, derrière le firewall).
"Gabriel Dos Reis" a écrit dans le message de news:
OK. À l'évidence, j'ai peu d'expérience des sites ados :-)
Lu aujourd'hui sur un de ces sites : " attention ! une application cliente ne DOIT PAS se connecter à une base de données sur un serveur distant... "
Les bras m'en tombent...
Non non, serrieusement, c'est aussi conseillé par Greenspun (qui a quand même réussi à faire fortune en programmant des sites web).
La raison est la suivante: les serveurs RDBMS ont un degré zéro de sécurité, ils sont restés (en tout cas en 1998 quand Greenspun a écrit son livre http://www.amazon.com/Philip-Alexs-Guide-Web-Publishing/dp/1558605347 ) sur un mode intranet, et pas Internet. En gros, ils permettent l'accès à n'importe quel ordinateur du moment qu'il a un nom de compte et un mot de passe, et comme il y a des couples (nom de compte, mot de passe) bien connus configurés par défaut, et qu'il passent en clair dans les protocoles client/serveur de ces base de données, et que sinon, de toutes façons ils se retrouvent en clair dans les applications clients, il vaut mieux laisser le RDBMS derrière le firewall, et donc interndir aux applications clientes de se connecter à une base de données sur un serveur distant (sur Internet).
En plus, la gestion des droits d'accès à l'intérieur des RDBMS est trop grossière: elle se fait verticalement, au niveau des tables, alors qu'on ne voudrait permettre à un utilisateur que l'accès en écriture à ses propres données, c'est à dire aux rangées qui le concerne. Ceci les RDBMS ne le gèrent pas eux mêmes.
C'est donc aux applications de le gérer, et pour ces questions de sécurité, ces applications ne peuvent pas être distribuées sur Internet, elles doivent fonctionner près du RDBMS (eg. dans le serveur web, derrière le firewall).
