Il manque les () à ton FooPtrComparator et un public avant ta fonction dans la classe... Mais ce n'est pas ce que je voulais ajouter à cette discussion quasi close...
Plutôt simplement qu'il n'est pas nécessaire (même si ça peut être utile) de passer par une classe de fonction objet, une simple fonction suffit :
Il manque les () à ton FooPtrComparator et un public avant ta
fonction dans la classe... Mais ce n'est pas ce que je voulais
ajouter à cette discussion quasi close...
Plutôt simplement qu'il n'est pas nécessaire (même si ça peut
être utile) de passer par une classe de fonction objet, une
simple fonction suffit :
Il manque les () à ton FooPtrComparator et un public avant ta fonction dans la classe... Mais ce n'est pas ce que je voulais ajouter à cette discussion quasi close...
Plutôt simplement qu'il n'est pas nécessaire (même si ça peut être utile) de passer par une classe de fonction objet, une simple fonction suffit :
Il manque les () à ton FooPtrComparator et un public avant ta fonction dans la classe... Mais ce n'est pas ce que je voulais ajouter à cette discussion quasi close...
Plutôt simplement qu'il n'est pas nécessaire (même si ça peut être utile) de passer par une classe de fonction objet, une simple fonction suffit :
L'avantage de l'objet-fonction est que l'appel de la fonction peut être "inliné", ce qui n'est probablement pas le cas quand on appelle une fonction indirectement (à travers d'un pointeur). Ceci résulte en un gain de performance qui peut être considérable quand le coût de l'appel de l'opérateur < est faible par rapport à un appel de fonction indirect.
Un autre avantage d'un objet-fonction (bien que non utilisé dans le cas présent) est de permettre de passer de l'état dans des variables membres initialisées par le constructeur.
Falk
Michel Michaud wrote:
Dans le message 41e46194$0$6431$8fcfb975@news.wanadoo.fr,
Il manque les () à ton FooPtrComparator et un public avant ta
fonction dans la classe... Mais ce n'est pas ce que je voulais
ajouter à cette discussion quasi close...
Plutôt simplement qu'il n'est pas nécessaire (même si ça peut
être utile) de passer par une classe de fonction objet, une
simple fonction suffit :
L'avantage de l'objet-fonction est que l'appel de la
fonction peut être "inliné", ce qui n'est probablement
pas le cas quand on appelle une fonction indirectement
(à travers d'un pointeur).
Ceci résulte en un gain de performance qui peut être
considérable quand le coût de l'appel de l'opérateur <
est faible par rapport à un appel de fonction indirect.
Un autre avantage d'un objet-fonction (bien que non
utilisé dans le cas présent) est de permettre de passer
de l'état dans des variables membres initialisées par
le constructeur.
Il manque les () à ton FooPtrComparator et un public avant ta fonction dans la classe... Mais ce n'est pas ce que je voulais ajouter à cette discussion quasi close...
Plutôt simplement qu'il n'est pas nécessaire (même si ça peut être utile) de passer par une classe de fonction objet, une simple fonction suffit :
L'avantage de l'objet-fonction est que l'appel de la fonction peut être "inliné", ce qui n'est probablement pas le cas quand on appelle une fonction indirectement (à travers d'un pointeur). Ceci résulte en un gain de performance qui peut être considérable quand le coût de l'appel de l'opérateur < est faible par rapport à un appel de fonction indirect.
Un autre avantage d'un objet-fonction (bien que non utilisé dans le cas présent) est de permettre de passer de l'état dans des variables membres initialisées par le constructeur.
Falk
kanze
Fabien LE LEZ wrote:
On 11 Jan 2005 23:39:11 GMT, Michael :
struct CompareByIndex
: public std::binary_function<const foo *, const foo *, bool>
Je n'ai jamais bien su si cet héritage sert à quelque chose ou pas. En tout cas, le "public" n'est guère utile.
On peut en discuter sur l'utilité -- si tu veux te servir de tes objets fonctionnels dans une composition avec ceux de la norme, il faut bien que tu définisses first_argument_type, etc., quelque part. (En fait, entre écrire l'héritage en spécifiant les types du template, et écrire les typedef, je ne trouve pas qu'il y a une différence énorme.)
Ce qui est sûr que si tu en hérites, il faut que l'héritage soit public. Sinon, il sert certainement à rien.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 11 Jan 2005 23:39:11 GMT, Michael
<michael_delva.enlever@hotmail.com>:
struct CompareByIndex
: public std::binary_function<const foo *, const foo *, bool>
Je n'ai jamais bien su si cet héritage sert à quelque chose ou
pas. En tout cas, le "public" n'est guère utile.
On peut en discuter sur l'utilité -- si tu veux te servir de tes
objets fonctionnels dans une composition avec ceux de la norme,
il faut bien que tu définisses first_argument_type, etc.,
quelque part. (En fait, entre écrire l'héritage en spécifiant
les types du template, et écrire les typedef, je ne trouve pas
qu'il y a une différence énorme.)
Ce qui est sûr que si tu en hérites, il faut que l'héritage soit
public. Sinon, il sert certainement à rien.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
: public std::binary_function<const foo *, const foo *, bool>
Je n'ai jamais bien su si cet héritage sert à quelque chose ou pas. En tout cas, le "public" n'est guère utile.
On peut en discuter sur l'utilité -- si tu veux te servir de tes objets fonctionnels dans une composition avec ceux de la norme, il faut bien que tu définisses first_argument_type, etc., quelque part. (En fait, entre écrire l'héritage en spécifiant les types du template, et écrire les typedef, je ne trouve pas qu'il y a une différence énorme.)
Ce qui est sûr que si tu en hérites, il faut que l'héritage soit public. Sinon, il sert certainement à rien.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ
On 14 Jan 2005 01:52:06 -0800, :
Ce qui est sûr que si tu en hérites, il faut que l'héritage soit public. Sinon, il sert certainement à rien.
Quand je déclare une classe par "struct", j'estime que tout est public et je n'utilise jamais les mots "public", "protected" ou "private". Si je veut une classe où tout n'est pas public, j'écris "class" et j'explicite.
-- ;-)
On 14 Jan 2005 01:52:06 -0800, kanze@gabi-soft.fr:
Ce qui est sûr que si tu en hérites, il faut que l'héritage soit
public. Sinon, il sert certainement à rien.
Quand je déclare une classe par "struct", j'estime que tout est public
et je n'utilise jamais les mots "public", "protected" ou "private".
Si je veut une classe où tout n'est pas public, j'écris "class" et
j'explicite.
Ce qui est sûr que si tu en hérites, il faut que l'héritage soit public. Sinon, il sert certainement à rien.
Quand je déclare une classe par "struct", j'estime que tout est public et je n'utilise jamais les mots "public", "protected" ou "private". Si je veut une classe où tout n'est pas public, j'écris "class" et j'explicite.
-- ;-)
James Kanze
Fabien LE LEZ wrote:
On 14 Jan 2005 01:52:06 -0800, :
Ce qui est sûr que si tu en hérites, il faut que l'héritage soit public. Sinon, il sert certainement à rien.
Quand je déclare une classe par "struct", j'estime que tout est public et je n'utilise jamais les mots "public", "protected" ou "private". Si je veut une classe où tout n'est pas public, j'écris "class" et j'explicite.
OK. Je n'avais pas rémarqué que c'était struct et non class. (Pas bien régardé.) En fait, c'est pareil chez moi.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 14 Jan 2005 01:52:06 -0800, kanze@gabi-soft.fr:
Ce qui est sûr que si tu en hérites, il faut que l'héritage
soit public. Sinon, il sert certainement à rien.
Quand je déclare une classe par "struct", j'estime que tout est public
et je n'utilise jamais les mots "public", "protected" ou "private".
Si je veut une classe où tout n'est pas public, j'écris "class" et
j'explicite.
OK. Je n'avais pas rémarqué que c'était struct et non class.
(Pas bien régardé.) En fait, c'est pareil chez moi.
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Ce qui est sûr que si tu en hérites, il faut que l'héritage soit public. Sinon, il sert certainement à rien.
Quand je déclare une classe par "struct", j'estime que tout est public et je n'utilise jamais les mots "public", "protected" ou "private". Si je veut une classe où tout n'est pas public, j'écris "class" et j'explicite.
OK. Je n'avais pas rémarqué que c'était struct et non class. (Pas bien régardé.) En fait, c'est pareil chez moi.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Michel Michaud
Dans le message cs838c$s84$,
Michel Michaud wrote:
[...] il n'est pas nécessaire (même si ça peut être utile) de passer par une classe de fonction objet, une simple fonction suffit :
L'avantage de l'objet-fonction est que l'appel de la fonction peut être "inliné", ce qui n'est probablement pas le cas quand on appelle une fonction indirectement (à travers d'un pointeur).
Comme je l'ai dit, ça peut être utile. Ça peut être utile aussi que ce ne soit pas « inliné » :-)
L'important c'est de savoir que les deux techniques sont possibles. Ensuite on peut choisir ce qui convient.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message cs838c$s84$1@s1.news.oleane.net,
Michel Michaud wrote:
[...] il n'est pas nécessaire (même si ça peut
être utile) de passer par une classe de fonction objet, une
simple fonction suffit :
L'avantage de l'objet-fonction est que l'appel de la
fonction peut être "inliné", ce qui n'est probablement
pas le cas quand on appelle une fonction indirectement
(à travers d'un pointeur).
Comme je l'ai dit, ça peut être utile. Ça peut être utile
aussi que ce ne soit pas « inliné » :-)
L'important c'est de savoir que les deux techniques sont
possibles. Ensuite on peut choisir ce qui convient.
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
L'avantage de l'objet-fonction est que l'appel de la fonction peut être "inliné", ce qui n'est probablement pas le cas quand on appelle une fonction indirectement (à travers d'un pointeur).
Comme je l'ai dit, ça peut être utile. Ça peut être utile aussi que ce ne soit pas « inliné » :-)
L'important c'est de savoir que les deux techniques sont possibles. Ensuite on peut choisir ce qui convient.
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/