méthode statique

kanze

25/02/2004 à 11:25

Gabriel Dos Reis wrote in message
news:...

writes:

| Si le callback a un paramètre, la meilleur solution est de s'en
| servir. Comme on fait avec pthread_create:

| class Thread
| {
| public:
| void start() ;
| virtual void run() = 0 ;

Je note avec intérêt que tu montres des classes avec des fonctions
virtuelles publiques ;-)

Tout à fait. Les fonctions virtuelles privées, c'est un moyen, non une
fin. La fin, c'est l'enforcement du contrat. Alors, quel est le contrat
de run() ?

En fait, c'est Kelvin Henney qui m'a fait comprendre cette
particularité, il y a longtemps, en comp.lang.c++.moderated. Il parlait
de « call inversion », mais je crois que l'idée est plus générale : il y
a des interfaces dont le rôle est précisement de permettre tout à
l'utilisateur : c'est le cas des callbacks, ou des visiteurs, par
exemple. Dans ces cas-là, la programmation par contrat n'a pas de sens,
parce que le but, c'est de ne pas imposer un contrat. Du coup, si la
programmation par contrat n'a pas de sens, les moyens de l'implémenter
ne sert pas.

--
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

25/02/2004 à 12:32

writes:

| Gabriel Dos Reis wrote in message
| news:...
| > writes:
|
| > | Si le callback a un paramètre, la meilleur solution est de s'en
| > | servir. Comme on fait avec pthread_create:
|
| > | class Thread
| > | {
| > | public:
| > | void start() ;
| > | virtual void run() = 0 ;
|
| > Je note avec intérêt que tu montres des classes avec des fonctions
| > virtuelles publiques ;-)
|
| Tout à fait. Les fonctions virtuelles privées, c'est un moyen, non une
| fin.

Heureux de te l'entendre dire !

C'est en effet une des faiblesses de Java. En C++, par exemple, il
est plus ou moins réconnu qu'une fonction publique n'est jamais
virtuelle. Elle renvoie à une fonction protégée virtuelle, toute
en vérifiant des pré- et des post-conditions, et éventuellement en
l'instrumentant. Chose qui est impossible en Java.

Message-ID:

| La fin, c'est l'enforcement du contrat. Alors, quel est le contrat
| de run() ?

C'est à toi de me le dire, je suis presque tenté de dire ;-/

Je ne suis pas connu pour avoir une position dogmatique sur les
fonctions virtuelles (ou toute autre fonctionnalité de C++). En fait
si, j'ai un dogme : les fonctionnalités de C++ devraient être
utilisées là cela elles ont du sens et là où elles servent de manière
utile. Par exemple, je dérive publiquement d'une classe
non-polymorphe, ou j'utilise des fonctions virtuelles publiques, ou
j'utilise des templates pour réduire le code-bloat (oui, surprenant,
non ?) qu'on pourrait trouver avec les techniques classiques «
orientées objet », etc.. là cela a du sens. Je n'ai pas d'obédiance
prédéfiniw ;-)

| En fait, c'est Kelvin Henney qui m'a fait comprendre cette
| particularité, il y a longtemps, en comp.lang.c++.moderated. Il parlait

Août 2001 n'est pas si « longtemps » ;-/

[...]

| parce que le but, c'est de ne pas imposer un contrat. Du coup, si la
| programmation par contrat n'a pas de sens, les moyens de l'implémenter
| ne sert pas.

Oh très certainement ; et je ne dirais pas le contraire. Mais il y a
une forte rumeur urbaine qui dit qu'une fonction virtuelle, en C++,
n'est jamais publique ;-)

-- Gaby

kanze@gabi-soft.fr writes:

| Gabriel Dos Reis <gdr@cs.tamu.edu> wrote in message
| news:<m3brno60ye.fsf@merlin.cs.tamu.edu>...
| > kanze@gabi-soft.fr writes:
|
| > | Si le callback a un paramètre, la meilleur solution est de s'en
| > | servir. Comme on fait avec pthread_create:
|
| > | class Thread
| > | {
| > | public:
| > | void start() ;
| > | virtual void run() = 0 ;
|
| > Je note avec intérêt que tu montres des classes avec des fonctions
| > virtuelles publiques ;-)
|
| Tout à fait. Les fonctions virtuelles privées, c'est un moyen, non une
| fin.

Heureux de te l'entendre dire !

C'est en effet une des faiblesses de Java. En C++, par exemple, il
est plus ou moins réconnu qu'une fonction publique n'est jamais
virtuelle. Elle renvoie à une fonction protégée virtuelle, toute
en vérifiant des pré- et des post-conditions, et éventuellement en
l'instrumentant. Chose qui est impossible en Java.

Message-ID: <86og1gw1nf.fsf@gabi-soft.de>

| La fin, c'est l'enforcement du contrat. Alors, quel est le contrat
| de run() ?

C'est à toi de me le dire, je suis presque tenté de dire ;-/

Je ne suis pas connu pour avoir une position dogmatique sur les
fonctions virtuelles (ou toute autre fonctionnalité de C++). En fait
si, j'ai un dogme : les fonctionnalités de C++ devraient être
utilisées là cela elles ont du sens et là où elles servent de manière
utile. Par exemple, je dérive publiquement d'une classe
non-polymorphe, ou j'utilise des fonctions virtuelles publiques, ou
j'utilise des templates pour réduire le code-bloat (oui, surprenant,
non ?) qu'on pourrait trouver avec les techniques classiques «
orientées objet », etc.. là cela a du sens. Je n'ai pas d'obédiance
prédéfiniw ;-)

| En fait, c'est Kelvin Henney qui m'a fait comprendre cette
| particularité, il y a longtemps, en comp.lang.c++.moderated. Il parlait

Août 2001 n'est pas si « longtemps » ;-/

[...]

| parce que le but, c'est de ne pas imposer un contrat. Du coup, si la
| programmation par contrat n'a pas de sens, les moyens de l'implémenter
| ne sert pas.

Oh très certainement ; et je ne dirais pas le contraire. Mais il y a
une forte rumeur urbaine qui dit qu'une fonction virtuelle, en C++,
n'est jamais publique ;-)

-- Gaby

Vous avez filtré cet utilisateur ! Consultez son message

writes:

| Gabriel Dos Reis wrote in message
| news:...
| > writes:
|
| > | Si le callback a un paramètre, la meilleur solution est de s'en
| > | servir. Comme on fait avec pthread_create:
|
| > | class Thread
| > | {
| > | public:
| > | void start() ;
| > | virtual void run() = 0 ;
|
| > Je note avec intérêt que tu montres des classes avec des fonctions
| > virtuelles publiques ;-)
|
| Tout à fait. Les fonctions virtuelles privées, c'est un moyen, non une
| fin.

Heureux de te l'entendre dire !

C'est en effet une des faiblesses de Java. En C++, par exemple, il
est plus ou moins réconnu qu'une fonction publique n'est jamais
virtuelle. Elle renvoie à une fonction protégée virtuelle, toute
en vérifiant des pré- et des post-conditions, et éventuellement en
l'instrumentant. Chose qui est impossible en Java.

Message-ID:

| La fin, c'est l'enforcement du contrat. Alors, quel est le contrat
| de run() ?

C'est à toi de me le dire, je suis presque tenté de dire ;-/

Je ne suis pas connu pour avoir une position dogmatique sur les
fonctions virtuelles (ou toute autre fonctionnalité de C++). En fait
si, j'ai un dogme : les fonctionnalités de C++ devraient être
utilisées là cela elles ont du sens et là où elles servent de manière
utile. Par exemple, je dérive publiquement d'une classe
non-polymorphe, ou j'utilise des fonctions virtuelles publiques, ou
j'utilise des templates pour réduire le code-bloat (oui, surprenant,
non ?) qu'on pourrait trouver avec les techniques classiques «
orientées objet », etc.. là cela a du sens. Je n'ai pas d'obédiance
prédéfiniw ;-)

| En fait, c'est Kelvin Henney qui m'a fait comprendre cette
| particularité, il y a longtemps, en comp.lang.c++.moderated. Il parlait

Août 2001 n'est pas si « longtemps » ;-/

[...]

| parce que le but, c'est de ne pas imposer un contrat. Du coup, si la
| programmation par contrat n'a pas de sens, les moyens de l'implémenter
| ne sert pas.

Oh très certainement ; et je ne dirais pas le contraire. Mais il y a
une forte rumeur urbaine qui dit qu'une fonction virtuelle, en C++,
n'est jamais publique ;-)

-- Gaby

kanze

26/02/2004 à 14:51

Gabriel Dos Reis wrote in message
news:...

writes:

| Gabriel Dos Reis wrote in message
| news:...
| > writes:

| > | Si le callback a un paramètre, la meilleur solution est de s'en
| > | servir. Comme on fait avec pthread_create:

| > | class Thread
| > | {
| > | public:
| > | void start() ;
| > | virtual void run() = 0 ;

| > Je note avec intérêt que tu montres des classes avec des
| > fonctions virtuelles publiques ;-)

| Tout à fait. Les fonctions virtuelles privées, c'est un moyen, non
| une fin.

Heureux de te l'entendre dire !

C'est en effet une des faiblesses de Java. En C++, par exemple, il
est plus ou moins réconnu qu'une fonction publique n'est jamais
virtuelle. Elle renvoie à une fonction protégée virtuelle, toute
en vérifiant des pré- et des post-conditions, et éventuellement en
l'instrumentant. Chose qui est impossible en Java.

Message-ID:

C'est de quand. Je sais que ma position a évolué dans le temps (ce qui
est normal, je crois).

Si tu cherches des idées que j'ai suggéré dans la passée, et que je
récuse aujourd'hui, il y en a bien pire. Même aujourd'hui, je dirais que
dans la plupart des classes, les fonctions virtuelles ne doivent pas
être publiques. Pas parce que c'est une règle en soi, mais parce que la
plupart des classes (de base) définissent un contrat, et quand il y a un
contrat, on aime prévoir les moyens de l'enforcer.

Ceci dit, tu sais bien que j'aime melanger le litote et la hyperbole.
C'est une faiblesse réele de Java qu'on ne peut pas utiliser cet idiome.
Le « jamais » ci-dessus tient de la hyperbole, mais le remplacé par
« que rarement », et je soutiens la reste même aujourd'hui.

| La fin, c'est l'enforcement du contrat. Alors, quel est le contrat
| de run() ?

C'est à toi de me le dire, je suis presque tenté de dire ;-/

Je ne suis pas connu pour avoir une position dogmatique sur les
fonctions virtuelles (ou toute autre fonctionnalité de C++).

J'aurais cru que toi, tu l'aurais compris déjà : mes prises de position
« dogmatique » sont toujours des prises de position contre une attitude
exagérée prévalente, et non une expression de toute mon attitude (ce qui
tiendrait rarement dans un posting d'ailleurs -- les choses sont prèsque
toujours trop nuancées). Donc, pendant longtemps, j'ai râlé fort contre
tout ce que semblait optimisation -- parce que partout, je ne voyais que
des gens qui se mettaient à optimiser du code qui ne marchait même pas.
Dernièrement, il y a eu un vent dans l'autre direction -- l'optimisation
n'a aucune importance, vue la performance des machines actuelles. Du
coup, tu m'as vu râlé contre les compilateurs qui ignorent inline -- la
réalité veut qu'il y a des cas où l'optimisation est importante (ce dont
je ne me suis jamais douté, mais qu'il ne semblait pas la peine de dire
auparavent), et qu'il serait vraiment stupid de s'en priver d'un moyen
aussi simple à la fois pour l'utilisateur et pour l'implémenteur du
compilateur.

Mais j'ai parfois l'impression que tu fais pareil. Si je dis noir, tu
dis blanc, peut-être simplement pour me faire plus y reflechir. Alors
que tous les deux, on le sait gris.

En fait si, j'ai un dogme : les fonctionnalités de C++ devraient être
utilisées là cela elles ont du sens et là où elles servent de manière
utile.

Tout à fait d'accord. Maintenant : mets ce dogme dans une règle de
codage qui pourrait servir à des programmeurs moyens dans une grosse
boîte.

Dire que définir un contrat pour toute classe de base est utile a un
sens. Dire que le moyen d'enforcer ce contrat, c'est avec des fonctions
virtuelles non-publique, ça a aussi un sens. Dire aussi que dans
certains cas bien précis, le contrat, c'est de laisser toute liberté à
celui qui en dérive, et que dans ce cas-là, enforcer le contrat n'a pas
de sens, a aussi un sens.

Par exemple, je dérive publiquement d'une classe non-polymorphe, ou
j'utilise des fonctions virtuelles publiques, ou j'utilise des
templates pour réduire le code-bloat (oui, surprenant, non ?) qu'on
pourrait trouver avec les techniques classiques « orientées objet »,
etc.. là cela a du sens. Je n'ai pas d'obédiance prédéfiniw ;-)

| En fait, c'est Kelvin Henney qui m'a fait comprendre cette
| particularité, il y a longtemps, en comp.lang.c++.moderated. Il
| parlait

Août 2001 n'est pas si « longtemps » ;-/

C'est rélatif, effectivement.

[...]

| parce que le but, c'est de ne pas imposer un contrat. Du coup, si la
| programmation par contrat n'a pas de sens, les moyens de
| l'implémenter ne sert pas.

Oh très certainement ; et je ne dirais pas le contraire. Mais il y a
une forte rumeur urbaine qui dit qu'une fonction virtuelle, en C++,
n'est jamais publique ;-)

J'avoue que dans ce cas-ci, la réaction m'a dépassé. Herb Sutter a bien
publié un article contre les fonctions virtuelles publiques, et il se
basait en partie des choses que j'avais dit avant. Mais même alors (et
c'est avant la discussion avec Henney), si tu régardes dans
comp.lang.c++.moderated, j'essaiais à nuancer. L'importance, ce n'était
pas que les fonctions virtuelles ne soient pas publiques ; l'importance,
c'est pourquoi on voulait qu'elles ne le soient pas. Herb s'est (à mon
avis) embrouillé dans une histoire du modèle template qui (toujours à
mon avis) ne s'applique que rarement. C'est vrai que quand j'utilise un
modèle template, les fonctions virtuelles sont privées. Mais c'est aussi
vrai que le modèle template, ce ne doit pas être si courant que ça, et
que surtout, quand on implémente un modèle template, ça doit être parce
que la conception exige un modèle template, et non à tout hazard parce
que je crois que peut-être un jour ça pourrait servir. (À l'époque, en
revanche, je crois que je ne m'étais pas encore rendu compte que la
notion de contrat ne s'appliquait pas par tout.)

--
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 <gdr@cs.tamu.edu> wrote in message
news:<m3ishvcs2p.fsf@merlin.cs.tamu.edu>...

kanze@gabi-soft.fr writes:

| Gabriel Dos Reis <gdr@cs.tamu.edu> wrote in message
| news:<m3brno60ye.fsf@merlin.cs.tamu.edu>...
| > kanze@gabi-soft.fr writes:

| > | Si le callback a un paramètre, la meilleur solution est de s'en
| > | servir. Comme on fait avec pthread_create:

| > | class Thread
| > | {
| > | public:
| > | void start() ;
| > | virtual void run() = 0 ;

| > Je note avec intérêt que tu montres des classes avec des
| > fonctions virtuelles publiques ;-)

| Tout à fait. Les fonctions virtuelles privées, c'est un moyen, non
| une fin.

Heureux de te l'entendre dire !

C'est en effet une des faiblesses de Java. En C++, par exemple, il
est plus ou moins réconnu qu'une fonction publique n'est jamais
virtuelle. Elle renvoie à une fonction protégée virtuelle, toute
en vérifiant des pré- et des post-conditions, et éventuellement en
l'instrumentant. Chose qui est impossible en Java.

Message-ID: <86og1gw1nf.fsf@gabi-soft.de>

C'est de quand. Je sais que ma position a évolué dans le temps (ce qui
est normal, je crois).

Si tu cherches des idées que j'ai suggéré dans la passée, et que je
récuse aujourd'hui, il y en a bien pire. Même aujourd'hui, je dirais que
dans la plupart des classes, les fonctions virtuelles ne doivent pas
être publiques. Pas parce que c'est une règle en soi, mais parce que la
plupart des classes (de base) définissent un contrat, et quand il y a un
contrat, on aime prévoir les moyens de l'enforcer.

Ceci dit, tu sais bien que j'aime melanger le litote et la hyperbole.
C'est une faiblesse réele de Java qu'on ne peut pas utiliser cet idiome.
Le « jamais » ci-dessus tient de la hyperbole, mais le remplacé par
« que rarement », et je soutiens la reste même aujourd'hui.

| La fin, c'est l'enforcement du contrat. Alors, quel est le contrat
| de run() ?

C'est à toi de me le dire, je suis presque tenté de dire ;-/

Je ne suis pas connu pour avoir une position dogmatique sur les
fonctions virtuelles (ou toute autre fonctionnalité de C++).

J'aurais cru que toi, tu l'aurais compris déjà : mes prises de position
« dogmatique » sont toujours des prises de position contre une attitude
exagérée prévalente, et non une expression de toute mon attitude (ce qui
tiendrait rarement dans un posting d'ailleurs -- les choses sont prèsque
toujours trop nuancées). Donc, pendant longtemps, j'ai râlé fort contre
tout ce que semblait optimisation -- parce que partout, je ne voyais que
des gens qui se mettaient à optimiser du code qui ne marchait même pas.
Dernièrement, il y a eu un vent dans l'autre direction -- l'optimisation
n'a aucune importance, vue la performance des machines actuelles. Du
coup, tu m'as vu râlé contre les compilateurs qui ignorent inline -- la
réalité veut qu'il y a des cas où l'optimisation est importante (ce dont
je ne me suis jamais douté, mais qu'il ne semblait pas la peine de dire
auparavent), et qu'il serait vraiment stupid de s'en priver d'un moyen
aussi simple à la fois pour l'utilisateur et pour l'implémenteur du
compilateur.

Mais j'ai parfois l'impression que tu fais pareil. Si je dis noir, tu
dis blanc, peut-être simplement pour me faire plus y reflechir. Alors
que tous les deux, on le sait gris.

En fait si, j'ai un dogme : les fonctionnalités de C++ devraient être
utilisées là cela elles ont du sens et là où elles servent de manière
utile.

Tout à fait d'accord. Maintenant : mets ce dogme dans une règle de
codage qui pourrait servir à des programmeurs moyens dans une grosse
boîte.

Dire que définir un contrat pour toute classe de base est utile a un
sens. Dire que le moyen d'enforcer ce contrat, c'est avec des fonctions
virtuelles non-publique, ça a aussi un sens. Dire aussi que dans
certains cas bien précis, le contrat, c'est de laisser toute liberté à
celui qui en dérive, et que dans ce cas-là, enforcer le contrat n'a pas
de sens, a aussi un sens.

Par exemple, je dérive publiquement d'une classe non-polymorphe, ou
j'utilise des fonctions virtuelles publiques, ou j'utilise des
templates pour réduire le code-bloat (oui, surprenant, non ?) qu'on
pourrait trouver avec les techniques classiques « orientées objet »,
etc.. là cela a du sens. Je n'ai pas d'obédiance prédéfiniw ;-)

| En fait, c'est Kelvin Henney qui m'a fait comprendre cette
| particularité, il y a longtemps, en comp.lang.c++.moderated. Il
| parlait

Août 2001 n'est pas si « longtemps » ;-/

C'est rélatif, effectivement.

[...]

| parce que le but, c'est de ne pas imposer un contrat. Du coup, si la
| programmation par contrat n'a pas de sens, les moyens de
| l'implémenter ne sert pas.

Oh très certainement ; et je ne dirais pas le contraire. Mais il y a
une forte rumeur urbaine qui dit qu'une fonction virtuelle, en C++,
n'est jamais publique ;-)

J'avoue que dans ce cas-ci, la réaction m'a dépassé. Herb Sutter a bien
publié un article contre les fonctions virtuelles publiques, et il se
basait en partie des choses que j'avais dit avant. Mais même alors (et
c'est avant la discussion avec Henney), si tu régardes dans
comp.lang.c++.moderated, j'essaiais à nuancer. L'importance, ce n'était
pas que les fonctions virtuelles ne soient pas publiques ; l'importance,
c'est pourquoi on voulait qu'elles ne le soient pas. Herb s'est (à mon
avis) embrouillé dans une histoire du modèle template qui (toujours à
mon avis) ne s'applique que rarement. C'est vrai que quand j'utilise un
modèle template, les fonctions virtuelles sont privées. Mais c'est aussi
vrai que le modèle template, ce ne doit pas être si courant que ça, et
que surtout, quand on implémente un modèle template, ça doit être parce
que la conception exige un modèle template, et non à tout hazard parce
que je crois que peut-être un jour ça pourrait servir. (À l'époque, en
revanche, je crois que je ne m'étais pas encore rendu compte que la
notion de contrat ne s'appliquait pas par tout.)

--
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

Vous avez filtré cet utilisateur ! Consultez son message

Gabriel Dos Reis wrote in message
news:...

writes:

| Gabriel Dos Reis wrote in message
| news:...
| > writes:

| > | Si le callback a un paramètre, la meilleur solution est de s'en
| > | servir. Comme on fait avec pthread_create:

| > | class Thread
| > | {
| > | public:
| > | void start() ;
| > | virtual void run() = 0 ;

| > Je note avec intérêt que tu montres des classes avec des
| > fonctions virtuelles publiques ;-)

| Tout à fait. Les fonctions virtuelles privées, c'est un moyen, non
| une fin.

Heureux de te l'entendre dire !

C'est en effet une des faiblesses de Java. En C++, par exemple, il
est plus ou moins réconnu qu'une fonction publique n'est jamais
virtuelle. Elle renvoie à une fonction protégée virtuelle, toute
en vérifiant des pré- et des post-conditions, et éventuellement en
l'instrumentant. Chose qui est impossible en Java.

Message-ID:

C'est de quand. Je sais que ma position a évolué dans le temps (ce qui
est normal, je crois).

Si tu cherches des idées que j'ai suggéré dans la passée, et que je
récuse aujourd'hui, il y en a bien pire. Même aujourd'hui, je dirais que
dans la plupart des classes, les fonctions virtuelles ne doivent pas
être publiques. Pas parce que c'est une règle en soi, mais parce que la
plupart des classes (de base) définissent un contrat, et quand il y a un
contrat, on aime prévoir les moyens de l'enforcer.

Ceci dit, tu sais bien que j'aime melanger le litote et la hyperbole.
C'est une faiblesse réele de Java qu'on ne peut pas utiliser cet idiome.
Le « jamais » ci-dessus tient de la hyperbole, mais le remplacé par
« que rarement », et je soutiens la reste même aujourd'hui.

| La fin, c'est l'enforcement du contrat. Alors, quel est le contrat
| de run() ?

C'est à toi de me le dire, je suis presque tenté de dire ;-/

Je ne suis pas connu pour avoir une position dogmatique sur les
fonctions virtuelles (ou toute autre fonctionnalité de C++).

J'aurais cru que toi, tu l'aurais compris déjà : mes prises de position
« dogmatique » sont toujours des prises de position contre une attitude
exagérée prévalente, et non une expression de toute mon attitude (ce qui
tiendrait rarement dans un posting d'ailleurs -- les choses sont prèsque
toujours trop nuancées). Donc, pendant longtemps, j'ai râlé fort contre
tout ce que semblait optimisation -- parce que partout, je ne voyais que
des gens qui se mettaient à optimiser du code qui ne marchait même pas.
Dernièrement, il y a eu un vent dans l'autre direction -- l'optimisation
n'a aucune importance, vue la performance des machines actuelles. Du
coup, tu m'as vu râlé contre les compilateurs qui ignorent inline -- la
réalité veut qu'il y a des cas où l'optimisation est importante (ce dont
je ne me suis jamais douté, mais qu'il ne semblait pas la peine de dire
auparavent), et qu'il serait vraiment stupid de s'en priver d'un moyen
aussi simple à la fois pour l'utilisateur et pour l'implémenteur du
compilateur.

Mais j'ai parfois l'impression que tu fais pareil. Si je dis noir, tu
dis blanc, peut-être simplement pour me faire plus y reflechir. Alors
que tous les deux, on le sait gris.

En fait si, j'ai un dogme : les fonctionnalités de C++ devraient être
utilisées là cela elles ont du sens et là où elles servent de manière
utile.

Tout à fait d'accord. Maintenant : mets ce dogme dans une règle de
codage qui pourrait servir à des programmeurs moyens dans une grosse
boîte.

Dire que définir un contrat pour toute classe de base est utile a un
sens. Dire que le moyen d'enforcer ce contrat, c'est avec des fonctions
virtuelles non-publique, ça a aussi un sens. Dire aussi que dans
certains cas bien précis, le contrat, c'est de laisser toute liberté à
celui qui en dérive, et que dans ce cas-là, enforcer le contrat n'a pas
de sens, a aussi un sens.

Par exemple, je dérive publiquement d'une classe non-polymorphe, ou
j'utilise des fonctions virtuelles publiques, ou j'utilise des
templates pour réduire le code-bloat (oui, surprenant, non ?) qu'on
pourrait trouver avec les techniques classiques « orientées objet »,
etc.. là cela a du sens. Je n'ai pas d'obédiance prédéfiniw ;-)

| En fait, c'est Kelvin Henney qui m'a fait comprendre cette
| particularité, il y a longtemps, en comp.lang.c++.moderated. Il
| parlait

Août 2001 n'est pas si « longtemps » ;-/

C'est rélatif, effectivement.

[...]

| parce que le but, c'est de ne pas imposer un contrat. Du coup, si la
| programmation par contrat n'a pas de sens, les moyens de
| l'implémenter ne sert pas.

Oh très certainement ; et je ne dirais pas le contraire. Mais il y a
une forte rumeur urbaine qui dit qu'une fonction virtuelle, en C++,
n'est jamais publique ;-)

J'avoue que dans ce cas-ci, la réaction m'a dépassé. Herb Sutter a bien
publié un article contre les fonctions virtuelles publiques, et il se
basait en partie des choses que j'avais dit avant. Mais même alors (et
c'est avant la discussion avec Henney), si tu régardes dans
comp.lang.c++.moderated, j'essaiais à nuancer. L'importance, ce n'était
pas que les fonctions virtuelles ne soient pas publiques ; l'importance,
c'est pourquoi on voulait qu'elles ne le soient pas. Herb s'est (à mon
avis) embrouillé dans une histoire du modèle template qui (toujours à
mon avis) ne s'applique que rarement. C'est vrai que quand j'utilise un
modèle template, les fonctions virtuelles sont privées. Mais c'est aussi
vrai que le modèle template, ce ne doit pas être si courant que ça, et
que surtout, quand on implémente un modèle template, ça doit être parce
que la conception exige un modèle template, et non à tout hazard parce
que je crois que peut-être un jour ça pourrait servir. (À l'époque, en
revanche, je crois que je ne m'étais pas encore rendu compte que la
notion de contrat ne s'appliquait pas par tout.)

--
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

Jean-Marc Bourguet

26/02/2004 à 14:58

writes:

Mais j'ai parfois l'impression que tu fais pareil. Si je dis noir,
tu dis blanc, peut-être simplement pour me faire plus y reflechir.

Toi? ou d'autres lecteurs qui te connaisse moins et qui seraient
tentes de te prendre au pied de la lettre?

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

Loïc Joly

26/02/2004 à 20:45

wrote:

la
réalité veut qu'il y a des cas où l'optimisation est importante (ce dont
je ne me suis jamais douté, mais qu'il ne semblait pas la peine de dire
auparavent),

D'habitue, je ne corrige pas les petites fautes de français, surtout
venant d'un américain d'origine, mais dans le cas présent, cette faute
fait dire à la phrase le contraire de ce tu voulais (je pense) dire. Je
la signale donc :

ce dont je ne me suis jamais douté -> je ne me suis jamais douté de
cette chose -> cette chose est une réelle surprise pour moi

ce dont je n'ai jamais douté -> je n'ai jamais douté de cette chose ->
cette chose est une certitude pour moi depuis toujours

--
Loïc

kanze

27/02/2004 à 09:55

Jean-Marc Bourguet wrote in message
news:...

writes:

Mais j'ai parfois l'impression que tu fais pareil. Si je dis noir,
tu dis blanc, peut-être simplement pour me faire plus y reflechir.

Toi? ou d'autres lecteurs qui te connaisse moins et qui seraient
tentes de te prendre au pied de la lettre?

Depuis Socrates, la dialectique a été reconnue comme forme efficace de
l'enseignement. Si quelqu'un dit A, ce n'est pas la peine que je repette
ses arguments, simplement pour qu'on se rend compte que ma position est
nuancée. Ce qu'on croît être ma position n'a finalement pas
d'importance ; ce qui importe, c'est l'ensemble que l'autre voit.

En passant, j'ajoute que ce ne s'applique pas au cas qui a commencé ce
thread. Il y a réelement eu une évolution dans mes pensées dans ce
cas-ci. Si c'est vrai que j'ai toujours cru que l'utilisation des
virtuelles non-publique était un moyen, et non une fin, j'ai bien cru
pendant longtemps qu'il fallait *toujours* définir un contrat pour une
classe. D'un certain sens, je le crois toujours : le contrat peut être
vide (ou ouvert), mais c'est toujours penser conscieusement comme un
contrat. C'est une décision consciente et documentée, et non simplement
le fruit d'hazard, ou un vague sentiment que peut-être le client
aimerait avoir cette liberté, pour faire quelque chose à laquelle je
n'ai pas pensé.

--
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

07/03/2004 à 18:00

Jean-Marc Bourguet writes:

| writes:
|
| > Mais j'ai parfois l'impression que tu fais pareil. Si je dis noir,
| > tu dis blanc, peut-être simplement pour me faire plus y reflechir.
|
| Toi? ou d'autres lecteurs qui te connaisse moins et qui seraient
| tentes de te prendre au pied de la lettre?

Je ne comprends pas ce que tu as voulu dire.
James a changé de « vision » sur virtual -- tu peux t'en rendre compte
en lisant ses anciens messages sur le sujet.

-- Gaby

méthode statique

7 réponses

Veuillez sélectionner un problème