Je viens de tomber sur un message de Michel, d'il y a un mois, dont
voici un extrait :
> From: "Michel Michaud" <mm@gdzid.com>
> Subject: Re: buffer et std::vector<char> passage de l'un a l'autre
> Message-ID: <pQnHa.816$5d.225371@news20.bellglobal.com>
> Date: Mon, 16 Jun 2003 14:16:52 -0400
> Avec
> vector<char> v(taille);
> &v[0] est un char* qui peut être passé aux fonctions attendant un
> char[]/char*. La norme ne dit pas explicitement que les char sont
> contigus, mais c'est un fait et il y a une correction à la norme qui
> l'indique aussi.
J'avais toujours entendu dire que la contigüités des éléments d'un
vecteur était garantie. Apparemment non. Pour ce qui est de la
correction à la norme, je suppose que tu parlais d'un DR. En as-tu la
référence, stp ?
| "Gabriel Dos Reis" a écrit dans le message | news: | | > "Alain Naigeon" writes: | > | > | Maintenant, dis-moi : cette impossibilité est-elle une intuition | > | de ta part, ou bien une induction basée sur un grand nombre | > | de tentatives (!), ou bien encore un théorème ? | > | > Sur une constatation très simple : la sémantique, c'est la partie qui | > s'occupe de donner un sens aux mots, i.e à la syntaxe. | > Chaque fois que j'ai une notation, il faut que je lui donne un sens. | > | > | Et dans ce | > | dernier cas, dans quel cadre conceptuel, mathématique | > | ou autre, ses hypothèses et sa démonstration peuvent-elles | > | être exprimées rigoureusement ? | > | > Ben j'avoue que je ne comprends pas très bien où tu veux en venir. | | Bon, je suppose que je n'utilise pas les mots corrects. | De l'exemple de l'intervalle [1...8] du Pascal, remplacé | en C++ par ta réponse avec template<typename T, int m, int M> | je tire l'impression que ce qui est "cablé" dans un langage, et | ce qui doit être écrit soi-même, est une limite qui peut bouger, | selon le langage considéré.
Effectivement.
Pour C++,la règle générale a toujours été : pas de machins particuliers, mais des mécanismes généraux réutilisables. Et on met un accent sur la bibliothèque. L'un des points est que si on veut câbler des constructions particulières dans le langage, on se retrouvera vite avec un vaisseau surchargé, ingérable et pourtant ne fournit pas assez de primitives.
| Ce qui est câblé, je l'appelais "syntaxe", à tort je pense, ce doit | être là mon erreur... | Il n'empêche, je suis frappé que la déclaration d'un sous-type | d'entier puisse être exprimée à l'aide d'une simple déclaration | en Pascal, alors même qu'elle contient un peu de sémantique | (restriction entre deux bornes).
C'est que Pascal associe à cette syntaxe, une sémantique qu'on ne pourrait exprimer autrement. J'appelerais cela de la magie.
| En regard de cela, je constatais que la contiguïté, elle, semble | plus résistante à une expression aussi immédiate.
Mais le C ou C++ ont fait la même chose, pour une syntaxe particulière : T[N]. Mais la magie ne plait pas à tout le monde. std::vector<> est quelque chose exprimable avec le reste du langage. On souhaite simplement qu'elle garantisse une certaine propriété, sans avoir à faire encore de la magie. En fait, moins il y a de la magie, mieux c'est. C'est une opinion.
| Ma question était donc : y aurait-il des propriétés dont on pourrait | démontrer qu'elles ne sont "câblables" dans aucun langage,
Il suffit de prendre n'importe quelle propriété connue et d'asserner sa négation ;-)
| et la contiguïté serait-elle l'une d'entre elles ?
non, on peut faire de la magie pour la contiguité dans un langage de son crû si on le veut. Le C et C++ l'ont fait pour T[N] et malloc().
| Mais si tout cela est trop confus pour un autre cerveau que le | mien, laissons tomber ;-)
OK.
-- Gaby
"Alain Naigeon" <anaigeon@free.fr> writes:
| "Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message
| news: m3znjcswq7.fsf@uniton.integrable-solutions.net...
|
| > "Alain Naigeon" <anaigeon@free.fr> writes:
| >
| > | Maintenant, dis-moi : cette impossibilité est-elle une intuition
| > | de ta part, ou bien une induction basée sur un grand nombre
| > | de tentatives (!), ou bien encore un théorème ?
| >
| > Sur une constatation très simple : la sémantique, c'est la partie qui
| > s'occupe de donner un sens aux mots, i.e à la syntaxe.
| > Chaque fois que j'ai une notation, il faut que je lui donne un sens.
| >
| > | Et dans ce
| > | dernier cas, dans quel cadre conceptuel, mathématique
| > | ou autre, ses hypothèses et sa démonstration peuvent-elles
| > | être exprimées rigoureusement ?
| >
| > Ben j'avoue que je ne comprends pas très bien où tu veux en venir.
|
| Bon, je suppose que je n'utilise pas les mots corrects.
| De l'exemple de l'intervalle [1...8] du Pascal, remplacé
| en C++ par ta réponse avec template<typename T, int m, int M>
| je tire l'impression que ce qui est "cablé" dans un langage, et
| ce qui doit être écrit soi-même, est une limite qui peut bouger,
| selon le langage considéré.
Effectivement.
Pour C++,la règle générale a toujours été : pas de machins
particuliers, mais des mécanismes généraux réutilisables. Et on met un
accent sur la bibliothèque.
L'un des points est que si on veut câbler des constructions
particulières dans le langage, on se retrouvera vite avec un vaisseau
surchargé, ingérable et pourtant ne fournit pas assez de primitives.
| Ce qui est câblé, je l'appelais "syntaxe", à tort je pense, ce doit
| être là mon erreur...
| Il n'empêche, je suis frappé que la déclaration d'un sous-type
| d'entier puisse être exprimée à l'aide d'une simple déclaration
| en Pascal, alors même qu'elle contient un peu de sémantique
| (restriction entre deux bornes).
C'est que Pascal associe à cette syntaxe, une sémantique qu'on ne
pourrait exprimer autrement. J'appelerais cela de la magie.
| En regard de cela, je constatais que la contiguïté, elle, semble
| plus résistante à une expression aussi immédiate.
Mais le C ou C++ ont fait la même chose, pour une syntaxe
particulière : T[N]. Mais la magie ne plait pas à tout le monde.
std::vector<> est quelque chose exprimable avec le reste du langage.
On souhaite simplement qu'elle garantisse une certaine propriété, sans
avoir à faire encore de la magie.
En fait, moins il y a de la magie, mieux c'est. C'est une opinion.
| Ma question était donc : y aurait-il des propriétés dont on pourrait
| démontrer qu'elles ne sont "câblables" dans aucun langage,
Il suffit de prendre n'importe quelle propriété connue et d'asserner
sa négation ;-)
| et la contiguïté serait-elle l'une d'entre elles ?
non, on peut faire de la magie pour la contiguité dans un langage de
son crû si on le veut. Le C et C++ l'ont fait pour T[N] et malloc().
| Mais si tout cela est trop confus pour un autre cerveau que le
| mien, laissons tomber ;-)
| "Gabriel Dos Reis" a écrit dans le message | news: | | > "Alain Naigeon" writes: | > | > | Maintenant, dis-moi : cette impossibilité est-elle une intuition | > | de ta part, ou bien une induction basée sur un grand nombre | > | de tentatives (!), ou bien encore un théorème ? | > | > Sur une constatation très simple : la sémantique, c'est la partie qui | > s'occupe de donner un sens aux mots, i.e à la syntaxe. | > Chaque fois que j'ai une notation, il faut que je lui donne un sens. | > | > | Et dans ce | > | dernier cas, dans quel cadre conceptuel, mathématique | > | ou autre, ses hypothèses et sa démonstration peuvent-elles | > | être exprimées rigoureusement ? | > | > Ben j'avoue que je ne comprends pas très bien où tu veux en venir. | | Bon, je suppose que je n'utilise pas les mots corrects. | De l'exemple de l'intervalle [1...8] du Pascal, remplacé | en C++ par ta réponse avec template<typename T, int m, int M> | je tire l'impression que ce qui est "cablé" dans un langage, et | ce qui doit être écrit soi-même, est une limite qui peut bouger, | selon le langage considéré.
Effectivement.
Pour C++,la règle générale a toujours été : pas de machins particuliers, mais des mécanismes généraux réutilisables. Et on met un accent sur la bibliothèque. L'un des points est que si on veut câbler des constructions particulières dans le langage, on se retrouvera vite avec un vaisseau surchargé, ingérable et pourtant ne fournit pas assez de primitives.
| Ce qui est câblé, je l'appelais "syntaxe", à tort je pense, ce doit | être là mon erreur... | Il n'empêche, je suis frappé que la déclaration d'un sous-type | d'entier puisse être exprimée à l'aide d'une simple déclaration | en Pascal, alors même qu'elle contient un peu de sémantique | (restriction entre deux bornes).
C'est que Pascal associe à cette syntaxe, une sémantique qu'on ne pourrait exprimer autrement. J'appelerais cela de la magie.
| En regard de cela, je constatais que la contiguïté, elle, semble | plus résistante à une expression aussi immédiate.
Mais le C ou C++ ont fait la même chose, pour une syntaxe particulière : T[N]. Mais la magie ne plait pas à tout le monde. std::vector<> est quelque chose exprimable avec le reste du langage. On souhaite simplement qu'elle garantisse une certaine propriété, sans avoir à faire encore de la magie. En fait, moins il y a de la magie, mieux c'est. C'est une opinion.
| Ma question était donc : y aurait-il des propriétés dont on pourrait | démontrer qu'elles ne sont "câblables" dans aucun langage,
Il suffit de prendre n'importe quelle propriété connue et d'asserner sa négation ;-)
| et la contiguïté serait-elle l'une d'entre elles ?
non, on peut faire de la magie pour la contiguité dans un langage de son crû si on le veut. Le C et C++ l'ont fait pour T[N] et malloc().
| Mais si tout cela est trop confus pour un autre cerveau que le | mien, laissons tomber ;-)
OK.
-- Gaby
Gabriel Dos Reis
"Michel Michaud" writes:
| Dans news:, Gabriel Dos | > "Alain Naigeon" writes: | >> Je lis dans Stroustrup, 2ème édition française, page 10, une mise | >> en garde contre les données membres publiques (mais dans certaines | >> circonstances, j'ajoute, pour être honnête). | > | > ce qui est important, c'est « dans certaines conditions ». | > Je mentionne encore l'exemple de std::pair<>. | | Mais là, il faut avouer que certaines personnes disent justement que | c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas | que les données publiques soient toujours des erreurs)
Pourquoi est-ce une erreur ? Qu'est-ce qu'on veut abstraire avec std::pair ? Qu'est-ce qu'on veut protéger ?
-- Gaby
"Michel Michaud" <mm@gdzid.com> writes:
| Dans news:m3n0fchm9m.fsf@uniton.integrable-solutions.net, Gabriel Dos
| > "Alain Naigeon" <anaigeon@free.fr> writes:
| >> Je lis dans Stroustrup, 2ème édition française, page 10, une mise
| >> en garde contre les données membres publiques (mais dans certaines
| >> circonstances, j'ajoute, pour être honnête).
| >
| > ce qui est important, c'est « dans certaines conditions ».
| > Je mentionne encore l'exemple de std::pair<>.
|
| Mais là, il faut avouer que certaines personnes disent justement que
| c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas
| que les données publiques soient toujours des erreurs)
Pourquoi est-ce une erreur ? Qu'est-ce qu'on veut abstraire avec
std::pair ? Qu'est-ce qu'on veut protéger ?
| Dans news:, Gabriel Dos | > "Alain Naigeon" writes: | >> Je lis dans Stroustrup, 2ème édition française, page 10, une mise | >> en garde contre les données membres publiques (mais dans certaines | >> circonstances, j'ajoute, pour être honnête). | > | > ce qui est important, c'est « dans certaines conditions ». | > Je mentionne encore l'exemple de std::pair<>. | | Mais là, il faut avouer que certaines personnes disent justement que | c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas | que les données publiques soient toujours des erreurs)
Pourquoi est-ce une erreur ? Qu'est-ce qu'on veut abstraire avec std::pair ? Qu'est-ce qu'on veut protéger ?
-- Gaby
Gabriel Dos Reis
"Michel Michaud" writes:
| Dans news:bf7gr1$58a$, Christophe | > "Michel Michaud" a écrit dans le message de | > news:1jHRa.7783$ | >> Dans news:, Gabriel | >>> "Alain Naigeon" writes: | >>>> Je lis dans Stroustrup, 2ème édition française, page 10, une mise | >>>> en garde contre les données membres publiques (mais dans | >>>> certaines circonstances, j'ajoute, pour être honnête). | >>> | >>> ce qui est important, c'est « dans certaines conditions ». | >>> Je mentionne encore l'exemple de std::pair<>. | >> | >> Mais là, il faut avouer que certaines personnes disent justement | >> que c'est une erreur d'avoir les données publiques. (ce qui ne | >> prouve pas que les données publiques soient toujours des erreurs) | > | > C'est vrai que ce serait bien plus robuste si on avait des | > fonctions membres du style get_the_first(), get_the_second(), | > set_the_first() et set_the_second() ;) | | Non, mais x.first() vs x.first ? x.first(v) vs x.first=v;
Qu'est-ce qu'on gagne en échange de la lourdeur de la syntaxe ?
| > Plus sérieusement, quel argument as-tu(*) contre le fait que les | > données de pair soient publiques ? | > | > Chris | > | > (*) je dis "as-tu", mais c'est une figure de style En toute rigueur | > ce devrait être "ont-ils"... | | Je ne me rappelle plus exactement. Je n'ai pas d'opinion ferme | là-dessus, alors je n'ai pas tellement le goût de chercher plus | loin que « pair private » dans Google pour clc++m. J'ai trouvé ces | deux bases si tu veux lire plus. | | http://minilien.com/?NTwSo50hFJ | | http://minilien.com/?flj2Rwz4iN
Je crois que le deuxième lien pondère ce qu'on peut trouver dans le premier. Ma question est tout simplement : qu'est-ce qu'on veut protéger ? Qu'est-ce qu'on veut abstraire ?
| Je ne suis même pas certain que c'est à quoi je pensais... | | Peut-être que Gabriel ou James se rappelle plus que moi s'il y a | eu une discussion plus exacte sur des problèmes dûs à l'interface | trop publique de std::pair... | | (Personnellement je n'ai pas de problème avec le std::pair actuel, | mon message tenait seulement à dire qu'il ne faut pas toujours se | fier sur la bibliothèque pour des exemples de design qui semblent | bons à tous. Si pair n'est pas un bon exemple de ça, il n'y a qu'à | voir les critiques de James pour en trouver d'autres :-)
Je ne disais pas que la bibliothèque était un exemple absolu à suivre. Pour nourrir la discussion avec des exemples concrets, j'indiquais un exemple spécifique. Si c'est std:: qui te distrait, fais comme s'il n'était pas là.
-- Gaby
"Michel Michaud" <mm@gdzid.com> writes:
| Dans news:bf7gr1$58a$1@news-reader3.wanadoo.fr, Christophe
| > "Michel Michaud" <mm@gdzid.com> a écrit dans le message de
| > news:1jHRa.7783$104.767215@news20.bellglobal.com...
| >> Dans news:m3n0fchm9m.fsf@uniton.integrable-solutions.net, Gabriel
| >>> "Alain Naigeon" <anaigeon@free.fr> writes:
| >>>> Je lis dans Stroustrup, 2ème édition française, page 10, une mise
| >>>> en garde contre les données membres publiques (mais dans
| >>>> certaines circonstances, j'ajoute, pour être honnête).
| >>>
| >>> ce qui est important, c'est « dans certaines conditions ».
| >>> Je mentionne encore l'exemple de std::pair<>.
| >>
| >> Mais là, il faut avouer que certaines personnes disent justement
| >> que c'est une erreur d'avoir les données publiques. (ce qui ne
| >> prouve pas que les données publiques soient toujours des erreurs)
| >
| > C'est vrai que ce serait bien plus robuste si on avait des
| > fonctions membres du style get_the_first(), get_the_second(),
| > set_the_first() et set_the_second() ;)
|
| Non, mais x.first() vs x.first ? x.first(v) vs x.first=v;
Qu'est-ce qu'on gagne en échange de la lourdeur de la syntaxe ?
| > Plus sérieusement, quel argument as-tu(*) contre le fait que les
| > données de pair soient publiques ?
| >
| > Chris
| >
| > (*) je dis "as-tu", mais c'est une figure de style En toute rigueur
| > ce devrait être "ont-ils"...
|
| Je ne me rappelle plus exactement. Je n'ai pas d'opinion ferme
| là-dessus, alors je n'ai pas tellement le goût de chercher plus
| loin que « pair private » dans Google pour clc++m. J'ai trouvé ces
| deux bases si tu veux lire plus.
|
| http://minilien.com/?NTwSo50hFJ
|
| http://minilien.com/?flj2Rwz4iN
Je crois que le deuxième lien pondère ce qu'on peut trouver dans le
premier. Ma question est tout simplement : qu'est-ce qu'on veut
protéger ? Qu'est-ce qu'on veut abstraire ?
| Je ne suis même pas certain que c'est à quoi je pensais...
|
| Peut-être que Gabriel ou James se rappelle plus que moi s'il y a
| eu une discussion plus exacte sur des problèmes dûs à l'interface
| trop publique de std::pair...
|
| (Personnellement je n'ai pas de problème avec le std::pair actuel,
| mon message tenait seulement à dire qu'il ne faut pas toujours se
| fier sur la bibliothèque pour des exemples de design qui semblent
| bons à tous. Si pair n'est pas un bon exemple de ça, il n'y a qu'à
| voir les critiques de James pour en trouver d'autres :-)
Je ne disais pas que la bibliothèque était un exemple absolu à suivre.
Pour nourrir la discussion avec des exemples concrets, j'indiquais un
exemple spécifique. Si c'est std:: qui te distrait, fais comme s'il
n'était pas là.
| Dans news:bf7gr1$58a$, Christophe | > "Michel Michaud" a écrit dans le message de | > news:1jHRa.7783$ | >> Dans news:, Gabriel | >>> "Alain Naigeon" writes: | >>>> Je lis dans Stroustrup, 2ème édition française, page 10, une mise | >>>> en garde contre les données membres publiques (mais dans | >>>> certaines circonstances, j'ajoute, pour être honnête). | >>> | >>> ce qui est important, c'est « dans certaines conditions ». | >>> Je mentionne encore l'exemple de std::pair<>. | >> | >> Mais là, il faut avouer que certaines personnes disent justement | >> que c'est une erreur d'avoir les données publiques. (ce qui ne | >> prouve pas que les données publiques soient toujours des erreurs) | > | > C'est vrai que ce serait bien plus robuste si on avait des | > fonctions membres du style get_the_first(), get_the_second(), | > set_the_first() et set_the_second() ;) | | Non, mais x.first() vs x.first ? x.first(v) vs x.first=v;
Qu'est-ce qu'on gagne en échange de la lourdeur de la syntaxe ?
| > Plus sérieusement, quel argument as-tu(*) contre le fait que les | > données de pair soient publiques ? | > | > Chris | > | > (*) je dis "as-tu", mais c'est une figure de style En toute rigueur | > ce devrait être "ont-ils"... | | Je ne me rappelle plus exactement. Je n'ai pas d'opinion ferme | là-dessus, alors je n'ai pas tellement le goût de chercher plus | loin que « pair private » dans Google pour clc++m. J'ai trouvé ces | deux bases si tu veux lire plus. | | http://minilien.com/?NTwSo50hFJ | | http://minilien.com/?flj2Rwz4iN
Je crois que le deuxième lien pondère ce qu'on peut trouver dans le premier. Ma question est tout simplement : qu'est-ce qu'on veut protéger ? Qu'est-ce qu'on veut abstraire ?
| Je ne suis même pas certain que c'est à quoi je pensais... | | Peut-être que Gabriel ou James se rappelle plus que moi s'il y a | eu une discussion plus exacte sur des problèmes dûs à l'interface | trop publique de std::pair... | | (Personnellement je n'ai pas de problème avec le std::pair actuel, | mon message tenait seulement à dire qu'il ne faut pas toujours se | fier sur la bibliothèque pour des exemples de design qui semblent | bons à tous. Si pair n'est pas un bon exemple de ça, il n'y a qu'à | voir les critiques de James pour en trouver d'autres :-)
Je ne disais pas que la bibliothèque était un exemple absolu à suivre. Pour nourrir la discussion avec des exemples concrets, j'indiquais un exemple spécifique. Si c'est std:: qui te distrait, fais comme s'il n'était pas là.
-- Gaby
kanze
"Michel Michaud" wrote in message news:<1jHRa.7783$...
Dans news:, Gabriel Dos
"Alain Naigeon" writes:
Je lis dans Stroustrup, 2ème édition française, page 10, une mise en garde contre les données membres publiques (mais dans certaines circonstances, j'ajoute, pour être honnête).
ce qui est important, c'est « dans certaines conditions ». Je mentionne encore l'exemple de std::pair<>.
Mais là, il faut avouer que certaines personnes disent justement que c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas que les données publiques soient toujours des erreurs)
Tiens, c'est la première fois que j'entends ça. La régle générale que j'ai toujours entendue, c'est que les données doivent être soit toutes privées (la plupart du temps), soit toutes publiques -- ce n'est pas parce qu'on a des classes que les bonnes vieilles struct sont sans utilité.
Quand on parle de l'enforcement des régles de « bonne » programmation par le compilateur, il ne faut jamais oublié la régle numéro 0 : on peut effreindre à n'importe quelle régle qui suit, à condition de pouvoir en justifier le besoin. Un langage où on ne peut absolument pas effreindre aux régles est un langage quasiment inutilisable. (Ceci dit, j'aime beaucoup la façon que c'est traité en Modula-3. Pour effreindre à une régle, il y a un mot clé « unsafe », qui dit bien ce qu'il dit.)
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<1jHRa.7783$104.767215@news20.bellglobal.com>...
Dans news:m3n0fchm9m.fsf@uniton.integrable-solutions.net, Gabriel Dos
"Alain Naigeon" <anaigeon@free.fr> writes:
Je lis dans Stroustrup, 2ème édition française, page 10, une mise
en garde contre les données membres publiques (mais dans certaines
circonstances, j'ajoute, pour être honnête).
ce qui est important, c'est « dans certaines conditions ». Je
mentionne encore l'exemple de std::pair<>.
Mais là, il faut avouer que certaines personnes disent justement que
c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas
que les données publiques soient toujours des erreurs)
Tiens, c'est la première fois que j'entends ça. La régle générale que
j'ai toujours entendue, c'est que les données doivent être soit toutes
privées (la plupart du temps), soit toutes publiques -- ce n'est pas
parce qu'on a des classes que les bonnes vieilles struct sont sans
utilité.
Quand on parle de l'enforcement des régles de « bonne » programmation
par le compilateur, il ne faut jamais oublié la régle numéro 0 : on peut
effreindre à n'importe quelle régle qui suit, à condition de pouvoir en
justifier le besoin. Un langage où on ne peut absolument pas effreindre
aux régles est un langage quasiment inutilisable. (Ceci dit, j'aime
beaucoup la façon que c'est traité en Modula-3. Pour effreindre à une
régle, il y a un mot clé « unsafe », qui dit bien ce qu'il dit.)
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Michel Michaud" wrote in message news:<1jHRa.7783$...
Dans news:, Gabriel Dos
"Alain Naigeon" writes:
Je lis dans Stroustrup, 2ème édition française, page 10, une mise en garde contre les données membres publiques (mais dans certaines circonstances, j'ajoute, pour être honnête).
ce qui est important, c'est « dans certaines conditions ». Je mentionne encore l'exemple de std::pair<>.
Mais là, il faut avouer que certaines personnes disent justement que c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas que les données publiques soient toujours des erreurs)
Tiens, c'est la première fois que j'entends ça. La régle générale que j'ai toujours entendue, c'est que les données doivent être soit toutes privées (la plupart du temps), soit toutes publiques -- ce n'est pas parce qu'on a des classes que les bonnes vieilles struct sont sans utilité.
Quand on parle de l'enforcement des régles de « bonne » programmation par le compilateur, il ne faut jamais oublié la régle numéro 0 : on peut effreindre à n'importe quelle régle qui suit, à condition de pouvoir en justifier le besoin. Un langage où on ne peut absolument pas effreindre aux régles est un langage quasiment inutilisable. (Ceci dit, j'aime beaucoup la façon que c'est traité en Modula-3. Pour effreindre à une régle, il y a un mot clé « unsafe », qui dit bien ce qu'il dit.)
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Gabriel Dos Reis
Julien Blanc writes:
| Gabriel Dos Reis wrote: | > "Michel Michaud" writes: | > | > | Dans news:, Gabriel Dos | > | > "Alain Naigeon" writes: | > | >> Je lis dans Stroustrup, 2ème édition française, page 10, une mise | > | >> en garde contre les données membres publiques (mais dans certaines | > | >> circonstances, j'ajoute, pour être honnête). | > | > | > | > ce qui est important, c'est « dans certaines conditions ». | > | > Je mentionne encore l'exemple de std::pair<>. | > | | > | Mais là, il faut avouer que certaines personnes disent justement que | > | c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas | > | que les données publiques soient toujours des erreurs) | > | > Pourquoi est-ce une erreur ? Qu'est-ce qu'on veut abstraire avec | > std::pair ? Qu'est-ce qu'on veut protéger ? | | je pense que cela peut se révéler gênant sur certaines instanciations | particulières.
Alors pourquoi cela ne serait pas en ne les mettant pas publics ?
| Si j'ai un invariant que dois respecter ma paire, le fait | d'avoir un accès direct en écriture aux éléments de pair supprime toute | garantie sur cet invariant.
Sauf qu'ici ce n'est pas le but de std::pair. std::pair est une aggrégation de deux données, rien de plus, rien de moins.
| Le fait d'avoir des accesseurs en écriture | me permettrait de les redéfinir pour garantir cet invariant.
Comment ?
-- Gaby
Julien Blanc <Julien.Blanc@imag.fr> writes:
| Gabriel Dos Reis wrote:
| > "Michel Michaud" <mm@gdzid.com> writes:
| >
| > | Dans news:m3n0fchm9m.fsf@uniton.integrable-solutions.net, Gabriel Dos
| > | > "Alain Naigeon" <anaigeon@free.fr> writes:
| > | >> Je lis dans Stroustrup, 2ème édition française, page 10, une mise
| > | >> en garde contre les données membres publiques (mais dans certaines
| > | >> circonstances, j'ajoute, pour être honnête).
| > | >
| > | > ce qui est important, c'est « dans certaines conditions ».
| > | > Je mentionne encore l'exemple de std::pair<>.
| > |
| > | Mais là, il faut avouer que certaines personnes disent justement que
| > | c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas
| > | que les données publiques soient toujours des erreurs)
| >
| > Pourquoi est-ce une erreur ? Qu'est-ce qu'on veut abstraire avec
| > std::pair ? Qu'est-ce qu'on veut protéger ?
|
| je pense que cela peut se révéler gênant sur certaines instanciations
| particulières.
Alors pourquoi cela ne serait pas en ne les mettant pas publics ?
| Si j'ai un invariant que dois respecter ma paire, le fait
| d'avoir un accès direct en écriture aux éléments de pair supprime toute
| garantie sur cet invariant.
Sauf qu'ici ce n'est pas le but de std::pair.
std::pair est une aggrégation de deux données, rien de plus, rien de
moins.
| Le fait d'avoir des accesseurs en écriture
| me permettrait de les redéfinir pour garantir cet invariant.
| Gabriel Dos Reis wrote: | > "Michel Michaud" writes: | > | > | Dans news:, Gabriel Dos | > | > "Alain Naigeon" writes: | > | >> Je lis dans Stroustrup, 2ème édition française, page 10, une mise | > | >> en garde contre les données membres publiques (mais dans certaines | > | >> circonstances, j'ajoute, pour être honnête). | > | > | > | > ce qui est important, c'est « dans certaines conditions ». | > | > Je mentionne encore l'exemple de std::pair<>. | > | | > | Mais là, il faut avouer que certaines personnes disent justement que | > | c'est une erreur d'avoir les données publiques. (ce qui ne prouve pas | > | que les données publiques soient toujours des erreurs) | > | > Pourquoi est-ce une erreur ? Qu'est-ce qu'on veut abstraire avec | > std::pair ? Qu'est-ce qu'on veut protéger ? | | je pense que cela peut se révéler gênant sur certaines instanciations | particulières.
Alors pourquoi cela ne serait pas en ne les mettant pas publics ?
| Si j'ai un invariant que dois respecter ma paire, le fait | d'avoir un accès direct en écriture aux éléments de pair supprime toute | garantie sur cet invariant.
Sauf qu'ici ce n'est pas le but de std::pair. std::pair est une aggrégation de deux données, rien de plus, rien de moins.
| Le fait d'avoir des accesseurs en écriture | me permettrait de les redéfinir pour garantir cet invariant.
Comment ?
-- Gaby
Christophe Lephay
a écrit dans le message de news:
Le problème ne concerne que ceux qui ont fait des études supérieur:-). Et pas tout d'eux. Mais c'est caractèristique du système d'éducation en France, et touche donc surtout ceux qui en sort.
J'ai une chance d'y échaper alors. Dieu merci, j'avais trouvé bien plus interessant le fait de fumer des joints à l'époque plutôt que d'aller à l'école ;)
Chris
<kanze@gabi-soft.fr> a écrit dans le message de
news:d6652001.0307180139.284f586a@posting.google.com...
Le problème ne concerne que ceux qui ont fait des
études supérieur:-). Et pas tout d'eux. Mais c'est caractèristique du
système d'éducation en France, et touche donc surtout ceux qui en sort.
J'ai une chance d'y échaper alors. Dieu merci, j'avais trouvé bien plus
interessant le fait de fumer des joints à l'époque plutôt que d'aller à
l'école ;)
Le problème ne concerne que ceux qui ont fait des études supérieur:-). Et pas tout d'eux. Mais c'est caractèristique du système d'éducation en France, et touche donc surtout ceux qui en sort.
J'ai une chance d'y échaper alors. Dieu merci, j'avais trouvé bien plus interessant le fait de fumer des joints à l'époque plutôt que d'aller à l'école ;)
Chris
Christophe Lephay
a écrit dans le message de news:
N'est-ce pas ? Il y a aussi le problème qu'une fois tu es un spécialiste en X, on te propose rarement des boulots avec Y.
Et c'est vraiment une plaie pour les gens qui veulent toucher un peu à tout (c'est mon cas) !
Chris
<kanze@gabi-soft.fr> a écrit dans le message de
news:d6652001.0307180028.450cc89d@posting.google.com...
N'est-ce pas ? Il y a aussi le problème qu'une fois tu es un spécialiste
en X, on te propose rarement des boulots avec Y.
Et c'est vraiment une plaie pour les gens qui veulent toucher un peu à tout
(c'est mon cas) !
Every feature must have a reasonably obvious implementation. Always provide a transition path.
Arf! Ca s'applique aussi à "export" ? :-)
Arnaud
Gabriel Dos Reis
"Christophe Lephay" writes:
| "Arnaud Debaene" a écrit dans le message de | news: | > Gabriel Dos Reis wrote in message | news:... | > | > > Every feature must have a reasonably obvious implementation. | > > Always provide a transition path. | > | > Arf! Ca s'applique aussi à "export" ? :-) | | Pff, si c'est pas du mauvais esprit, ça.. ;)
Je n'ai pas vu le message de Arnaud Debaene, mais je lui réponds : Oui.
| "Arnaud Debaene" <adebaene@club-internet.fr> a écrit dans le message de
| news:16a4a8c7.0307180611.3341c7c8@posting.google.com...
| > Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
| news:<m3vfu1xpfr.fsf@uniton.integrable-solutions.net>...
| >
| > > Every feature must have a reasonably obvious implementation.
| > > Always provide a transition path.
| >
| > Arf! Ca s'applique aussi à "export" ? :-)
|
| Pff, si c'est pas du mauvais esprit, ça.. ;)
Je n'ai pas vu le message de Arnaud Debaene, mais je lui réponds : Oui.
| "Arnaud Debaene" a écrit dans le message de | news: | > Gabriel Dos Reis wrote in message | news:... | > | > > Every feature must have a reasonably obvious implementation. | > > Always provide a transition path. | > | > Arf! Ca s'applique aussi à "export" ? :-) | | Pff, si c'est pas du mauvais esprit, ça.. ;)
Je n'ai pas vu le message de Arnaud Debaene, mais je lui réponds : Oui.
-- Gaby
Christophe Lephay
"Arnaud Debaene" a écrit dans le message de news:
Gabriel Dos Reis wrote in message news:...
Every feature must have a reasonably obvious implementation. Always provide a transition path.
Arf! Ca s'applique aussi à "export" ? :-)
Pff, si c'est pas du mauvais esprit, ça.. ;)
Chris
"Arnaud Debaene" <adebaene@club-internet.fr> a écrit dans le message de
news:16a4a8c7.0307180611.3341c7c8@posting.google.com...
Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
news:<m3vfu1xpfr.fsf@uniton.integrable-solutions.net>...
Every feature must have a reasonably obvious implementation.
Always provide a transition path.
