Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

vitesse: if vs pointeur de methode

126 réponses
Avatar
Guillaume Desticourt
bonsoir,

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;
}

inline bool isTrue(void)
{
return _test;
}
private:
bool _test;
};

#endif

if.cc
-----


#include "def.hh"

int main(void)
{
Test * test = new Test();

for (unsigned long u = 0;
u < MAX_LOOP;
++u)
{
if (test->isTrue())
test->behavior1();
else
abort();
}
return 0;
}


pointer.cc
----------



#include "def.hh"

int main(void)
{
Test * test = new Test();
behavior_t behavior;
if (test->isTrue())
behavior = &Test::behavior1;
else
abort();

(test->*behavior)();


for (unsigned long u = 0;
u < MAX_LOOP;
++u)
{
(test->*behavior)();
}
return 0;
}


Makefile
--------

all: iftest pointertest

iftest: def.hh
g++ -Wall -Werror -O2 if.cc -o iftest

pointertest: def.hh
g++ -Wall -Werror -O2 pointer.cc -o pointertest

clean:
rm -f *.o
rm -f *~
rm -f iftest pointertest


une tarball est - provisoirement - disponible ici:
http://www.freenopen.net/~guillaume/info/prog/source/ifpointerbench-20050720-1755.tar.bz2

--
Guillaume Desticourt

10 réponses

Avatar
Michel Michaud
Dans le message ,
"Michel Michaud" writes:

(En fait, on peut dire que MS a laissé tomber C++ car pour


C'est intéressant, parce que selon des sources sûres, MS encourage
les dévelopements internes en C++, et non plus en C# comme cela a
été la politique juste après le lancement de la propagande C#.


Tu te trompes. C'est C++/CLI qui est encouragé au lieu de C#. Et
C++/CLI != C++.

(Ceci dit, je suppose qu'il y a du développement interne chez MS
qui n'est pas en .NET et j'espère qu'ils continuent à faire du
C++ pour ça. C'est la même chose ailleurs aussi...)

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/


Avatar
Guillaume Desticourt
wrote:

Guillaume Desticourt wrote:




[...]



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.





La solution classique ici, c'est la modèle stratégie, non ?




d'apres ce que je lis dans Design Patterns, Catalogue de modeles de
conception reutilisables de Gamma Helm Johnson et vissides, la strategy
sert a remplacer:

switch(_srategie):
case STRATEGY1
behavior1();
break;
case STRATEGY2:
behavior2()
...

par:

_strategie->behavior();

donc oui ca a l air de coller, mais:
vu que je dois pouvoir changer de comportement, il faudrait que
_compositeur soit un pointer sur la strategie qui m interesse, donc dans
ma classe j aurais un set de disons 2 strategies differentes, et
_strategie serait settee sur un element de mon set, puis change sur l
autre etc...
j aurais donc
- un Strategy * pointant sur un des...
- deux Strategy * (un &Strategy1 et un &Strategy2)

bon ca revient au meme que mon pointer de methode si ce n est que au
lieu de bosser avec des objets Stratetegy ma solution de pointer de
methode bosser avec des methodes behavior, et que le behavior est donc
dans ma classe principale au lieu d etre dans une derivee de Strategy.
bref il me semble que c est pareil?


Est-ce qu'il y a des raisons pour faire autre chose ? D'après
mon expérience :

-- La syntaxe de l'utilisation des pointeurs deplaît à
beaucoup. Moi, je m'en sers de temps en temps, mais chaque
fois, j'ai dû bien en justifier l'utilisation dans les
révues de code. Il faut donc bien une justification pour les
utiliser.

-- L'utilisation des if/else (dans ce cas-ci) risque de donner
des fonctions trop grandes et trop complexes.





d'accord mais dans ce cas, et apres reflexion suite a ce thread, je me
demande si ce n est pas la meilleure solution, en effet le code du if et
du else sont quasi identique, a 4 lignes pres, ainsi, dispatcher le
code dans des fonctions differentes n est peut etre pas pertient
notamment au niveau de la maintenance du code.

en esperant avoir ete clair,
cordialement,

--
Guillaume Desticourt




Avatar
Fabien LE LEZ
On 21 Jul 2005 16:25:14 +0200, Gabriel Dos Reis
:

C'est intéressant, parce que selon des sources sûres, MS encourage
les dévelopements internes


Il y a encore des développements internes chez MS ? :-p

en C++,


Ben oui, il me semble que MS-Office n'était pas programmé en Visual
Basic, je ne vois pas pourquoi ils se mettraient à utiliser son
remplaçant.

Avatar
Stan
"Guillaume Desticourt" a écrit dans
le message de news: 42df9c7f$0$13356$

[...]

d'accord mais dans ce cas, et apres reflexion suite a ce thread, je me
demande si ce n est pas la meilleure solution, en effet le code du if et
du else sont quasi identique, a 4 lignes pres, ainsi, dispatcher le
code dans des fonctions differentes n est peut etre pas pertient
notamment au niveau de la maintenance du code.

en esperant avoir ete clair,
cordialement,



Ben, clair ou pas clair, pour juger une solution par rapport à une autre,
il faut une vision globale du projet;
or ce qui a été exposé n'est qu'une partie.


--
-Stan

Avatar
Fabien LE LEZ
On Thu, 21 Jul 2005 09:23:43 -0400, "Michel Michaud" :

Plus sérieusement : s'il y a une meilleure alternative, ce sont
les développeurs qui vont laisser tomber C# avant MS.


Pas sûr. MS a décidé d'abandonner d'abandonner Visual Basic, les MFC,
etc.
Dans un autre domaine, ils avaient décidé d'abandonner le support de
Windows NT4 Server, et ont été obligés de le prolonger à la demande
insistante de leurs clients.

Avatar
Matthieu Moy
Fabien LE LEZ writes:

Ben oui, il me semble que MS-Office n'était pas programmé en Visual
Basic, je ne vois pas pourquoi ils se mettraient à utiliser son
remplaçant.


C# n'est absolument pas le remplaçant de VB. VB est explicitement un
langage concu pour être simple a apprendre, mais pas pour faciliter le
développement de grosses applications fiables.

C# ne vise pas du tout le même public. Je ne connais pas trop, mais en
gros, c'est un Java++, concu en particulier pour les systèmes
d'informations.

Si j'ai bien compris, lu but de MS pour le prochain Windows est de
faire un truc centré sur .NET, ou chaque application serai un
composant .NET. Du coup, je ne comprends pas trop le choix stratégique
de se replier sur C++. Gabi, on peut avoir une idée de tes sources ?

--
Matthieu

Avatar
Gabriel Dos Reis
"Michel Michaud" writes:

| Dans le message ,
| > "Michel Michaud" writes:
| >> Non, Managed C++ n'a pas été standardisé. C++/CLI le sera et je
| >> crois qu'il sera alors plus « standard » que C++ lui-même ! Il
| >
| > Cela veut dire quoi exactement ?
|
| Je te dirais que j'expliquais un peu dans la portion que tu as
| coupée, mais je suppose que tu n'as pas compris exactement ce
| que je voulais dire...

Oui.

| J'étais peut-être un peu trop subtil avec
| mon mot standard entre guillemets :-(

Peut-être.

| C'est sûr qu'un standard officiel est un standard officiel, mais
| je prenais le mot standard dans son sens général de courant,
| habituel, etc¹. Ceux qui vont faire du C++/CLI ne pourront faire
| que ça (tout ce qu'ils auront besoin sera là), alors que ceux qui
| font du C++ ne peuvent le plus souvent ni s'y limiter (il faut
| des bibliothèques ou des garanties supplémentaires), ni l'utiliser
| complètement (par manque de conformité des compilateurs courants).

Je comprends encore moins pourquoi cela fait de C++/CLI quelque chose
de plus « standard » que C++. Voudrais-tu en conclure que OCaml est plus
standard que Standard ML ou C++ ? Cela serait bien une utilisation
non-standard du mot standard, si je puis me permettre.

-- Gaby
Avatar
Gabriel Dos Reis
"Michel Michaud" writes:

| Dans le message ,
| > "Michel Michaud" writes:
| >
| >> (En fait, on peut dire que MS a laissé tomber C++ car pour
| >
| > C'est intéressant, parce que selon des sources sûres, MS encourage
| > les dévelopements internes en C++, et non plus en C# comme cela a
| > été la politique juste après le lancement de la propagande C#.
|
| Tu te trompes.

Tu veux dire ma taupe au sein de MS m'aurait menti ? J'ai du mal à te
croire, sans vouloir t'offenser :-)

-- Gaby
Avatar
Gabriel Dos Reis
Fabien LE LEZ writes:

| On 21 Jul 2005 16:25:14 +0200, Gabriel Dos Reis
| :
|
| >C'est intéressant, parce que selon des sources sûres, MS encourage
| >les dévelopements internes
|
| Il y a encore des développements internes chez MS ? :-p

D'après ce que j'ai compris dernièrement, ils feraient des choses très
intéressantes...

-- Gaby
Avatar
Gabriel Dos Reis
Matthieu Moy writes:

| Fabien LE LEZ writes:
|
| > Ben oui, il me semble que MS-Office n'était pas programmé en Visual
| > Basic, je ne vois pas pourquoi ils se mettraient à utiliser son
| > remplaçant.
|
| C# n'est absolument pas le remplaçant de VB. VB est explicitement un
| langage concu pour être simple a apprendre, mais pas pour faciliter le
| développement de grosses applications fiables.

C'est ce que la propagande dit aussi à propos de C#.

[...]

| Si j'ai bien compris, lu but de MS pour le prochain Windows est de
| faire un truc centré sur .NET, ou chaque application serai un
| composant .NET. Du coup, je ne comprends pas trop le choix stratégique
| de se replier sur C++. Gabi, on peut avoir une idée de tes sources ?
^
C'est un « y », autrement James va croire que toute la famille Kanze
se met à discuter dans fclc++ :-)

(1) Je ne travaille pas chez MS.
(2) Même si je travaillais chez MS, j'aurais signé un NDA, donc
je serais incapable de t'en dire plus.

En ce qui concerne ta question, je pourrais te dire que MS est une
très *grande* entreprise et donc emploie des gens avec des vues assez
diversifiées :-).
Tu pourrais aussi te poser des questions en lisant les derniers
articles de CUJ écrits par des employés MS qui argumentent qu'ils font
mieux avec Standard C++ que les gars d'à côté avec C#, et donc que
Standard C++ c'est bien. :-)


-- Gaby