je m interroge sur la vitesse d execution entre une comparaison et un
pointeur de methode.
j ai une class dont une methode peut changer de comportement au cours de
la vie du process, mais cela rarement.
je me demandais si je devais avoir une methode unique avec un bloc
if/else ou alors un pointeur de methode sette a la methode qui va bien.
j ai donc ecrit deux petits programmes de test, et la solution if/else
est /visiblement/ plus rapide.
et donc je me demandais:
- est ce que mon test est pertinent?
- pourquoi une telle difference de temps?
les prog ont ete compile sous un linux 2.6 avec g++ 3.3.5
merci,
def.hh
------
#ifndef DEF_HH
# define DEF_HH
#include <stdlib.h>
#define MAX_LOOP 1000000000
class Test;
typedef int (Test::*behavior_t)(void);
class Test
{
public:
Test() :
_test(true)
{
}
int behavior1(void)
{
return 0;
}
int behavior2()
{
return 0;
}
Quelqu'un a-t-il déjà vu une explication du principe des « méthodes » où ce terme semble justifié adéquatement ?
Certainement. J'utilise le mot tout le temps. La méthode que je préfère, c'est d'utiliser un outil pour créer les diagrammes UML avant de commencer le codage. De toute façon, c'est une très mauvaise méthode de s'installer davant le claveir, et de commencer à taper du code sans d'abord avoir au moins refléchi sur ce que ce code doit faire.
En somme, on se sert des méthodes pour savoir si une fonction membre doit être virtuelle ou non.
-- James Kanze mailto: 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 wrote:
Dans le message h4k0e1djrq3dndgj2b8a0r907hjgc2qosc@4ax.com,
Quelqu'un a-t-il déjà vu une explication du principe des «
méthodes » où ce terme semble justifié adéquatement ?
Certainement. J'utilise le mot tout le temps. La méthode que je
préfère, c'est d'utiliser un outil pour créer les diagrammes UML
avant de commencer le codage. De toute façon, c'est une très
mauvaise méthode de s'installer davant le claveir, et de
commencer à taper du code sans d'abord avoir au moins refléchi
sur ce que ce code doit faire.
En somme, on se sert des méthodes pour savoir si une fonction
membre doit être virtuelle ou non.
--
James Kanze mailto: james.kanze@free.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
Quelqu'un a-t-il déjà vu une explication du principe des « méthodes » où ce terme semble justifié adéquatement ?
Certainement. J'utilise le mot tout le temps. La méthode que je préfère, c'est d'utiliser un outil pour créer les diagrammes UML avant de commencer le codage. De toute façon, c'est une très mauvaise méthode de s'installer davant le claveir, et de commencer à taper du code sans d'abord avoir au moins refléchi sur ce que ce code doit faire.
En somme, on se sert des méthodes pour savoir si une fonction membre doit être virtuelle ou non.
-- James Kanze mailto: 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
James Kanze
Laurent Deniau wrote:
Guillaume Desticourt wrote:
je m interroge sur la vitesse d execution entre une comparaison et un pointeur de methode.
Juste pour info, l'implementation fait probablement elle-meme un test sur le pointeur pour savoir s'il sagit d'un pointeur de fonction membre ou de methode.
Pour revenir à ce que tu dis, suite à la dérivation sur la vocabulaire :
Quand le compilateur génère un appel à travers un pointeur à une fonction membre, il faut bien qu'il traite correctement les deux cas : que la fonction designée est virtuelle, et qu'il ne l'est pas. Dans le cas d'un appel non virtuel, le comportement est à peu près pareil à l'appel d'une fonction non membre à traver un pointeur, et le compilateur a besoin de l'adresse de la fonction. Dans le cas d'un appel virtuel, le compilateur doit chercher l'adresse de la fonction à appeler dans le vtbl, et ce qu'il lui faut dans le pointeur, c'est l'indication où chercher les informations dans le vtbl. Il lui faut aussi une facteur de correction sur l'adresse de l'objet, puisqu'il le pointeur peut contenir l'adresse d'une fonction dans une classe de base.
Les premiers compilateurs implémentaient réelement une structure avec ces informations, et avec une valeur spécial (du genre -1) comme indice dans le vtbl pour signaler que la fonction n'était pas virtuelle. Et lors de l'appel, ils généraient du code pour tester cette valeur, et pour traiter les deux cas correctement. (Voir la section 8.1.2c de l'ARM, par exemple.)
Si le compilateur voit la définition de la classe, un certain nombre d'optimisations sont immédiatement possibles : s'il voit qu'il n'y a pas de function virtuelle, ni de classe de base, par exemple, il peut effectuer le saut indirect immediatement, en ignorant les champs inutiles. Au moins un compilateur (VC++) va plus loins, et utilise une structure de données simplifiée. Ce qui pose des problèmes si le pointeur sert aussi dans une autre unité de compilation, où il n'y a qu'une déclaration, mais pas de définition de la classe.
Enfin, la plupart des compilateurs aujourd'hui, je crois, utilise une technique de trampoline : le pointeur à la fonction membre n'est réelement qu'un pointeur à une fonction. S'il n'y a pas de correction à faire sur l'adresse de l'objet, et la fonction n'est pas virtuelle, il contient l'adresse réele de la fonction. S'il faut une correction, ou si la fonction est virtuelle, on y met l'adresse d'un bout de code « trampoline », qui fait la correction, si nécessaire, et puis fait l'appel virtuel ou direct. Si sizeof( void (Classe::*pfm)() ) = sizeof( void (*)() ), tu peux être sûr que le compilateur utilise cette technique, au moins si Classe a des fonctions virtuelles.
-- James Kanze mailto: 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
Laurent Deniau wrote:
Guillaume Desticourt wrote:
je m interroge sur la vitesse d execution entre une
comparaison et un pointeur de methode.
Juste pour info, l'implementation fait probablement elle-meme
un test sur le pointeur pour savoir s'il sagit d'un pointeur
de fonction membre ou de methode.
Pour revenir à ce que tu dis, suite à la dérivation sur la
vocabulaire :
Quand le compilateur génère un appel à travers un pointeur à une
fonction membre, il faut bien qu'il traite correctement les deux
cas : que la fonction designée est virtuelle, et qu'il ne l'est
pas. Dans le cas d'un appel non virtuel, le comportement est à
peu près pareil à l'appel d'une fonction non membre à traver un
pointeur, et le compilateur a besoin de l'adresse de la
fonction. Dans le cas d'un appel virtuel, le compilateur doit
chercher l'adresse de la fonction à appeler dans le vtbl, et ce
qu'il lui faut dans le pointeur, c'est l'indication où chercher
les informations dans le vtbl. Il lui faut aussi une facteur de
correction sur l'adresse de l'objet, puisqu'il le pointeur peut
contenir l'adresse d'une fonction dans une classe de base.
Les premiers compilateurs implémentaient réelement une structure
avec ces informations, et avec une valeur spécial (du genre -1)
comme indice dans le vtbl pour signaler que la fonction n'était
pas virtuelle. Et lors de l'appel, ils généraient du code pour
tester cette valeur, et pour traiter les deux cas correctement.
(Voir la section 8.1.2c de l'ARM, par exemple.)
Si le compilateur voit la définition de la classe, un certain
nombre d'optimisations sont immédiatement possibles : s'il voit
qu'il n'y a pas de function virtuelle, ni de classe de base, par
exemple, il peut effectuer le saut indirect immediatement, en
ignorant les champs inutiles. Au moins un compilateur (VC++) va
plus loins, et utilise une structure de données simplifiée. Ce
qui pose des problèmes si le pointeur sert aussi dans une autre
unité de compilation, où il n'y a qu'une déclaration, mais pas
de définition de la classe.
Enfin, la plupart des compilateurs aujourd'hui, je crois,
utilise une technique de trampoline : le pointeur à la fonction
membre n'est réelement qu'un pointeur à une fonction. S'il n'y a
pas de correction à faire sur l'adresse de l'objet, et la
fonction n'est pas virtuelle, il contient l'adresse réele de la
fonction. S'il faut une correction, ou si la fonction est
virtuelle, on y met l'adresse d'un bout de code « trampoline »,
qui fait la correction, si nécessaire, et puis fait l'appel
virtuel ou direct. Si sizeof( void (Classe::*pfm)() ) = sizeof( void (*)() ), tu peux être sûr que le compilateur
utilise cette technique, au moins si Classe a des fonctions
virtuelles.
--
James Kanze mailto: james.kanze@free.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
je m interroge sur la vitesse d execution entre une comparaison et un pointeur de methode.
Juste pour info, l'implementation fait probablement elle-meme un test sur le pointeur pour savoir s'il sagit d'un pointeur de fonction membre ou de methode.
Pour revenir à ce que tu dis, suite à la dérivation sur la vocabulaire :
Quand le compilateur génère un appel à travers un pointeur à une fonction membre, il faut bien qu'il traite correctement les deux cas : que la fonction designée est virtuelle, et qu'il ne l'est pas. Dans le cas d'un appel non virtuel, le comportement est à peu près pareil à l'appel d'une fonction non membre à traver un pointeur, et le compilateur a besoin de l'adresse de la fonction. Dans le cas d'un appel virtuel, le compilateur doit chercher l'adresse de la fonction à appeler dans le vtbl, et ce qu'il lui faut dans le pointeur, c'est l'indication où chercher les informations dans le vtbl. Il lui faut aussi une facteur de correction sur l'adresse de l'objet, puisqu'il le pointeur peut contenir l'adresse d'une fonction dans une classe de base.
Les premiers compilateurs implémentaient réelement une structure avec ces informations, et avec une valeur spécial (du genre -1) comme indice dans le vtbl pour signaler que la fonction n'était pas virtuelle. Et lors de l'appel, ils généraient du code pour tester cette valeur, et pour traiter les deux cas correctement. (Voir la section 8.1.2c de l'ARM, par exemple.)
Si le compilateur voit la définition de la classe, un certain nombre d'optimisations sont immédiatement possibles : s'il voit qu'il n'y a pas de function virtuelle, ni de classe de base, par exemple, il peut effectuer le saut indirect immediatement, en ignorant les champs inutiles. Au moins un compilateur (VC++) va plus loins, et utilise une structure de données simplifiée. Ce qui pose des problèmes si le pointeur sert aussi dans une autre unité de compilation, où il n'y a qu'une déclaration, mais pas de définition de la classe.
Enfin, la plupart des compilateurs aujourd'hui, je crois, utilise une technique de trampoline : le pointeur à la fonction membre n'est réelement qu'un pointeur à une fonction. S'il n'y a pas de correction à faire sur l'adresse de l'objet, et la fonction n'est pas virtuelle, il contient l'adresse réele de la fonction. S'il faut une correction, ou si la fonction est virtuelle, on y met l'adresse d'un bout de code « trampoline », qui fait la correction, si nécessaire, et puis fait l'appel virtuel ou direct. Si sizeof( void (Classe::*pfm)() ) = sizeof( void (*)() ), tu peux être sûr que le compilateur utilise cette technique, au moins si Classe a des fonctions virtuelles.
-- James Kanze mailto: 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
Laurent Deniau
Michel Michaud wrote:
Dans le message ,
"Michel Michaud" writes:
Quelqu'un a-t-il déjà vu une explication du principe des « méthodes » où ce terme semble justifié adéquatement ?
Si un gugus s'amène sur ce forum et s'entête à ne converser exclusivement qu'en Anglais (tout en sachant parler Français et le status de ce forum), tu trouverais cela un brin déplacé, non ?
Je ne suis pas sûr de comprendre ta réponse, mais je voulais parler du cas général. Par exemple dans un livre sur Smalltalk, Java, C# ou autre langage qui utilise ce terme. Quand on présente le concept de fonction dans un langage de programmation comme C, il est facile d'expliquer le terme en faisant la relation avec une fonction mathématique (moins évident en C et dérivées depuis qu'on a les fonctions void, mais encore là, on peut donner l'explication historique au moins). Si j'avais à écrire un livre sur Java ou C#, j'aimerais présenter tout aussi logiquement le terme méthode et je n'ai jamais rien vu de bien fort à ce sujet. Il faut dire que je n'ai aucun livre spécifique sur Smalltalk (où le terme a été inventé je crois).
En principe, quand il n'y a pas d'abus de langage on a:
fonction = resolution statique = appel direct methode = resolution tardive = appel indirect (pointeur de fonction) message = resolution dynamique = appel dynamique (dictionnaire + pointeur de fonction)
Le probleme, c'est que l'emploi de ces termes impliques une connaissance (limitee) de la resolution d'appel et donc de l'implementation, ce qui n'est generalement pas le but. D'ou je pense une certaine confusion a travers les cultures et les langages suivant le parti pris de celui qui explique (moi compris ;-) ). Le fait aussi que les compilateurs sachent dans certaines conditions faire les optimisation d'appel message -> methode -> fonction -> inline n'aide pas non plus a etre formel.
a+, ld.
Michel Michaud wrote:
Dans le message m3d5pbgzt6.fsf@uniton.integrable-solutions.net,
"Michel Michaud" <mm@gdzid.com> writes:
Quelqu'un a-t-il déjà vu une explication du principe des
« méthodes » où ce terme semble justifié adéquatement ?
Si un gugus s'amène sur ce forum et s'entête à ne converser
exclusivement qu'en Anglais (tout en sachant parler Français et le
status de ce forum), tu trouverais cela un brin déplacé, non ?
Je ne suis pas sûr de comprendre ta réponse, mais je voulais
parler du cas général. Par exemple dans un livre sur Smalltalk,
Java, C# ou autre langage qui utilise ce terme. Quand on présente
le concept de fonction dans un langage de programmation comme C,
il est facile d'expliquer le terme en faisant la relation avec une
fonction mathématique (moins évident en C et dérivées depuis qu'on
a les fonctions void, mais encore là, on peut donner l'explication
historique au moins). Si j'avais à écrire un livre sur Java ou C#,
j'aimerais présenter tout aussi logiquement le terme méthode et
je n'ai jamais rien vu de bien fort à ce sujet. Il faut dire que
je n'ai aucun livre spécifique sur Smalltalk (où le terme a été
inventé je crois).
En principe, quand il n'y a pas d'abus de langage on a:
fonction = resolution statique = appel direct
methode = resolution tardive = appel indirect (pointeur de fonction)
message = resolution dynamique = appel dynamique (dictionnaire +
pointeur de fonction)
Le probleme, c'est que l'emploi de ces termes impliques une connaissance
(limitee) de la resolution d'appel et donc de l'implementation, ce qui
n'est generalement pas le but. D'ou je pense une certaine confusion a
travers les cultures et les langages suivant le parti pris de celui qui
explique (moi compris ;-) ). Le fait aussi que les compilateurs sachent
dans certaines conditions faire les optimisation d'appel message ->
methode -> fonction -> inline n'aide pas non plus a etre formel.
Quelqu'un a-t-il déjà vu une explication du principe des « méthodes » où ce terme semble justifié adéquatement ?
Si un gugus s'amène sur ce forum et s'entête à ne converser exclusivement qu'en Anglais (tout en sachant parler Français et le status de ce forum), tu trouverais cela un brin déplacé, non ?
Je ne suis pas sûr de comprendre ta réponse, mais je voulais parler du cas général. Par exemple dans un livre sur Smalltalk, Java, C# ou autre langage qui utilise ce terme. Quand on présente le concept de fonction dans un langage de programmation comme C, il est facile d'expliquer le terme en faisant la relation avec une fonction mathématique (moins évident en C et dérivées depuis qu'on a les fonctions void, mais encore là, on peut donner l'explication historique au moins). Si j'avais à écrire un livre sur Java ou C#, j'aimerais présenter tout aussi logiquement le terme méthode et je n'ai jamais rien vu de bien fort à ce sujet. Il faut dire que je n'ai aucun livre spécifique sur Smalltalk (où le terme a été inventé je crois).
En principe, quand il n'y a pas d'abus de langage on a:
fonction = resolution statique = appel direct methode = resolution tardive = appel indirect (pointeur de fonction) message = resolution dynamique = appel dynamique (dictionnaire + pointeur de fonction)
Le probleme, c'est que l'emploi de ces termes impliques une connaissance (limitee) de la resolution d'appel et donc de l'implementation, ce qui n'est generalement pas le but. D'ou je pense une certaine confusion a travers les cultures et les langages suivant le parti pris de celui qui explique (moi compris ;-) ). Le fait aussi que les compilateurs sachent dans certaines conditions faire les optimisation d'appel message -> methode -> fonction -> inline n'aide pas non plus a etre formel.
a+, ld.
Michel Michaud
Dans le message dc23j8$1pj$,
Michel Michaud wrote:
Je ne suis pas sûr de comprendre ta réponse, mais je voulais parler du cas général. Par exemple dans un livre sur Smalltalk, Java, C# ou autre langage qui utilise ce terme. Quand on présente le concept de fonction dans un langage de programmation comme C, il est facile d'expliquer le terme en faisant la relation avec une fonction mathématique (moins évident en C et dérivées depuis qu'on a les fonctions void, mais encore là, on peut donner l'explication historique au moins). Si j'avais à écrire un livre sur Java ou C#, j'aimerais présenter tout aussi logiquement le terme méthode et je n'ai jamais rien vu de bien fort à ce sujet. Il faut dire que je n'ai aucun livre spécifique sur Smalltalk (où le terme a été inventé je crois).
En principe, quand il n'y a pas d'abus de langage on a:
fonction = resolution statique = appel direct methode = resolution tardive = appel indirect (pointeur de fonction) message = resolution dynamique = appel dynamique (dictionnaire + pointeur de fonction)
Je sais bien tout ça... J'essaie de trouver une explication au choix du mot « méthode » au lieu de « patate » par exemple. L'explication classique est que c'est la méthode (« façon ») de traiter le « message ». Ça me semble très faible comme explication, même avec les nuances anglaises du mot method.
Il semble que personne ici ne soit capable de faire mieux par contre. Faudra s'y faire :-(
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message dc23j8$1pj$1@sunnews.cern.ch,
Michel Michaud wrote:
Je ne suis pas sûr de comprendre ta réponse, mais je voulais
parler du cas général. Par exemple dans un livre sur Smalltalk,
Java, C# ou autre langage qui utilise ce terme. Quand on présente
le concept de fonction dans un langage de programmation comme C,
il est facile d'expliquer le terme en faisant la relation avec une
fonction mathématique (moins évident en C et dérivées depuis qu'on
a les fonctions void, mais encore là, on peut donner l'explication
historique au moins). Si j'avais à écrire un livre sur Java ou C#,
j'aimerais présenter tout aussi logiquement le terme méthode et
je n'ai jamais rien vu de bien fort à ce sujet. Il faut dire que
je n'ai aucun livre spécifique sur Smalltalk (où le terme a été
inventé je crois).
En principe, quand il n'y a pas d'abus de langage on a:
fonction = resolution statique = appel direct
methode = resolution tardive = appel indirect (pointeur de fonction)
message = resolution dynamique = appel dynamique (dictionnaire +
pointeur de fonction)
Je sais bien tout ça... J'essaie de trouver une explication au
choix du mot « méthode » au lieu de « patate » par exemple.
L'explication classique est que c'est la méthode (« façon »)
de traiter le « message ». Ça me semble très faible comme
explication, même avec les nuances anglaises du mot method.
Il semble que personne ici ne soit capable de faire mieux par
contre. Faudra s'y faire :-(
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Je ne suis pas sûr de comprendre ta réponse, mais je voulais parler du cas général. Par exemple dans un livre sur Smalltalk, Java, C# ou autre langage qui utilise ce terme. Quand on présente le concept de fonction dans un langage de programmation comme C, il est facile d'expliquer le terme en faisant la relation avec une fonction mathématique (moins évident en C et dérivées depuis qu'on a les fonctions void, mais encore là, on peut donner l'explication historique au moins). Si j'avais à écrire un livre sur Java ou C#, j'aimerais présenter tout aussi logiquement le terme méthode et je n'ai jamais rien vu de bien fort à ce sujet. Il faut dire que je n'ai aucun livre spécifique sur Smalltalk (où le terme a été inventé je crois).
En principe, quand il n'y a pas d'abus de langage on a:
fonction = resolution statique = appel direct methode = resolution tardive = appel indirect (pointeur de fonction) message = resolution dynamique = appel dynamique (dictionnaire + pointeur de fonction)
Je sais bien tout ça... J'essaie de trouver une explication au choix du mot « méthode » au lieu de « patate » par exemple. L'explication classique est que c'est la méthode (« façon ») de traiter le « message ». Ça me semble très faible comme explication, même avec les nuances anglaises du mot method.
Il semble que personne ici ne soit capable de faire mieux par contre. Faudra s'y faire :-(
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Fabien LE LEZ
On Mon, 25 Jul 2005 10:06:35 -0400, "Michel Michaud" :
Je sais bien tout ça... J'essaie de trouver une explication au choix du mot « méthode » au lieu de « patate » par exemple.
Si on va par là, on peut aussi essayer de trouver pourquoi on désigne ce tubercule par le mot "patate" et pas "xylophone" ;-)
On Mon, 25 Jul 2005 10:06:35 -0400, "Michel Michaud" <mm@gdzid.com>:
Je sais bien tout ça... J'essaie de trouver une explication au
choix du mot « méthode » au lieu de « patate » par exemple.
Si on va par là, on peut aussi essayer de trouver pourquoi on désigne
ce tubercule par le mot "patate" et pas "xylophone" ;-)
On Mon, 25 Jul 2005 10:06:35 -0400, "Michel Michaud" :
Je sais bien tout ça... J'essaie de trouver une explication au choix du mot « méthode » au lieu de « patate » par exemple.
Si on va par là, on peut aussi essayer de trouver pourquoi on désigne ce tubercule par le mot "patate" et pas "xylophone" ;-)
Non, on ne part pas de rien. Pense à fonction, qui est, je crois l'autre mot le plus classique en plus de procédure... Mais « méthode » ?
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Laurent Deniau
Michel Michaud wrote:
Dans le message ,
On Mon, 25 Jul 2005 10:06:35 -0400, "Michel Michaud" :
Je sais bien tout ça... J'essaie de trouver une explication au choix du mot « méthode » au lieu de « patate » par exemple.
Si on va par là, on peut aussi essayer de trouver pourquoi on désigne ce tubercule par le mot "patate" et pas "xylophone" ;-)
Non, on ne part pas de rien. Pense à fonction, qui est, je crois l'autre mot le plus classique en plus de procédure... Mais « méthode » ?
Il est possible que cela soit venu par iteration (chronologique):
1) fonction: code qui possede une fonctionnalite. 2) analogie math: qui renvoie un resultat -> procedure: fonctionnalite qui ne renvoie pas de resultat. 3) fonction + objet: fonctionalite adaptee a l'objet -> methodes 4) methode: fonction selectionnee par l'objet (et donc adaptee).
voila mes deux centimes de contribution.
a+, ld.
Michel Michaud wrote:
Dans le message 8ht9e1l2t7hev64vh9ut2v5irtamf8ts7v@4ax.com,
On Mon, 25 Jul 2005 10:06:35 -0400, "Michel Michaud" <mm@gdzid.com>:
Je sais bien tout ça... J'essaie de trouver une explication au
choix du mot « méthode » au lieu de « patate » par exemple.
Si on va par là, on peut aussi essayer de trouver pourquoi on
désigne ce tubercule par le mot "patate" et pas "xylophone" ;-)
Non, on ne part pas de rien. Pense à fonction, qui est, je crois
l'autre mot le plus classique en plus de procédure... Mais
« méthode » ?
Il est possible que cela soit venu par iteration (chronologique):
1) fonction: code qui possede une fonctionnalite.
2) analogie math: qui renvoie un resultat
-> procedure: fonctionnalite qui ne renvoie pas de resultat.
3) fonction + objet: fonctionalite adaptee a l'objet -> methodes
4) methode: fonction selectionnee par l'objet (et donc adaptee).
On Mon, 25 Jul 2005 10:06:35 -0400, "Michel Michaud" :
Je sais bien tout ça... J'essaie de trouver une explication au choix du mot « méthode » au lieu de « patate » par exemple.
Si on va par là, on peut aussi essayer de trouver pourquoi on désigne ce tubercule par le mot "patate" et pas "xylophone" ;-)
Non, on ne part pas de rien. Pense à fonction, qui est, je crois l'autre mot le plus classique en plus de procédure... Mais « méthode » ?
Il est possible que cela soit venu par iteration (chronologique):
1) fonction: code qui possede une fonctionnalite. 2) analogie math: qui renvoie un resultat -> procedure: fonctionnalite qui ne renvoie pas de resultat. 3) fonction + objet: fonctionalite adaptee a l'objet -> methodes 4) methode: fonction selectionnee par l'objet (et donc adaptee).
voila mes deux centimes de contribution.
a+, ld.
Jean-Marc Bourguet
Haskell n'a pas d'effet de bord, mais un concept (les monades) qui permet d'en avoir le goût et la saveur. Mais je n'ai jamais réellement pris la peine de comprendre ce que c'était.
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
Haskell n'a pas d'effet de bord, mais un concept (les
monades) qui permet d'en avoir le goût et la saveur. Mais
je n'ai jamais réellement pris la peine de comprendre ce que
c'était.
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
Haskell n'a pas d'effet de bord, mais un concept (les monades) qui permet d'en avoir le goût et la saveur. Mais je n'ai jamais réellement pris la peine de comprendre ce que c'était.
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
Gabriel Dos Reis
Jean-Marc Bourguet writes:
| Haskell n'a pas d'effet de bord, mais un concept (les | monades) qui permet d'en avoir le goût et la saveur. Mais | je n'ai jamais réellement pris la peine de comprendre ce que | c'était.
Les IO monads, par exemple ? C'est bel et bien des effets de bord. La seule difference avec des langages profondement imperatifs, c'est qu'ils ont une construction typee pour marquee la ou se trouve les effets de bords. sinon, ils ont bien des effets de bords et meme des constructions "unsafe". Ils disent "purement fonctionnel", mais ils fournissent aussi la definition qui va avec :-)
-- Gaby
Jean-Marc Bourguet <jm@bourguet.org> writes:
| Haskell n'a pas d'effet de bord, mais un concept (les
| monades) qui permet d'en avoir le goût et la saveur. Mais
| je n'ai jamais réellement pris la peine de comprendre ce que
| c'était.
Les IO monads, par exemple ? C'est bel et bien des effets de bord.
La seule difference avec des langages profondement imperatifs, c'est
qu'ils ont une construction typee pour marquee la ou se trouve les
effets de bords. sinon, ils ont bien des effets de bords et meme des
constructions "unsafe". Ils disent "purement fonctionnel", mais ils
fournissent aussi la definition qui va avec :-)
| Haskell n'a pas d'effet de bord, mais un concept (les | monades) qui permet d'en avoir le goût et la saveur. Mais | je n'ai jamais réellement pris la peine de comprendre ce que | c'était.
Les IO monads, par exemple ? C'est bel et bien des effets de bord. La seule difference avec des langages profondement imperatifs, c'est qu'ils ont une construction typee pour marquee la ou se trouve les effets de bords. sinon, ils ont bien des effets de bords et meme des constructions "unsafe". Ils disent "purement fonctionnel", mais ils fournissent aussi la definition qui va avec :-)
