methodes statiques, miam miam !

Alain Naigeon

24/05/2004 à 18:26

"drkm" a écrit dans le message news:

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

Oui, bien sûr - je ne saurais passer une fonction, sauf en mode texte :-)

Un objet foncteur

Je ne connais pas cette bête là :-(
(ou alors, est-ce que ça ressemble à la méthode employée pour
écrire un manipulateur de flux avec argument ?)

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Strasbourg, France

Alain Naigeon

24/05/2004 à 18:43

"Gabriel Dos Reis" a écrit dans le message
news:

"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

Ah...? Et le responsable de la sémantique ne serait pas embêté
si l'argument avait, comme valeur par défaut, un pointeur sur
une fonction membre non static ?
Rassure-moi, l'objet n'existe pas encore au moment d'appeler
le constructeur, non ? Parce que moi je n'aime pas écrire une
instruction inutile :-)
Et si l'objet n'existe pas, comment appeler cette fonction
qui en fera partie... plus tard ?

[je scinde mon intervention en 3 questions, car j'aurai plus
de chances de comprendre en lisant 3 réponses elliptiques
plutôt qu'une seule ;-) ]

question super-banco : et si c'est faisable, de quel droit la
syntaxe se mêle-t-elle d'interdire quelque chose qui peut
avoir un sens ?

--

Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - - Strasbourg, France

Alain Naigeon

24/05/2004 à 18:51

"Alain Naigeon" a écrit dans le message news:
40b226da$0$3021$

Et si l'objet n'existe pas, comment appeler cette fonction

++mes_betises ;

car il ne s'agit pas d'appeler la fonction, mais seulement
d'assigner son pointeur à l'argument.

(mais la question super-banco reste donc pertinente)

--

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

24/05/2004 à 19:33

"Alain Naigeon" writes:

| "Gabriel Dos Reis" a écrit dans le message
| news:
| > "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
|
|
| Ah...? Et le responsable de la sémantique ne serait pas embêté
| si l'argument avait, comme valeur par défaut, un pointeur sur
| une fonction membre non static ?

Tu aurais une erreur de type, mais conceptuellement, si la virtualité
n'est pas de la partie, tu peux faire la même chose avec une fonction
membre statique ou non-statique. Autrement dit, il n'y a pas un
différence de fond entre

struct foo {
void bar();
};

et

struct foo {
static void bar(foo&);
};

C'est grosso modo équivalent -- à syntax près, et curiosité comme
foo().bar(), c'est encore une fois, c'est de la syntaxe et non une
différence de fond.

| Rassure-moi, l'objet n'existe pas encore au moment d'appeler
| le constructeur, non ?

Oui, mais la fonction n'est pas créée au moment de la construction de
l'objet. À l'intérieur du constructeur tu es en droit d'appeler la
fonction membre -- alors que techniquement, l'objet n'existe qu'à la
fin de l'exécution du constructeur.

Si tu tiens comptes des fonctions virtuelles, alors les choses
deviennent radicalement différence -- parce qu'en gros une fonction
virtuelle est réellement une propriété de l'objet. Par exemple, à
l'intérieur du constructeur, si tu appelles une fonction virtuelle,
elle fera référence au type connu le plus « en cours ».

En d'autres termes, la différence entre une fonction membre statique
et une fonction membre non-statique ne devient significative que
lorsque la virtualité rentre en jeu.

| Parce que moi je n'aime pas écrire une
| instruction inutile :-)

Je ne comprends pas cette phrase.

| Et si l'objet n'existe pas, comment appeler cette fonction
| qui en fera partie... plus tard ?

Si tu penses que la fonction appartient à l'objet, c'est le genre de
question à laquelle tu arrives -- et comme le posteur originel, tu
penserais que la fonction est créée à chaque création d'un objet, mais
il n'est rien. Par exemple, considère

struct A {
void (A::*f())() { return &A::g; }
void g() { }
};

int main() {
A a;
A b;
assert(a.f() == b.f());
}

| question super-banco : et si c'est faisable, de quel droit la
| syntaxe se mêle-t-elle d'interdire quelque chose qui peut
| avoir un sens ?

Je ne comprends pas cette question.

-- Gaby

"Alain Naigeon" <anaigeon@free.fr> writes:

| "Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message
| news: m34qq6kl49.fsf@uniton.integrable-solutions.net...
| > "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.
| >
| > Là on reste toujours de l'ordre du syntaxique :-)
| >
| > -- Gaby
|
|
| Ah...? Et le responsable de la sémantique ne serait pas embêté
| si l'argument avait, comme valeur par défaut, un pointeur sur
| une fonction membre non static ?

Tu aurais une erreur de type, mais conceptuellement, si la virtualité
n'est pas de la partie, tu peux faire la même chose avec une fonction
membre statique ou non-statique. Autrement dit, il n'y a pas un
différence de fond entre

struct foo {
void bar();
};

et

struct foo {
static void bar(foo&);
};

C'est grosso modo équivalent -- à syntax près, et curiosité comme
foo().bar(), c'est encore une fois, c'est de la syntaxe et non une
différence de fond.

| Rassure-moi, l'objet n'existe pas encore au moment d'appeler
| le constructeur, non ?

Oui, mais la fonction n'est pas créée au moment de la construction de
l'objet. À l'intérieur du constructeur tu es en droit d'appeler la
fonction membre -- alors que techniquement, l'objet n'existe qu'à la
fin de l'exécution du constructeur.

Si tu tiens comptes des fonctions virtuelles, alors les choses
deviennent radicalement différence -- parce qu'en gros une fonction
virtuelle est réellement une propriété de l'objet. Par exemple, à
l'intérieur du constructeur, si tu appelles une fonction virtuelle,
elle fera référence au type connu le plus « en cours ».

En d'autres termes, la différence entre une fonction membre statique
et une fonction membre non-statique ne devient significative que
lorsque la virtualité rentre en jeu.

| Parce que moi je n'aime pas écrire une
| instruction inutile :-)

Je ne comprends pas cette phrase.

| Et si l'objet n'existe pas, comment appeler cette fonction
| qui en fera partie... plus tard ?

Si tu penses que la fonction appartient à l'objet, c'est le genre de
question à laquelle tu arrives -- et comme le posteur originel, tu
penserais que la fonction est créée à chaque création d'un objet, mais
il n'est rien. Par exemple, considère

struct A {
void (A::*f())() { return &A::g; }
void g() { }
};

int main() {
A a;
A b;
assert(a.f() == b.f());
}

| question super-banco : et si c'est faisable, de quel droit la
| syntaxe se mêle-t-elle d'interdire quelque chose qui peut
| avoir un sens ?

Je ne comprends pas cette question.

-- Gaby

Vous avez filtré cet utilisateur ! Consultez son message

"Alain Naigeon" writes:

| "Gabriel Dos Reis" a écrit dans le message
| news:
| > "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
|
|
| Ah...? Et le responsable de la sémantique ne serait pas embêté
| si l'argument avait, comme valeur par défaut, un pointeur sur
| une fonction membre non static ?

Tu aurais une erreur de type, mais conceptuellement, si la virtualité
n'est pas de la partie, tu peux faire la même chose avec une fonction
membre statique ou non-statique. Autrement dit, il n'y a pas un
différence de fond entre

struct foo {
void bar();
};

et

struct foo {
static void bar(foo&);
};

C'est grosso modo équivalent -- à syntax près, et curiosité comme
foo().bar(), c'est encore une fois, c'est de la syntaxe et non une
différence de fond.

| Rassure-moi, l'objet n'existe pas encore au moment d'appeler
| le constructeur, non ?

Oui, mais la fonction n'est pas créée au moment de la construction de
l'objet. À l'intérieur du constructeur tu es en droit d'appeler la
fonction membre -- alors que techniquement, l'objet n'existe qu'à la
fin de l'exécution du constructeur.

Si tu tiens comptes des fonctions virtuelles, alors les choses
deviennent radicalement différence -- parce qu'en gros une fonction
virtuelle est réellement une propriété de l'objet. Par exemple, à
l'intérieur du constructeur, si tu appelles une fonction virtuelle,
elle fera référence au type connu le plus « en cours ».

En d'autres termes, la différence entre une fonction membre statique
et une fonction membre non-statique ne devient significative que
lorsque la virtualité rentre en jeu.

| Parce que moi je n'aime pas écrire une
| instruction inutile :-)

Je ne comprends pas cette phrase.

| Et si l'objet n'existe pas, comment appeler cette fonction
| qui en fera partie... plus tard ?

Si tu penses que la fonction appartient à l'objet, c'est le genre de
question à laquelle tu arrives -- et comme le posteur originel, tu
penserais que la fonction est créée à chaque création d'un objet, mais
il n'est rien. Par exemple, considère

struct A {
void (A::*f())() { return &A::g; }
void g() { }
};

int main() {
A a;
A b;
assert(a.f() == b.f());
}

| question super-banco : et si c'est faisable, de quel droit la
| syntaxe se mêle-t-elle d'interdire quelque chose qui peut
| avoir un sens ?

Je ne comprends pas cette question.

-- Gaby

Horst Kraemer

25/05/2004 à 05:16

On Sat, 22 May 2004 16:01:08 +0200, Anthony Fleury
wrote:

giova wrote:

alors la il faut que quelqu'un me corrige car je risque de dire une
connerie.

qui dit statique dit appartient a la classe et non a l'objet. cad que
sitot la classe défini la methode statique se voit alloué son
emplacement mémoire meme si aucun objet n'a été créé. ca veut aussi dire
que quelque soit le nombre d'objet la fonction statique ne sera
"allouée" qu'une seule fois. Donc gain de place.

En fait, penses tu que pour une méthode non static le code de la méthode
membre sera dupliqué et existera pour chaque objet ?
Si c'est le cas c'est faux. Une méthode membre non static et une méthode
static se distinguent par une chose : l'une connait le pointeur this de la
classe, l'autre non. Dans les deux cas, le code de la fonction n'est
présent qu'une fois dans l'executable, et un appel de fonction normal se
fait. Mais dans le cas d'une fonction non statique, il y a une notion
d'appartenance à une instance de la classe donnée par this, qui fait que
l'on peut acceder à des variables dépendantes de l'instance en cours. (tout
ceci n'est valable que pour les méthode non inline, dans le cas contraire
il n'y a même pas présence du code dans l'executable...).

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.

C'est exagéré ;-)

En principe on peut remplacer toute fonction membre non virtuelle
(sauf des constructeurs et des destructeurs) par une fonction
statique. C.a.d.

struct X
{
int x;
void f(int i) { x=i; }
};

par

struct X
{
int x;
static void s(X* const this_, int i) { this_->x = i; }
};

au lieu de x.f(3) on appelle s(&x,3). (je sais que le vrai 'this'
n'est pas un X * const mais un X * "rvalue" mais ce n'est qu'un
détail sémantique).

En fait sur les système que j'ai vu l'implémentation de f est
identique à celle de s, et x.f(3) est implémenté par s(&x,3). En fait
l'écriture x.f(3) n'est que du "sucre" qui veut dire s(&x,3). Bien
entendu ce sucre s'étend à la syntaxe parce qu'un simple 'x' dans f
correspond à this_->x dans s, mais au niveau de l'implémentation un
accès à x est aussi implémenté par un accès à "this->x" dans f.

--
Horst

On Sat, 22 May 2004 16:01:08 +0200, Anthony Fleury
<fleury_anthony@_hotmail_.com> wrote:

giova wrote:

alors la il faut que quelqu'un me corrige car je risque de dire une
connerie.

qui dit statique dit appartient a la classe et non a l'objet. cad que
sitot la classe défini la methode statique se voit alloué son
emplacement mémoire meme si aucun objet n'a été créé. ca veut aussi dire
que quelque soit le nombre d'objet la fonction statique ne sera
"allouée" qu'une seule fois. Donc gain de place.

En fait, penses tu que pour une méthode non static le code de la méthode
membre sera dupliqué et existera pour chaque objet ?
Si c'est le cas c'est faux. Une méthode membre non static et une méthode
static se distinguent par une chose : l'une connait le pointeur this de la
classe, l'autre non. Dans les deux cas, le code de la fonction n'est
présent qu'une fois dans l'executable, et un appel de fonction normal se
fait. Mais dans le cas d'une fonction non statique, il y a une notion
d'appartenance à une instance de la classe donnée par this, qui fait que
l'on peut acceder à des variables dépendantes de l'instance en cours. (tout
ceci n'est valable que pour les méthode non inline, dans le cas contraire
il n'y a même pas présence du code dans l'executable...).

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.

C'est exagéré ;-)

En principe on peut remplacer toute fonction membre non virtuelle
(sauf des constructeurs et des destructeurs) par une fonction
statique. C.a.d.

struct X
{
int x;
void f(int i) { x=i; }
};

par

struct X
{
int x;
static void s(X* const this_, int i) { this_->x = i; }
};

au lieu de x.f(3) on appelle s(&x,3). (je sais que le vrai 'this'
n'est pas un X * const mais un X * "rvalue" mais ce n'est qu'un
détail sémantique).

En fait sur les système que j'ai vu l'implémentation de f est
identique à celle de s, et x.f(3) est implémenté par s(&x,3). En fait
l'écriture x.f(3) n'est que du "sucre" qui veut dire s(&x,3). Bien
entendu ce sucre s'étend à la syntaxe parce qu'un simple 'x' dans f
correspond à this_->x dans s, mais au niveau de l'implémentation un
accès à x est aussi implémenté par un accès à "this->x" dans f.

--
Horst

Vous avez filtré cet utilisateur ! Consultez son message

On Sat, 22 May 2004 16:01:08 +0200, Anthony Fleury
wrote:

giova wrote:

alors la il faut que quelqu'un me corrige car je risque de dire une
connerie.

qui dit statique dit appartient a la classe et non a l'objet. cad que
sitot la classe défini la methode statique se voit alloué son
emplacement mémoire meme si aucun objet n'a été créé. ca veut aussi dire
que quelque soit le nombre d'objet la fonction statique ne sera
"allouée" qu'une seule fois. Donc gain de place.

En fait, penses tu que pour une méthode non static le code de la méthode
membre sera dupliqué et existera pour chaque objet ?
Si c'est le cas c'est faux. Une méthode membre non static et une méthode
static se distinguent par une chose : l'une connait le pointeur this de la
classe, l'autre non. Dans les deux cas, le code de la fonction n'est
présent qu'une fois dans l'executable, et un appel de fonction normal se
fait. Mais dans le cas d'une fonction non statique, il y a une notion
d'appartenance à une instance de la classe donnée par this, qui fait que
l'on peut acceder à des variables dépendantes de l'instance en cours. (tout
ceci n'est valable que pour les méthode non inline, dans le cas contraire
il n'y a même pas présence du code dans l'executable...).

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.

C'est exagéré ;-)

En principe on peut remplacer toute fonction membre non virtuelle
(sauf des constructeurs et des destructeurs) par une fonction
statique. C.a.d.

struct X
{
int x;
void f(int i) { x=i; }
};

par

struct X
{
int x;
static void s(X* const this_, int i) { this_->x = i; }
};

au lieu de x.f(3) on appelle s(&x,3). (je sais que le vrai 'this'
n'est pas un X * const mais un X * "rvalue" mais ce n'est qu'un
détail sémantique).

En fait sur les système que j'ai vu l'implémentation de f est
identique à celle de s, et x.f(3) est implémenté par s(&x,3). En fait
l'écriture x.f(3) n'est que du "sucre" qui veut dire s(&x,3). Bien
entendu ce sucre s'étend à la syntaxe parce qu'un simple 'x' dans f
correspond à this_->x dans s, mais au niveau de l'implémentation un
accès à x est aussi implémenté par un accès à "this->x" dans f.

--
Horst

methodes statiques, miam miam !

5 réponses

Veuillez sélectionner un problème