Généralement, quand tu as un système de callback, tu peux passer un pointeur (ici, this) et un pointeur sur une fonction callback. Ce pointeur sur fonction ne peut pas être un pointeur sur une fonction membre "normale", ça ne peut être qu'une fonction static ou libre.
Bien qu'utiliser une fonction membre statique est la solution idiomatique, il me semble, au problème des callbacks à la C, il me semble avoir lu, ici même, que la norme ne garantit pas cette utilisation. C'est à dire que le déréférencement d'un pointeur vers une fonction membre statique depuis une variable de type pointeur vers une fonction libre, *par ailleurs* de même prototype, ne serait pas garantit de fonctionner comme l'on s'y attend.
Je n'ai pas retrouvé les articles en question. Suis-je victime d'hallucinations, ou est-ce bien le cas ?-)
--drkm
Fabien LE LEZ <gramster@gramster.com> writes:
On Sun, 23 May 2004 10:39:05 +0200, Anthony Fleury
<fleury_anthony@_hotmail_.com> wrote:
class foo {
int x;
public:
static int X(foo& f) { return f.x; }
};
Ceci est légal, mais est ce que ca a un intêret ?
Sous la forme suivante, je m'en sers assez souvent :
Généralement, quand tu as un système de callback, tu peux passer un
pointeur (ici, this) et un pointeur sur une fonction callback. Ce
pointeur sur fonction ne peut pas être un pointeur sur une fonction
membre "normale", ça ne peut être qu'une fonction static ou libre.
Bien qu'utiliser une fonction membre statique est la solution
idiomatique, il me semble, au problème des callbacks à la C, il me
semble avoir lu, ici même, que la norme ne garantit pas cette
utilisation. C'est à dire que le déréférencement d'un pointeur vers
une fonction membre statique depuis une variable de type pointeur vers
une fonction libre, *par ailleurs* de même prototype, ne serait pas
garantit de fonctionner comme l'on s'y attend.
Je n'ai pas retrouvé les articles en question. Suis-je victime
d'hallucinations, ou est-ce bien le cas ?-)
Généralement, quand tu as un système de callback, tu peux passer un pointeur (ici, this) et un pointeur sur une fonction callback. Ce pointeur sur fonction ne peut pas être un pointeur sur une fonction membre "normale", ça ne peut être qu'une fonction static ou libre.
Bien qu'utiliser une fonction membre statique est la solution idiomatique, il me semble, au problème des callbacks à la C, il me semble avoir lu, ici même, que la norme ne garantit pas cette utilisation. C'est à dire que le déréférencement d'un pointeur vers une fonction membre statique depuis une variable de type pointeur vers une fonction libre, *par ailleurs* de même prototype, ne serait pas garantit de fonctionner comme l'on s'y attend.
Je n'ai pas retrouvé les articles en question. Suis-je victime d'hallucinations, ou est-ce bien le cas ?-)
--drkm
Gabriel Dos Reis
drkm writes:
| Bien qu'utiliser une fonction membre statique est la solution | idiomatique, il me semble, au problème des callbacks à la C, il me | semble avoir lu, ici même, que la norme ne garantit pas cette | utilisation. C'est à dire que le déréférencement d'un pointeur vers | une fonction membre statique depuis une variable de type pointeur vers | une fonction libre, *par ailleurs* de même prototype, ne serait pas | garantit de fonctionner comme l'on s'y attend.
Je ne me souviens de personne qui a écrit ça ici (à part ton présent message :-)). Une fonction membre a le même type que si elle avait été non membre. Donc on peut prendre son adresse et la stocker dans une variable de type pointeur vers une fonction non-membre et ça marchera nickel.
Cepdenant, ce que les gens ont dit, c'est que typiquement les callbacks C sont attendus avoir un linkage C. Or une fonction membre a toujours un linkage C++ -- et C++ ne permet pas de spécifier un linkage C pour les membres. Certains compilateurs bugués comme GCC (si si, dans GCC c'est un bug) ne vérifient pas les linkages et laissent passer des choses qui devraient être des erreurs. Donc on a l'impression que ça marche mais il n'y a aucune garantie. Cela induit les gens à écrire du code non portable. D'autres compilateurs comme como donnent une erreur (je crois en mode strict).
| Je n'ai pas retrouvé les articles en question. Suis-je victime | d'hallucinations, ou est-ce bien le cas ?-)
yep :-)
-- Gaby
drkm <usenet.fclcxx@fgeorges.org> writes:
| Bien qu'utiliser une fonction membre statique est la solution
| idiomatique, il me semble, au problème des callbacks à la C, il me
| semble avoir lu, ici même, que la norme ne garantit pas cette
| utilisation. C'est à dire que le déréférencement d'un pointeur vers
| une fonction membre statique depuis une variable de type pointeur vers
| une fonction libre, *par ailleurs* de même prototype, ne serait pas
| garantit de fonctionner comme l'on s'y attend.
Je ne me souviens de personne qui a écrit ça ici (à part ton présent
message :-)). Une fonction membre a le même type que si elle avait
été non membre. Donc on peut prendre son adresse et la stocker dans
une variable de type pointeur vers une fonction non-membre et ça
marchera nickel.
Cepdenant, ce que les gens ont dit, c'est que typiquement les
callbacks C sont attendus avoir un linkage C. Or une fonction membre
a toujours un linkage C++ -- et C++ ne permet pas de spécifier un
linkage C pour les membres.
Certains compilateurs bugués comme GCC (si si, dans GCC c'est un bug)
ne vérifient pas les linkages et laissent passer des choses qui
devraient être des erreurs. Donc on a l'impression que ça marche mais
il n'y a aucune garantie. Cela induit les gens à écrire du code non
portable. D'autres compilateurs comme como donnent une erreur (je
crois en mode strict).
| Je n'ai pas retrouvé les articles en question. Suis-je victime
| d'hallucinations, ou est-ce bien le cas ?-)
| Bien qu'utiliser une fonction membre statique est la solution | idiomatique, il me semble, au problème des callbacks à la C, il me | semble avoir lu, ici même, que la norme ne garantit pas cette | utilisation. C'est à dire que le déréférencement d'un pointeur vers | une fonction membre statique depuis une variable de type pointeur vers | une fonction libre, *par ailleurs* de même prototype, ne serait pas | garantit de fonctionner comme l'on s'y attend.
Je ne me souviens de personne qui a écrit ça ici (à part ton présent message :-)). Une fonction membre a le même type que si elle avait été non membre. Donc on peut prendre son adresse et la stocker dans une variable de type pointeur vers une fonction non-membre et ça marchera nickel.
Cepdenant, ce que les gens ont dit, c'est que typiquement les callbacks C sont attendus avoir un linkage C. Or une fonction membre a toujours un linkage C++ -- et C++ ne permet pas de spécifier un linkage C pour les membres. Certains compilateurs bugués comme GCC (si si, dans GCC c'est un bug) ne vérifient pas les linkages et laissent passer des choses qui devraient être des erreurs. Donc on a l'impression que ça marche mais il n'y a aucune garantie. Cela induit les gens à écrire du code non portable. D'autres compilateurs comme como donnent une erreur (je crois en mode strict).
| Je n'ai pas retrouvé les articles en question. Suis-je victime | d'hallucinations, ou est-ce bien le cas ?-)
yep :-)
-- Gaby
Gabriel Dos Reis
Anthony Fleury writes:
| Gabriel Dos Reis wrote: | | > Anthony Fleury writes: | > | > | Une méthode static ne connaissant pas this, elle ne peut pas acceder à | > | des membres dépendant d'une instance de la classe, donc elle n'a accès à | > | aucun membre non static. | > | > Ce n'est pas exactement ça. Une fonction membre statique a les mêmes | > droit d'accès que les autres fonctions membres (non-statiques), | > seulement elle ne peut pas faire cet accès par this -- parce que ce | > dernier n'y existe pas. Elle peut parfaitement trifouiller les membres | > d'un paramètre dont le type est la classe à laquelle elle appartient. | | Merci de la précision, vu que je ne l'utilise jamais, je n'y pense pas. | Vient alors ma question : | | class foo { | int x; | public: | static int X(foo& f) { return f.x; } | }; | | Ceci est légal, mais est ce que ca a un intêret ?
Oui.
| Quel pourrait être l'intêret de passer un paramètre du type de la classe qui | contient la fonction statique pour en récupérer un membre privé ?
Conceptuellement, la différence entre une fonction membre non-statique et une fonction membre statique n'a d'intérêt que pour les fonctions virtuelles. Autrement, il n'y a pas uen grande différence de fond. Certaines choses sont plus faciles à faire avec une fonction membre statique que sans. Quelqu'un a donné l'exemple de callback.
| Je demande ca car les seules fois où j'ai écrit le mot static dans une | classe, je me referais à des membres static uniquement et gardais cette | idée : "Un membre static est indépendant de toute instanciation de la | classe"
Le fait d'être indépendant de toute instantiation d'une classe n'implique pas qu'on n'accepte pas les paramètres de cette classe :-)
Il faut bien s'entendre sur la phrase « Un membre static est indépendant de toute instanciation de la classe ».
-- Gaby
Anthony Fleury <fleury_anthony@_hotmail_.com> writes:
| Gabriel Dos Reis wrote:
|
| > Anthony Fleury <fleury_anthony@_hotmail_.com> writes:
| >
| > | Une méthode static ne connaissant pas this, elle ne peut pas acceder à
| > | des membres dépendant d'une instance de la classe, donc elle n'a accès à
| > | aucun membre non static.
| >
| > Ce n'est pas exactement ça. Une fonction membre statique a les mêmes
| > droit d'accès que les autres fonctions membres (non-statiques),
| > seulement elle ne peut pas faire cet accès par this -- parce que ce
| > dernier n'y existe pas. Elle peut parfaitement trifouiller les membres
| > d'un paramètre dont le type est la classe à laquelle elle appartient.
|
| Merci de la précision, vu que je ne l'utilise jamais, je n'y pense pas.
| Vient alors ma question :
|
| class foo {
| int x;
| public:
| static int X(foo& f) { return f.x; }
| };
|
| Ceci est légal, mais est ce que ca a un intêret ?
Oui.
| Quel pourrait être l'intêret de passer un paramètre du type de la classe qui
| contient la fonction statique pour en récupérer un membre privé ?
Conceptuellement, la différence entre une fonction membre non-statique
et une fonction membre statique n'a d'intérêt que pour les fonctions
virtuelles. Autrement, il n'y a pas uen grande différence de fond.
Certaines choses sont plus faciles à faire avec une fonction membre
statique que sans. Quelqu'un a donné l'exemple de callback.
| Je demande ca car les seules fois où j'ai écrit le mot static dans une
| classe, je me referais à des membres static uniquement et gardais cette
| idée : "Un membre static est indépendant de toute instanciation de la
| classe"
Le fait d'être indépendant de toute instantiation d'une classe
n'implique pas qu'on n'accepte pas les paramètres de cette classe :-)
Il faut bien s'entendre sur la phrase « Un membre static est
indépendant de toute instanciation de la classe ».
| Gabriel Dos Reis wrote: | | > Anthony Fleury writes: | > | > | Une méthode static ne connaissant pas this, elle ne peut pas acceder à | > | des membres dépendant d'une instance de la classe, donc elle n'a accès à | > | aucun membre non static. | > | > Ce n'est pas exactement ça. Une fonction membre statique a les mêmes | > droit d'accès que les autres fonctions membres (non-statiques), | > seulement elle ne peut pas faire cet accès par this -- parce que ce | > dernier n'y existe pas. Elle peut parfaitement trifouiller les membres | > d'un paramètre dont le type est la classe à laquelle elle appartient. | | Merci de la précision, vu que je ne l'utilise jamais, je n'y pense pas. | Vient alors ma question : | | class foo { | int x; | public: | static int X(foo& f) { return f.x; } | }; | | Ceci est légal, mais est ce que ca a un intêret ?
Oui.
| Quel pourrait être l'intêret de passer un paramètre du type de la classe qui | contient la fonction statique pour en récupérer un membre privé ?
Conceptuellement, la différence entre une fonction membre non-statique et une fonction membre statique n'a d'intérêt que pour les fonctions virtuelles. Autrement, il n'y a pas uen grande différence de fond. Certaines choses sont plus faciles à faire avec une fonction membre statique que sans. Quelqu'un a donné l'exemple de callback.
| Je demande ca car les seules fois où j'ai écrit le mot static dans une | classe, je me referais à des membres static uniquement et gardais cette | idée : "Un membre static est indépendant de toute instanciation de la | classe"
Le fait d'être indépendant de toute instantiation d'une classe n'implique pas qu'on n'accepte pas les paramètres de cette classe :-)
Il faut bien s'entendre sur la phrase « Un membre static est indépendant de toute instanciation de la classe ».
-- Gaby
Patrick Mézard
Bien qu'utiliser une fonction membre statique est la solution idiomatique, il me semble, au problème des callbacks à la C, il me semble avoir lu, ici même, que la norme ne garantit pas cette utilisation. C'est à dire que le déréférencement d'un pointeur vers une fonction membre statique depuis une variable de type pointeur vers une fonction libre, *par ailleurs* de même prototype, ne serait pas garantit de fonctionner comme l'on s'y attend.
Je n'ai pas retrouvé les articles en question. Suis-je victime d'hallucinations, ou est-ce bien le cas ?-)
Stroustrup 3ed (française...), §15.5 :
" Un membre statique n'est pas associé à un objet en particulier. Le pointeur d'un membre statique est donc simplement un pointeur ordinaire. Par exemple :
class Task { // ... static void schedule(); };
void (*p)() = &Task::schedule; //ok void (Task::* pm)() = &Task::schedule; //erreur: pointeur ordinaire affecté à un pointeur de membre "
Ca vaut pas exactement une incantation obscure de la norme mais c'est déjà un peu rassurant non ?
Patrick Mézard
Bien qu'utiliser une fonction membre statique est la solution
idiomatique, il me semble, au problème des callbacks à la C, il me
semble avoir lu, ici même, que la norme ne garantit pas cette
utilisation. C'est à dire que le déréférencement d'un pointeur vers
une fonction membre statique depuis une variable de type pointeur vers
une fonction libre, *par ailleurs* de même prototype, ne serait pas
garantit de fonctionner comme l'on s'y attend.
Je n'ai pas retrouvé les articles en question. Suis-je victime
d'hallucinations, ou est-ce bien le cas ?-)
Stroustrup 3ed (française...), §15.5 :
"
Un membre statique n'est pas associé à un objet en particulier. Le
pointeur d'un membre statique est donc simplement un pointeur ordinaire.
Par exemple :
class Task {
// ...
static void schedule();
};
void (*p)() = &Task::schedule; //ok
void (Task::* pm)() = &Task::schedule; //erreur: pointeur ordinaire
affecté à un pointeur de membre
"
Ca vaut pas exactement une incantation obscure de la norme mais c'est
déjà un peu rassurant non ?
Bien qu'utiliser une fonction membre statique est la solution idiomatique, il me semble, au problème des callbacks à la C, il me semble avoir lu, ici même, que la norme ne garantit pas cette utilisation. C'est à dire que le déréférencement d'un pointeur vers une fonction membre statique depuis une variable de type pointeur vers une fonction libre, *par ailleurs* de même prototype, ne serait pas garantit de fonctionner comme l'on s'y attend.
Je n'ai pas retrouvé les articles en question. Suis-je victime d'hallucinations, ou est-ce bien le cas ?-)
Stroustrup 3ed (française...), §15.5 :
" Un membre statique n'est pas associé à un objet en particulier. Le pointeur d'un membre statique est donc simplement un pointeur ordinaire. Par exemple :
class Task { // ... static void schedule(); };
void (*p)() = &Task::schedule; //ok void (Task::* pm)() = &Task::schedule; //erreur: pointeur ordinaire affecté à un pointeur de membre "
Ca vaut pas exactement une incantation obscure de la norme mais c'est déjà un peu rassurant non ?
Patrick Mézard
Franck Branjonneau
drkm écrivait:
Bien qu'utiliser une fonction membre statique est la solution idiomatique, il me semble, au problème des callbacks à la C, il me semble avoir lu, ici même, que la norme ne garantit pas cette utilisation. C'est à dire que le déréférencement d'un pointeur vers une fonction membre statique depuis une variable de type pointeur vers une fonction libre, *par ailleurs* de même prototype, ne serait pas garantit de fonctionner comme l'on s'y attend.
Je n'ai pas retrouvé les articles en question. Suis-je victime d'hallucinations, ou est-ce bien le cas ?-)
Autant que je sache un pointeur sur fonction membre statique est un pointeur sur fonction. Cependant il ne peut être utilisé comme paramètre d'une fonction C "pure". -- Franck Branjonneau
drkm <usenet.fclcxx@fgeorges.org> écrivait:
Bien qu'utiliser une fonction membre statique est la solution
idiomatique, il me semble, au problème des callbacks à la C, il me
semble avoir lu, ici même, que la norme ne garantit pas cette
utilisation. C'est à dire que le déréférencement d'un pointeur vers
une fonction membre statique depuis une variable de type pointeur vers
une fonction libre, *par ailleurs* de même prototype, ne serait pas
garantit de fonctionner comme l'on s'y attend.
Je n'ai pas retrouvé les articles en question. Suis-je victime
d'hallucinations, ou est-ce bien le cas ?-)
Autant que je sache un pointeur sur fonction membre statique est un
pointeur sur fonction. Cependant il ne peut être utilisé comme
paramètre d'une fonction C "pure".
--
Franck Branjonneau <fasbjx@free.fr>
Bien qu'utiliser une fonction membre statique est la solution idiomatique, il me semble, au problème des callbacks à la C, il me semble avoir lu, ici même, que la norme ne garantit pas cette utilisation. C'est à dire que le déréférencement d'un pointeur vers une fonction membre statique depuis une variable de type pointeur vers une fonction libre, *par ailleurs* de même prototype, ne serait pas garantit de fonctionner comme l'on s'y attend.
Je n'ai pas retrouvé les articles en question. Suis-je victime d'hallucinations, ou est-ce bien le cas ?-)
Autant que je sache un pointeur sur fonction membre statique est un pointeur sur fonction. Cependant il ne peut être utilisé comme paramètre d'une fonction C "pure". -- Franck Branjonneau
James Kanze
Franck Branjonneau writes:
|> drkm écrivait:
|> > Bien qu'utiliser une fonction membre statique est la solution |> > idiomatique, il me semble, au problème des callbacks à la C, |> > il me semble avoir lu, ici même, que la norme ne garantit pas |> > cette utilisation. C'est à dire que le déréférencement |> > d'un pointeur vers une fonction membre statique depuis une |> > variable de type pointeur vers une fonction libre, *par ailleurs* |> > de même prototype, ne serait pas garantit de fonctionner comme |> > l'on s'y attend.
|> > Je n'ai pas retrouvé les articles en question. Suis-je |> > victime d'hallucinations, ou est-ce bien le cas ?-)
|> Autant que je sache un pointeur sur fonction membre statique est un |> pointeur sur fonction. Cependant il ne peut être utilisé comme |> paramètre d'une fonction C "pure".
Tout à fait. Une fonction C pure ne peut prendre que des fonctions avec « extern "C" ». Or qu'une fonction member, même statique, ne peut pas être « extern "C" ».
-- James Kanze 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
Franck Branjonneau <fasbjx@free.fr> writes:
|> drkm <usenet.fclcxx@fgeorges.org> écrivait:
|> > Bien qu'utiliser une fonction membre statique est la solution
|> > idiomatique, il me semble, au problème des callbacks à la C,
|> > il me semble avoir lu, ici même, que la norme ne garantit pas
|> > cette utilisation. C'est à dire que le déréférencement
|> > d'un pointeur vers une fonction membre statique depuis une
|> > variable de type pointeur vers une fonction libre, *par ailleurs*
|> > de même prototype, ne serait pas garantit de fonctionner comme
|> > l'on s'y attend.
|> > Je n'ai pas retrouvé les articles en question. Suis-je
|> > victime d'hallucinations, ou est-ce bien le cas ?-)
|> Autant que je sache un pointeur sur fonction membre statique est un
|> pointeur sur fonction. Cependant il ne peut être utilisé comme
|> paramètre d'une fonction C "pure".
Tout à fait. Une fonction C pure ne peut prendre que des fonctions
avec « extern "C" ». Or qu'une fonction member, même statique,
ne peut pas être « extern "C" ».
--
James Kanze
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
|> > Bien qu'utiliser une fonction membre statique est la solution |> > idiomatique, il me semble, au problème des callbacks à la C, |> > il me semble avoir lu, ici même, que la norme ne garantit pas |> > cette utilisation. C'est à dire que le déréférencement |> > d'un pointeur vers une fonction membre statique depuis une |> > variable de type pointeur vers une fonction libre, *par ailleurs* |> > de même prototype, ne serait pas garantit de fonctionner comme |> > l'on s'y attend.
|> > Je n'ai pas retrouvé les articles en question. Suis-je |> > victime d'hallucinations, ou est-ce bien le cas ?-)
|> Autant que je sache un pointeur sur fonction membre statique est un |> pointeur sur fonction. Cependant il ne peut être utilisé comme |> paramètre d'une fonction C "pure".
Tout à fait. Une fonction C pure ne peut prendre que des fonctions avec « extern "C" ». Or qu'une fonction member, même statique, ne peut pas être « extern "C" ».
-- James Kanze 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
Michel Michaud
Dans news:, James
Franck Branjonneau writes:
Autant que je sache un pointeur sur fonction membre statique est un pointeur sur fonction. Cependant il ne peut être utilisé comme paramètre d'une fonction C "pure".
Tout à fait. Une fonction C pure ne peut prendre que des fonctions avec « extern "C" ». Or qu'une fonction member, même statique, ne peut pas être « extern "C" ».
Mais il est facile de faire une fonction libre extern C qui appelle la fonction static, si besoin est d'une telle fonction (pour travailler sur des objets de cette classe par exemple).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:86fz9qn62b.fsf@alex.gabi-soft.fr, James
Franck Branjonneau <fasbjx@free.fr> writes:
Autant que je sache un pointeur sur fonction membre statique
est un pointeur sur fonction. Cependant il ne peut être
utilisé comme paramètre d'une fonction C "pure".
Tout à fait. Une fonction C pure ne peut prendre que des
fonctions avec « extern "C" ». Or qu'une fonction member, même
statique,
ne peut pas être « extern "C" ».
Mais il est facile de faire une fonction libre extern C qui
appelle la fonction static, si besoin est d'une telle fonction
(pour travailler sur des objets de cette classe par exemple).
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Autant que je sache un pointeur sur fonction membre statique est un pointeur sur fonction. Cependant il ne peut être utilisé comme paramètre d'une fonction C "pure".
Tout à fait. Une fonction C pure ne peut prendre que des fonctions avec « extern "C" ». Or qu'une fonction member, même statique, ne peut pas être « extern "C" ».
Mais il est facile de faire une fonction libre extern C qui appelle la fonction static, si besoin est d'une telle fonction (pour travailler sur des objets de cette classe par exemple).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Alain Naigeon
"Gabriel Dos Reis" a écrit dans le message news:
Conceptuellement, la différence entre une fonction membre non-statique et une fonction membre statique n'a d'intérêt que pour les fonctions virtuelles.
Ah...? Un jour j'ai fait une classe de hashtable. Le constructeur recevait en argument une fonction de hachage, ayant une valeur par défaut, c'est à dire une fonction définie dans la classe. Son type était évidemment static, en plus cela permettait de passer d'autres fonctions non membres.
--
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" <gdr@integrable-solutions.net> a écrit dans le message
news: m3ekpbm0nj.fsf@uniton.integrable-solutions.net...
Conceptuellement, la différence entre une fonction membre non-statique
et une fonction membre statique n'a d'intérêt que pour les fonctions
virtuelles.
Ah...? Un jour j'ai fait une classe de hashtable. Le constructeur
recevait en argument une fonction de hachage, ayant une
valeur par défaut, c'est à dire une fonction définie dans la
classe. Son type était évidemment static, en plus cela
permettait de passer d'autres fonctions non membres.
--
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
Conceptuellement, la différence entre une fonction membre non-statique et une fonction membre statique n'a d'intérêt que pour les fonctions virtuelles.
Ah...? Un jour j'ai fait une classe de hashtable. Le constructeur recevait en argument une fonction de hachage, ayant une valeur par défaut, c'est à dire une fonction définie dans la classe. Son type était évidemment static, en plus cela permettait de passer d'autres fonctions non membres.
--
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:
| "Gabriel Dos Reis" a écrit dans le message | news: | | > Conceptuellement, la différence entre une fonction membre non-statique | > et une fonction membre statique n'a d'intérêt que pour les fonctions | > virtuelles. | | Ah...?
POui.
| Un jour j'ai fait une classe de hashtable. Le constructeur | recevait en argument une fonction de hachage, ayant une | valeur par défaut, c'est à dire une fonction définie dans la | classe. Son type était évidemment static, en plus cela | permettait de passer d'autres fonctions non membres.
Là on reste toujours de l'ordre du syntaxique :-)
-- Gaby
"Alain Naigeon" <anaigeon@free.fr> writes:
| "Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message
| news: m3ekpbm0nj.fsf@uniton.integrable-solutions.net...
|
| > Conceptuellement, la différence entre une fonction membre non-statique
| > et une fonction membre statique n'a d'intérêt que pour les fonctions
| > virtuelles.
|
| Ah...?
POui.
| Un jour j'ai fait une classe de hashtable. Le constructeur
| recevait en argument une fonction de hachage, ayant une
| valeur par défaut, c'est à dire une fonction définie dans la
| classe. Son type était évidemment static, en plus cela
| permettait de passer d'autres fonctions non membres.
| "Gabriel Dos Reis" a écrit dans le message | news: | | > Conceptuellement, la différence entre une fonction membre non-statique | > et une fonction membre statique n'a d'intérêt que pour les fonctions | > virtuelles. | | Ah...?
POui.
| Un jour j'ai fait une classe de hashtable. Le constructeur | recevait en argument une fonction de hachage, ayant une | valeur par défaut, c'est à dire une fonction définie dans la | classe. Son type était évidemment static, en plus cela | permettait de passer d'autres fonctions non membres.
Là on reste toujours de l'ordre du syntaxique :-)
-- Gaby
drkm
"Alain Naigeon" writes:
Ah...? Un jour j'ai fait une classe de hashtable. Le constructeur recevait en argument une fonction de hachage, ayant une valeur par défaut, c'est à dire une fonction définie dans la classe. Son type était évidemment static, en plus cela permettait de passer d'autres fonctions non membres.
Quand tu dis que le constructeur recevait une fonction de hachage, tu parles d'un pointeur vers fonction ? Un objet foncteur t'aurait permis d'accepter des fonctions libres, membres, membres statiques, utiliser la virtualité, etc.
--drkm
"Alain Naigeon" <anaigeon@free.fr> writes:
Ah...? Un jour j'ai fait une classe de hashtable. Le constructeur
recevait en argument une fonction de hachage, ayant une
valeur par défaut, c'est à dire une fonction définie dans la
classe. Son type était évidemment static, en plus cela
permettait de passer d'autres fonctions non membres.
Quand tu dis que le constructeur recevait une fonction de hachage,
tu parles d'un pointeur vers fonction ? Un objet foncteur t'aurait
permis d'accepter des fonctions libres, membres, membres statiques,
utiliser la virtualité, etc.
Ah...? Un jour j'ai fait une classe de hashtable. Le constructeur recevait en argument une fonction de hachage, ayant une valeur par défaut, c'est à dire une fonction définie dans la classe. Son type était évidemment static, en plus cela permettait de passer d'autres fonctions non membres.
Quand tu dis que le constructeur recevait une fonction de hachage, tu parles d'un pointeur vers fonction ? Un objet foncteur t'aurait permis d'accepter des fonctions libres, membres, membres statiques, utiliser la virtualité, etc.
