| Gabriel Dos Reis wrote: | | > Fabien LE LEZ writes: | > | et ne s'utilise pas comme un | > | pointeur (pas besoin de l'opérateur "*")... | > | > Ça, c'est une invention du comité en ANSI C ; une invention que le | > Père a refusé de suivre en ce qui concerne les pointeurs sur membre. | > | | Ce qui a pour effet d'introduire une brisure de symétrie.
S'il y a brisure de symétrie, je ne suis pas certain qu'il soit du côté de C++ (à part retenir la règle de ANSI C pour compatibilité). C++ de ce point de vue là (i.e. pointer sur membre) est 100% cohérent avec C classique et le principe général que si on a un pointeur alors appliquer * permet d'accéder à la valeur pointée.
| Y avait-il un | autre intérêt qu'une histoire de goût à faire ce choix ?
Voir ci-dessus.
-- Gaby
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
| Gabriel Dos Reis wrote:
|
| > Fabien LE LEZ <gramster@gramster.com> writes:
| > | et ne s'utilise pas comme un
| > | pointeur (pas besoin de l'opérateur "*")...
| >
| > Ça, c'est une invention du comité en ANSI C ; une invention que le
| > Père a refusé de suivre en ce qui concerne les pointeurs sur membre.
| >
|
| Ce qui a pour effet d'introduire une brisure de symétrie.
S'il y a brisure de symétrie, je ne suis pas certain qu'il soit du
côté de C++ (à part retenir la règle de ANSI C pour compatibilité).
C++ de ce point de vue là (i.e. pointer sur membre) est 100% cohérent
avec C classique et le principe général que si on a un pointeur alors
appliquer * permet d'accéder à la valeur pointée.
| Y avait-il un
| autre intérêt qu'une histoire de goût à faire ce choix ?
| Gabriel Dos Reis wrote: | | > Fabien LE LEZ writes: | > | et ne s'utilise pas comme un | > | pointeur (pas besoin de l'opérateur "*")... | > | > Ça, c'est une invention du comité en ANSI C ; une invention que le | > Père a refusé de suivre en ce qui concerne les pointeurs sur membre. | > | | Ce qui a pour effet d'introduire une brisure de symétrie.
S'il y a brisure de symétrie, je ne suis pas certain qu'il soit du côté de C++ (à part retenir la règle de ANSI C pour compatibilité). C++ de ce point de vue là (i.e. pointer sur membre) est 100% cohérent avec C classique et le principe général que si on a un pointeur alors appliquer * permet d'accéder à la valeur pointée.
| Y avait-il un | autre intérêt qu'une histoire de goût à faire ce choix ?
Voir ci-dessus.
-- Gaby
Gabriel Dos Reis
"Alain Naigeon" writes:
| "Loïc Joly" a écrit dans le message news: | bkqa1r$vrn$ | > Fabien LE LEZ wrote: | > | > > D'ailleurs je trouve le terme "pointeur de/sur une fonction" plutôt | > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un | > > pointeur (pas convertible en void*) | > | > std::cout peut se convertir en void*, donc std::cout est un pointeur ! | | Sophisme.
Nullement. Cela amène simplement Fabien à regarder de plus près son assertion initiale.
-- Gaby
"Alain Naigeon" <anaigeon@free.fr> writes:
| "Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message news:
| bkqa1r$vrn$1@news-reader4.wanadoo.fr...
| > Fabien LE LEZ wrote:
| >
| > > D'ailleurs je trouve le terme "pointeur de/sur une fonction" plutôt
| > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un
| > > pointeur (pas convertible en void*)
| >
| > std::cout peut se convertir en void*, donc std::cout est un pointeur !
|
| Sophisme.
Nullement. Cela amène simplement Fabien à regarder de plus près son
assertion initiale.
| "Loïc Joly" a écrit dans le message news: | bkqa1r$vrn$ | > Fabien LE LEZ wrote: | > | > > D'ailleurs je trouve le terme "pointeur de/sur une fonction" plutôt | > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un | > > pointeur (pas convertible en void*) | > | > std::cout peut se convertir en void*, donc std::cout est un pointeur ! | | Sophisme.
Nullement. Cela amène simplement Fabien à regarder de plus près son assertion initiale.
-- Gaby
Samuel Krempp
le Tuesday 23 September 2003 23:59, écrivit :
"Alain Naigeon" writes:
| "Loïc Joly" a écrit dans le message news: | bkqa1r$vrn$ | > Fabien LE LEZ wrote: | > | > > D'ailleurs je trouve le terme "pointeur de/sur une fonction" plutôt | > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un | > > pointeur (pas convertible en void*) | > | > std::cout peut se convertir en void*, donc std::cout est un pointeur ! | | Sophisme.
Nullement. Cela amène simplement Fabien à regarder de plus près son assertion initiale.
Fabien : pas convertible en void* => pas vraiment en pointeur Loïc : ah, mais alors, comme cout est convertible en void *, cout est un pointeur C'est implicitement un raisonnement pour justifier que Fabien a tort. Mais comme il fait dire à l'implication de Fabien ce qu'elle ne veut pas dire, le raisonnement est faux. (indépendamment de la vérité ou non de l'assertion initiale de Fabien) Qu'on appelle ça un sophisme ou pas, c'est une question de Français. Pour ma part avec les définitions de http://zeus.inalf.cnrs.fr/ je ne sais pas.
-- Sam
le Tuesday 23 September 2003 23:59, dosreis@cmla.ens-cachan.fr écrivit :
"Alain Naigeon" <anaigeon@free.fr> writes:
| "Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message news:
| bkqa1r$vrn$1@news-reader4.wanadoo.fr...
| > Fabien LE LEZ wrote:
| >
| > > D'ailleurs je trouve le terme "pointeur de/sur une fonction" plutôt
| > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un
| > > pointeur (pas convertible en void*)
| >
| > std::cout peut se convertir en void*, donc std::cout est un pointeur !
|
| Sophisme.
Nullement. Cela amène simplement Fabien à regarder de plus près son
assertion initiale.
Fabien : pas convertible en void* => pas vraiment en pointeur
Loïc : ah, mais alors, comme cout est convertible en void *,
cout est un pointeur
C'est implicitement un raisonnement pour justifier que Fabien a tort.
Mais comme il fait dire à l'implication de Fabien ce qu'elle ne veut pas
dire, le raisonnement est faux. (indépendamment de la vérité ou non de
l'assertion initiale de Fabien)
Qu'on appelle ça un sophisme ou pas, c'est une question de Français. Pour ma
part avec les définitions de http://zeus.inalf.cnrs.fr/ je ne sais pas.
| "Loïc Joly" a écrit dans le message news: | bkqa1r$vrn$ | > Fabien LE LEZ wrote: | > | > > D'ailleurs je trouve le terme "pointeur de/sur une fonction" plutôt | > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un | > > pointeur (pas convertible en void*) | > | > std::cout peut se convertir en void*, donc std::cout est un pointeur ! | | Sophisme.
Nullement. Cela amène simplement Fabien à regarder de plus près son assertion initiale.
Fabien : pas convertible en void* => pas vraiment en pointeur Loïc : ah, mais alors, comme cout est convertible en void *, cout est un pointeur C'est implicitement un raisonnement pour justifier que Fabien a tort. Mais comme il fait dire à l'implication de Fabien ce qu'elle ne veut pas dire, le raisonnement est faux. (indépendamment de la vérité ou non de l'assertion initiale de Fabien) Qu'on appelle ça un sophisme ou pas, c'est une question de Français. Pour ma part avec les définitions de http://zeus.inalf.cnrs.fr/ je ne sais pas.
-- Sam
Michel Michaud
Dans news:, Gabriel Dos
S'il y a brisure de symétrie, je ne suis pas certain qu'il soit du côté de C++ (à part retenir la règle de ANSI C pour compatibilité). C++ de ce point de vue là (i.e. pointer sur membre) est 100% cohérent avec C classique et le principe général que si on a un pointeur alors appliquer * permet d'accéder à la valeur pointée.
Je ne suis pas certain, * n'est pas le seul opérateur de déréférencement. On peut voir l'appel de fonction comme une sorte de déréférencement. Comparons :
int a[100]; int *b= a;
int c= b[0];
int d(int e[]) { return e[0]; } int f(int *g) { return *g; } d(a); d(b); f(a); f(b);
Avec
int A(int); int (*B)(int)= A;
int C= B(0);
int D(int E(int)) { return E(0); } int F(int (*G)(int)) { return (*G)(0); } D(A); D(B); F(A); F(B);
Ça me semble assez cohérent :-)
(Je sais, je n'ai mis que ce qui est cohérent :-)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:flk77zkzp0.fsf@sel.cmla.ens-cachan.fr, Gabriel Dos
S'il y a brisure de symétrie, je ne suis pas certain qu'il soit du
côté de C++ (à part retenir la règle de ANSI C pour compatibilité).
C++ de ce point de vue là (i.e. pointer sur membre) est 100%
cohérent avec C classique et le principe général que si on a un
pointeur alors appliquer * permet d'accéder à la valeur pointée.
Je ne suis pas certain, * n'est pas le seul opérateur de
déréférencement. On peut voir l'appel de fonction comme une sorte
de déréférencement. Comparons :
int a[100];
int *b= a;
int c= b[0];
int d(int e[]) { return e[0]; }
int f(int *g) { return *g; }
d(a); d(b);
f(a); f(b);
Avec
int A(int);
int (*B)(int)= A;
int C= B(0);
int D(int E(int)) { return E(0); }
int F(int (*G)(int)) { return (*G)(0); }
D(A); D(B);
F(A); F(B);
Ça me semble assez cohérent :-)
(Je sais, je n'ai mis que ce qui est cohérent :-)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
S'il y a brisure de symétrie, je ne suis pas certain qu'il soit du côté de C++ (à part retenir la règle de ANSI C pour compatibilité). C++ de ce point de vue là (i.e. pointer sur membre) est 100% cohérent avec C classique et le principe général que si on a un pointeur alors appliquer * permet d'accéder à la valeur pointée.
Je ne suis pas certain, * n'est pas le seul opérateur de déréférencement. On peut voir l'appel de fonction comme une sorte de déréférencement. Comparons :
int a[100]; int *b= a;
int c= b[0];
int d(int e[]) { return e[0]; } int f(int *g) { return *g; } d(a); d(b); f(a); f(b);
Avec
int A(int); int (*B)(int)= A;
int C= B(0);
int D(int E(int)) { return E(0); } int F(int (*G)(int)) { return (*G)(0); } D(A); D(B); F(A); F(B);
Ça me semble assez cohérent :-)
(Je sais, je n'ai mis que ce qui est cohérent :-)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Gabriel Dos Reis
"Michel Michaud" writes:
| Dans news:, Gabriel Dos | > S'il y a brisure de symétrie, je ne suis pas certain qu'il soit du | > côté de C++ (à part retenir la règle de ANSI C pour compatibilité). | > C++ de ce point de vue là (i.e. pointer sur membre) est 100% | > cohérent avec C classique et le principe général que si on a un | > pointeur alors appliquer * permet d'accéder à la valeur pointée. | | Je ne suis pas certain, * n'est pas le seul opérateur de | déréférencement. On peut voir l'appel de fonction comme une sorte | de déréférencement. Comparons : | | int a[100]; | int *b= a; | | int c= b[0];
tu déréfences, est c'est équivalent à *b
| int d(int e[]) { return e[0]; }
Idem.
| int f(int *g) { return *g; } | d(a); d(b); | f(a); f(b); | | Avec | | int A(int); | int (*B)(int)= A; | | int C= B(0);
ceci est l'invention de ANSI C89 comme je l'ai indiqué ci-haut. C'est invalide en C classique.
| | int D(int E(int)) { return E(0); } | int F(int (*G)(int)) { return (*G)(0); } | D(A); D(B); | F(A); F(B); | | Ça me semble assez cohérent :-)
lequel ?
| | (Je sais, je n'ai mis que ce qui est cohérent :-)
-- Gaby
"Michel Michaud" <mm@gdzid.com> writes:
| Dans news:flk77zkzp0.fsf@sel.cmla.ens-cachan.fr, Gabriel Dos
| > S'il y a brisure de symétrie, je ne suis pas certain qu'il soit du
| > côté de C++ (à part retenir la règle de ANSI C pour compatibilité).
| > C++ de ce point de vue là (i.e. pointer sur membre) est 100%
| > cohérent avec C classique et le principe général que si on a un
| > pointeur alors appliquer * permet d'accéder à la valeur pointée.
|
| Je ne suis pas certain, * n'est pas le seul opérateur de
| déréférencement. On peut voir l'appel de fonction comme une sorte
| de déréférencement. Comparons :
|
| int a[100];
| int *b= a;
|
| int c= b[0];
tu déréfences, est c'est équivalent à *b
| int d(int e[]) { return e[0]; }
Idem.
| int f(int *g) { return *g; }
| d(a); d(b);
| f(a); f(b);
|
| Avec
|
| int A(int);
| int (*B)(int)= A;
|
| int C= B(0);
ceci est l'invention de ANSI C89 comme je l'ai indiqué ci-haut. C'est
invalide en C classique.
|
| int D(int E(int)) { return E(0); }
| int F(int (*G)(int)) { return (*G)(0); }
| D(A); D(B);
| F(A); F(B);
|
| Ça me semble assez cohérent :-)
lequel ?
|
| (Je sais, je n'ai mis que ce qui est cohérent :-)
| Dans news:, Gabriel Dos | > S'il y a brisure de symétrie, je ne suis pas certain qu'il soit du | > côté de C++ (à part retenir la règle de ANSI C pour compatibilité). | > C++ de ce point de vue là (i.e. pointer sur membre) est 100% | > cohérent avec C classique et le principe général que si on a un | > pointeur alors appliquer * permet d'accéder à la valeur pointée. | | Je ne suis pas certain, * n'est pas le seul opérateur de | déréférencement. On peut voir l'appel de fonction comme une sorte | de déréférencement. Comparons : | | int a[100]; | int *b= a; | | int c= b[0];
tu déréfences, est c'est équivalent à *b
| int d(int e[]) { return e[0]; }
Idem.
| int f(int *g) { return *g; } | d(a); d(b); | f(a); f(b); | | Avec | | int A(int); | int (*B)(int)= A; | | int C= B(0);
ceci est l'invention de ANSI C89 comme je l'ai indiqué ci-haut. C'est invalide en C classique.
| | int D(int E(int)) { return E(0); } | int F(int (*G)(int)) { return (*G)(0); } | D(A); D(B); | F(A); F(B); | | Ça me semble assez cohérent :-)
lequel ?
| | (Je sais, je n'ai mis que ce qui est cohérent :-)
-- Gaby
Gabriel Dos Reis
Samuel Krempp writes:
| le Tuesday 23 September 2003 23:59, écrivit : | | > "Alain Naigeon" writes: | > | > | "Loïc Joly" a écrit dans le message news: | > | bkqa1r$vrn$ | > | > Fabien LE LEZ wrote: | > | > | > | > > D'ailleurs je trouve le terme "pointeur de/sur une fonction" plutôt | > | > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un | > | > > pointeur (pas convertible en void*) | > | > | > | > std::cout peut se convertir en void*, donc std::cout est un pointeur ! | > | | > | Sophisme. | > | > Nullement. Cela amène simplement Fabien à regarder de plus près son | > assertion initiale. | | Fabien : pas convertible en void* => pas vraiment en pointeur | Loïc : ah, mais alors, comme cout est convertible en void *, | cout est un pointeur | C'est implicitement un raisonnement pour justifier que Fabien a tort. | Mais comme il fait dire à l'implication de Fabien ce qu'elle ne veut pas | dire, le raisonnement est faux. (indépendamment de la vérité ou non de | l'assertion initiale de Fabien)
La question réelle que soulève le message de Loïc est de savoir si « pas convertible en void* » est une caractérisationde « pas vraiment un pointeur ».
Cela va au delà de la simple constatation qu'un raisonnement est faux ou est du sophisme. Dire que c'est un sophisme est un prétexte pour éviter de s'interogger sur l'affirmation de Fabien.
Comme on dit, le sage montre la lune, ...
-- Gaby
Samuel Krempp <krempp@crans.truc.en.trop.ens-cachan.fr> writes:
| le Tuesday 23 September 2003 23:59, dosreis@cmla.ens-cachan.fr écrivit :
|
| > "Alain Naigeon" <anaigeon@free.fr> writes:
| >
| > | "Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message news:
| > | bkqa1r$vrn$1@news-reader4.wanadoo.fr...
| > | > Fabien LE LEZ wrote:
| > | >
| > | > > D'ailleurs je trouve le terme "pointeur de/sur une fonction" plutôt
| > | > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un
| > | > > pointeur (pas convertible en void*)
| > | >
| > | > std::cout peut se convertir en void*, donc std::cout est un pointeur !
| > |
| > | Sophisme.
| >
| > Nullement. Cela amène simplement Fabien à regarder de plus près son
| > assertion initiale.
|
| Fabien : pas convertible en void* => pas vraiment en pointeur
| Loïc : ah, mais alors, comme cout est convertible en void *,
| cout est un pointeur
| C'est implicitement un raisonnement pour justifier que Fabien a tort.
| Mais comme il fait dire à l'implication de Fabien ce qu'elle ne veut pas
| dire, le raisonnement est faux. (indépendamment de la vérité ou non de
| l'assertion initiale de Fabien)
La question réelle que soulève le message de Loïc est de savoir si
« pas convertible en void* » est une caractérisationde « pas vraiment
un pointeur ».
Cela va au delà de la simple constatation qu'un raisonnement est faux
ou est du sophisme. Dire que c'est un sophisme est un prétexte pour
éviter de s'interogger sur l'affirmation de Fabien.
| le Tuesday 23 September 2003 23:59, écrivit : | | > "Alain Naigeon" writes: | > | > | "Loïc Joly" a écrit dans le message news: | > | bkqa1r$vrn$ | > | > Fabien LE LEZ wrote: | > | > | > | > > D'ailleurs je trouve le terme "pointeur de/sur une fonction" plutôt | > | > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un | > | > > pointeur (pas convertible en void*) | > | > | > | > std::cout peut se convertir en void*, donc std::cout est un pointeur ! | > | | > | Sophisme. | > | > Nullement. Cela amène simplement Fabien à regarder de plus près son | > assertion initiale. | | Fabien : pas convertible en void* => pas vraiment en pointeur | Loïc : ah, mais alors, comme cout est convertible en void *, | cout est un pointeur | C'est implicitement un raisonnement pour justifier que Fabien a tort. | Mais comme il fait dire à l'implication de Fabien ce qu'elle ne veut pas | dire, le raisonnement est faux. (indépendamment de la vérité ou non de | l'assertion initiale de Fabien)
La question réelle que soulève le message de Loïc est de savoir si « pas convertible en void* » est une caractérisationde « pas vraiment un pointeur ».
Cela va au delà de la simple constatation qu'un raisonnement est faux ou est du sophisme. Dire que c'est un sophisme est un prétexte pour éviter de s'interogger sur l'affirmation de Fabien.
Comme on dit, le sage montre la lune, ...
-- Gaby
kanze
Gabriel Dos Reis wrote in message news:...
writes:
| typedef double (*PtrAMaFnc)( double ) ;
| double | f( double a, PtrAMaFnc fnc ) | { | return (*fnc)( a ) ; | }
| Mais peut-être tu voulais dire qu'en général, les priorités des | nombreux opérateurs C++ n'est pas facile à tenir en tête. Là, | j'avoue être d'accord. Alors, dans la doute, je mets des | parenthèses. (En l'occurance, ils sont nécessaires ci-dessus. Mais | j'en mets parfois sans savoir s'ils sont nécessaires ou non.)
En l'occurence, elles ne sont pas nécessaires
return fnc(a);
Sans les parenthèses, ce que j'ai écris devient :
return *fnc( a ) ;
Les parenthèses sont bien nécessaires.
Il y a évidemment d'autres façons d'écrire l'expression. Qui pourrait avoir besoin de plus ou de moins de parenthèses. Je préfère la forme qui dit ce qui se passe -- c'est une question de respect pour le lecteur. (Mais il y a d'autres cas, surtout avec des templates, où l'écriture sans * se justifie.)
-- 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 <dosreis@cmla.ens-cachan.fr> wrote in message
news:<flr827r9qu.fsf@sel.cmla.ens-cachan.fr>...
kanze@gabi-soft.fr writes:
| typedef double (*PtrAMaFnc)( double ) ;
| double
| f( double a, PtrAMaFnc fnc )
| {
| return (*fnc)( a ) ;
| }
| Mais peut-être tu voulais dire qu'en général, les priorités des
| nombreux opérateurs C++ n'est pas facile à tenir en tête. Là,
| j'avoue être d'accord. Alors, dans la doute, je mets des
| parenthèses. (En l'occurance, ils sont nécessaires ci-dessus. Mais
| j'en mets parfois sans savoir s'ils sont nécessaires ou non.)
En l'occurence, elles ne sont pas nécessaires
return fnc(a);
Sans les parenthèses, ce que j'ai écris devient :
return *fnc( a ) ;
Les parenthèses sont bien nécessaires.
Il y a évidemment d'autres façons d'écrire l'expression. Qui pourrait
avoir besoin de plus ou de moins de parenthèses. Je préfère la forme qui
dit ce qui se passe -- c'est une question de respect pour le lecteur.
(Mais il y a d'autres cas, surtout avec des templates, où l'écriture
sans * se justifie.)
--
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
| double | f( double a, PtrAMaFnc fnc ) | { | return (*fnc)( a ) ; | }
| Mais peut-être tu voulais dire qu'en général, les priorités des | nombreux opérateurs C++ n'est pas facile à tenir en tête. Là, | j'avoue être d'accord. Alors, dans la doute, je mets des | parenthèses. (En l'occurance, ils sont nécessaires ci-dessus. Mais | j'en mets parfois sans savoir s'ils sont nécessaires ou non.)
En l'occurence, elles ne sont pas nécessaires
return fnc(a);
Sans les parenthèses, ce que j'ai écris devient :
return *fnc( a ) ;
Les parenthèses sont bien nécessaires.
Il y a évidemment d'autres façons d'écrire l'expression. Qui pourrait avoir besoin de plus ou de moins de parenthèses. Je préfère la forme qui dit ce qui se passe -- c'est une question de respect pour le lecteur. (Mais il y a d'autres cas, surtout avec des templates, où l'écriture sans * se justifie.)
-- 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
writes:
| Gabriel Dos Reis wrote in message | news:... | > writes: | | > | typedef double (*PtrAMaFnc)( double ) ; | | > | double | > | f( double a, PtrAMaFnc fnc ) | > | { | > | return (*fnc)( a ) ; | > | } | | > | Mais peut-être tu voulais dire qu'en général, les priorités des | > | nombreux opérateurs C++ n'est pas facile à tenir en tête. Là, | > | j'avoue être d'accord. Alors, dans la doute, je mets des | > | parenthèses. (En l'occurance, ils sont nécessaires ci-dessus. Mais | > | j'en mets parfois sans savoir s'ils sont nécessaires ou non.) | | > En l'occurence, elles ne sont pas nécessaires | | > return fnc(a); | | Sans les parenthèses, ce que j'ai écris devient : | | return *fnc( a ) ; | | Les parenthèses sont bien nécessaires. | | Il y a évidemment d'autres façons d'écrire l'expression. Qui pourrait | avoir besoin de plus ou de moins de parenthèses. Je préfère la forme qui | dit ce qui se passe -- c'est une question de respect pour le lecteur. | (Mais il y a d'autres cas, surtout avec des templates, où l'écriture | sans * se justifie.)
Donc tu ne respectes pas le lecteur dans les templates ?
-- Gaby
kanze@gabi-soft.fr writes:
| Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> wrote in message
| news:<flr827r9qu.fsf@sel.cmla.ens-cachan.fr>...
| > kanze@gabi-soft.fr writes:
|
| > | typedef double (*PtrAMaFnc)( double ) ;
|
| > | double
| > | f( double a, PtrAMaFnc fnc )
| > | {
| > | return (*fnc)( a ) ;
| > | }
|
| > | Mais peut-être tu voulais dire qu'en général, les priorités des
| > | nombreux opérateurs C++ n'est pas facile à tenir en tête. Là,
| > | j'avoue être d'accord. Alors, dans la doute, je mets des
| > | parenthèses. (En l'occurance, ils sont nécessaires ci-dessus. Mais
| > | j'en mets parfois sans savoir s'ils sont nécessaires ou non.)
|
| > En l'occurence, elles ne sont pas nécessaires
|
| > return fnc(a);
|
| Sans les parenthèses, ce que j'ai écris devient :
|
| return *fnc( a ) ;
|
| Les parenthèses sont bien nécessaires.
|
| Il y a évidemment d'autres façons d'écrire l'expression. Qui pourrait
| avoir besoin de plus ou de moins de parenthèses. Je préfère la forme qui
| dit ce qui se passe -- c'est une question de respect pour le lecteur.
| (Mais il y a d'autres cas, surtout avec des templates, où l'écriture
| sans * se justifie.)
Donc tu ne respectes pas le lecteur dans les templates ?
| Gabriel Dos Reis wrote in message | news:... | > writes: | | > | typedef double (*PtrAMaFnc)( double ) ; | | > | double | > | f( double a, PtrAMaFnc fnc ) | > | { | > | return (*fnc)( a ) ; | > | } | | > | Mais peut-être tu voulais dire qu'en général, les priorités des | > | nombreux opérateurs C++ n'est pas facile à tenir en tête. Là, | > | j'avoue être d'accord. Alors, dans la doute, je mets des | > | parenthèses. (En l'occurance, ils sont nécessaires ci-dessus. Mais | > | j'en mets parfois sans savoir s'ils sont nécessaires ou non.) | | > En l'occurence, elles ne sont pas nécessaires | | > return fnc(a); | | Sans les parenthèses, ce que j'ai écris devient : | | return *fnc( a ) ; | | Les parenthèses sont bien nécessaires. | | Il y a évidemment d'autres façons d'écrire l'expression. Qui pourrait | avoir besoin de plus ou de moins de parenthèses. Je préfère la forme qui | dit ce qui se passe -- c'est une question de respect pour le lecteur. | (Mais il y a d'autres cas, surtout avec des templates, où l'écriture | sans * se justifie.)
Donc tu ne respectes pas le lecteur dans les templates ?
-- Gaby
Alain Naigeon
"Gabriel Dos Reis" a écrit dans le message news:
"Alain Naigeon" writes:
| "Loïc Joly" a écrit dans le message news: | bkqa1r$vrn$ | > Fabien LE LEZ wrote: | > | > > D'ailleurs je trouve le terme "pointeur de/sur une fonction" plutôt | > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un | > > pointeur (pas convertible en void*) | > | > std::cout peut se convertir en void*, donc std::cout est un pointeur ! | | Sophisme.
Nullement.
[...] Cela amène simplement Fabien à regarder de plus près son assertion initiale.
Certainement une bonne chose.
Nullement.
| > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un | > > pointeur (pas convertible en void*)
Autrement dit, "convertible en void*" est une condition nécessaire pour être un pointeur - c'est bien ce qu'il dit, non ?
| > std::cout peut se convertir en void*, donc std::cout est un pointeur !
Autrement dit, "peut se convertir en void*" est une condition suffisante, c'est bien ce qu'il dit, non ?
Prendre une condition nécessaire pour suffisante, c'est un sophisme. (ceci dit, nous sommes tous trois mortels, humains, etc)
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Gabriel Dos Reis" <dosreis@cmla.ens-cachan.fr> a écrit dans le message
news: flfzinkvyp.fsf@sel.cmla.ens-cachan.fr...
"Alain Naigeon" <anaigeon@free.fr> writes:
| "Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message news:
| bkqa1r$vrn$1@news-reader4.wanadoo.fr...
| > Fabien LE LEZ wrote:
| >
| > > D'ailleurs je trouve le terme "pointeur de/sur une fonction" plutôt
| > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un
| > > pointeur (pas convertible en void*)
| >
| > std::cout peut se convertir en void*, donc std::cout est un pointeur !
|
| Sophisme.
Nullement.
[...] Cela amène simplement Fabien à regarder de plus près son
assertion initiale.
Certainement une bonne chose.
Nullement.
| > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un
| > > pointeur (pas convertible en void*)
Autrement dit, "convertible en void*" est une condition nécessaire pour
être un pointeur - c'est bien ce qu'il dit, non ?
| > std::cout peut se convertir en void*, donc std::cout est un pointeur !
Autrement dit, "peut se convertir en void*" est une condition suffisante,
c'est bien ce qu'il dit, non ?
Prendre une condition nécessaire pour suffisante, c'est un sophisme.
(ceci dit, nous sommes tous trois mortels, humains, etc)
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
| "Loïc Joly" a écrit dans le message news: | bkqa1r$vrn$ | > Fabien LE LEZ wrote: | > | > > D'ailleurs je trouve le terme "pointeur de/sur une fonction" plutôt | > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un | > > pointeur (pas convertible en void*) | > | > std::cout peut se convertir en void*, donc std::cout est un pointeur ! | | Sophisme.
Nullement.
[...] Cela amène simplement Fabien à regarder de plus près son assertion initiale.
Certainement une bonne chose.
Nullement.
| > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un | > > pointeur (pas convertible en void*)
Autrement dit, "convertible en void*" est une condition nécessaire pour être un pointeur - c'est bien ce qu'il dit, non ?
| > std::cout peut se convertir en void*, donc std::cout est un pointeur !
Autrement dit, "peut se convertir en void*" est une condition suffisante, c'est bien ce qu'il dit, non ?
Prendre une condition nécessaire pour suffisante, c'est un sophisme. (ceci dit, nous sommes tous trois mortels, humains, etc)
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
Gabriel Dos Reis
"Alain Naigeon" writes:
[...]
| > | > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un | > | > > pointeur (pas convertible en void*) | | Autrement dit, "convertible en void*" est une condition nécessaire pour | être un pointeur - c'est bien ce qu'il dit, non ?
oui.
sauf que ce n'est pas une condition nécessaire pour être pointeur.
| > | > std::cout peut se convertir en void*, donc std::cout est un pointeur ! | | Autrement dit, "peut se convertir en void*" est une condition suffisante, | c'est bien ce qu'il dit, non ?
oui
sauf que Loïc ne voulait pas donner une condition suffisante d'être pointeur.
| Prendre une condition nécessaire pour suffisante, c'est un sophisme.
aucune dispute là dessus.
Mais dans le contexte du message de Loïc, je ne crois pas.
| (ceci dit, nous sommes tous trois mortels, humains, etc)
et alors ?
-- Gaby
"Alain Naigeon" <anaigeon@free.fr> writes:
[...]
| > | > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un
| > | > > pointeur (pas convertible en void*)
|
| Autrement dit, "convertible en void*" est une condition nécessaire pour
| être un pointeur - c'est bien ce qu'il dit, non ?
oui.
sauf que ce n'est pas une condition nécessaire pour être pointeur.
| > | > std::cout peut se convertir en void*, donc std::cout est un pointeur !
|
| Autrement dit, "peut se convertir en void*" est une condition suffisante,
| c'est bien ce qu'il dit, non ?
oui
sauf que Loïc ne voulait pas donner une condition suffisante d'être pointeur.
| Prendre une condition nécessaire pour suffisante, c'est un sophisme.
aucune dispute là dessus.
Mais dans le contexte du message de Loïc, je ne crois pas.
| (ceci dit, nous sommes tous trois mortels, humains, etc)
| > | > > mal choisi, puisqu'un pointeur de fonction n'est pas vraiment un | > | > > pointeur (pas convertible en void*) | | Autrement dit, "convertible en void*" est une condition nécessaire pour | être un pointeur - c'est bien ce qu'il dit, non ?
oui.
sauf que ce n'est pas une condition nécessaire pour être pointeur.
| > | > std::cout peut se convertir en void*, donc std::cout est un pointeur ! | | Autrement dit, "peut se convertir en void*" est une condition suffisante, | c'est bien ce qu'il dit, non ?
oui
sauf que Loïc ne voulait pas donner une condition suffisante d'être pointeur.
| Prendre une condition nécessaire pour suffisante, c'est un sophisme.
aucune dispute là dessus.
Mais dans le contexte du message de Loïc, je ne crois pas.
| (ceci dit, nous sommes tous trois mortels, humains, etc)
