Discussion :

[deubelte]

ok merci
c'est ce que j'avais fait au départ.
j'ai l'impression que l'usage de pointeurs en C+ sur fonction est tres limité.

Peut on utiliser les pointeurs avec des appels de fonctions partiels, des compositions de fonction? (je donne un exemple plus haut de ce que je veux faire).

[HanLee]

ok merci
c'est ce que j'avais fait au départ.
j'ai l'impression que l'usage de pointeurs en C+ sur fonction est tres limité.

Peut on utiliser les pointeurs avec des appels de fonctions partiels, des compositions de fonction? (je donne un exemple plus haut de ce que je veux faire).

Je t'ai dit non plus haut, à moins de tricher salement et difficilement...

[Alp]

Je t'ai dit non plus haut, à moins de tricher salement et difficilement...

Ce qui est possible toutefois. boost::bind permet l'application partielle et la composition est aisee avec boost::function et boost::bind. On peut meme aller plus loin avec boost.phoenix / boost.lambda.

[loufoque]

Toutes les opérations que tu peux faire dans un langage fonctionnel et même plus sont possibles.

[JolyLoic]

Je n'ai jamais trouvé de solution agréable pour la mémoization. En particulier, le point qui me manque est le "remplacement" dans un code existant, pas spécialement écrit pour, d'une fonction par sa version mémoizée.

[loufoque]

auto f_memoized = memoize<argument_type>(f);
devrait parfaitement être capable de générer une fonction f_memoized qui fera de la memoization sur f... (argument_type n'a même pas forcément besoin d'être spécifié si il peut être déduit d'après f, comme c'est le cas pour un pointeur de fonction par exemple)
Il suffit de faire une table avec les arguments comme clé, de chercher la valeur dans la table, et si elle n'y est pas d'appeler la fonction enrobée.

Boost.Flyweight (avec le système key_value) permet ce genre de choses, sauf que c'est orienté constructeur plutôt que fonction, ce qui est équivalent.

[JolyLoic]

Oui, mais mon problème est de pouvoir ensuite dans un code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int g()
{
  return f();
}

Utiliser f_memoized à la place de f sans pour autant avoir à toucher une virgule de la définition de g. Dans l'idéal, je voudrais pouvoir écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

auto g_optimized = memoize(g, f);

Qui ferait l'équivalent de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int g_optimized()
{
  return f_memoized();
}

[loufoque]

J'avais même pas pensé qu'il pouvait être utile de memoizer une fonction sans arguments.

Tu peux pas vraiment faire ce que tu veux, non, à moins de remplacer l'invocation de f par celle de memoize(f) ce qui demanderait sûrement de l'aide de la part de l'éditeur de liens.

[JolyLoic]

J'avais même pas pensé qu'il pouvait être utile de memoizer une fonction sans arguments.

J'ai juste zappé les morceaux qui ne me semblaient pas pertinents pour mon problème.

Tu peux pas vraiment faire ce que tu veux, non, à moins de remplacer l'invocation de f par celle de memoize(f) ce qui demanderait sûrement de l'aide de la part de l'éditeur de liens.

Oui. Ou alors une abomination à base de macros peut-être, mais je n'ai pas trop voulu chercher dans cette voie.

[Alp]

Oui. Ou alors une abomination à base de macros peut-être, mais je n'ai pas trop voulu chercher dans cette voie.

On doit pouvoir s'en sortir. Mais 1/ ça serait affreusement inutilisable (fonctionnel mais dégueulasse quoi) 2/ le besoin est faible à ma connaissance

[JolyLoic]

2/ le besoin est faible à ma connaissance

Je pense que mémoizer du code non prévu pour sans le retoucher pourrait avoir une certaine valeur pendant une phase d'optimisation. Mais ça demande certainement un langage plus dynamique que le C++...

[Alp]

Je pense que mémoizer du code non prévu pour sans le retoucher pourrait avoir une certaine valeur pendant une phase d'optimisation. Mais ça demande certainement un langage plus dynamique que le C++...

En plus de ça, j'imagine déjà la complexité de la chose...

[loufoque]

Faire de la memoization ça change la complexité des algorithmes et tout, moi c'est plus quelque chose auquel je penserais au début de la conception qu'à la fin.

[Jean-Marc.Bourguet]

Oui, mais mon problème est de pouvoir ensuite dans un code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int g()
{
  return f();
}

Utiliser f_memoized à la place de f sans pour autant avoir à toucher une virgule de la définition de g. Dans l'idéal, je voudrais pouvoir écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

auto g_optimized = memoize(g, f);

Qui ferait l'équivalent de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int g_optimized()
{
  return f_memoized();
}

Quand je memoize (ce qui m'est arrive en phase d'optimisation), c'est f() que je touche, pas les clients que je ne connais parfois meme pas. Je comprends donc mal ta problematique; pour ce que j'en percois, je me demande si une piste n'est pas de jouer avec la recherche des noms (rendre f() non visible et importer un f() d'un namespace memoized).

[JolyLoic]

Faire de la memoization ça change la complexité des algorithmes et tout, moi c'est plus quelque chose auquel je penserais au début de la conception qu'à la fin.

C'est avant tout déplacer le curseur sur le compromis mémoire/performances et c'est donc quelque-chose que j'estime légitime de faire quand j'ai de vraies données de profiling pour étayer mon choix.

Quand je memoize (ce qui m'est arrive en phase d'optimisation), c'est f() que je touche, pas les clients que je ne connais parfois meme pas.

Pour l'instant, c'est plus une interrogation théorique qu'un besoin concret, je passe donc peut-être à coté de certains problèmes. L'idée de base étant comment fournir de la mémoization en C++ qui tienne en une seule ligne.

Le faire à l'extérieur de la fonction à mémoizer est envisageable avec de la métaprogrammation, mais dans ce cas là, on doit modifier le code client, ce que j'aurais aimé éviter. L'avantage est que pour deux clients différents, qui n'auraient pas les mêmes profils de donnée en entrée, on pourrait décider que l'un utilise la version mémoizée, pas l'autre.

Le faire depuis l'intérieur de la fonction en question me semble un peu moins direct, et demande un refactoring du code. De plus, tous les clients utilisent alors la version mémoizée.

Dans mon monde idéal, on n'a besoin de toucher ni au code de f, ni à celui de g, mais uniquement au code initialement client de g, pour décider d'appeler un code équivalent à g mais qui fait appel à une version mémoizée de f. J'hésite sur les compromis qui me semblent les plus acceptables par rapport à cette vision, et je manque un peu d'un cas concret pour m'aider à choisir.

Je comprends donc mal ta problematique; pour ce que j'en percois, je me demande si une piste n'est pas de jouer avec la recherche des noms (rendre f() non visible et importer un f() d'un namespace memoized).

C'est effectivement une piste intéressante. C'est la partie "rendre f non visible" qui me pose problème, je ne vois pas trop comment y parvenir dans mes hypothèses de travail.

[Jean-Marc.Bourguet]

Le faire à l'extérieur de la fonction à mémoizer est envisageable avec de la métaprogrammation, mais dans ce cas là, on doit modifier le code client, ce que j'aurais aimé éviter. L'avantage est que pour deux clients différents, qui n'auraient pas les mêmes profils de donnée en entrée, on pourrait décider que l'un utilise la version mémoizée, pas l'autre.

Si tu ne le fais pas pour tout les clients avec le meme algo (on peut jouer sur le nombre de valeur dans le cache et la maniere dont les valeurs dans le cache sont remplacee), il va te falloir faire quelque chose pour indiquer a chaque client ce qu'il appelle. Le plus simple me semble de changer le nom de la fonction appelee.

Dans mon monde idéal, on n'a besoin de toucher ni au code de f, ni à celui de g, mais uniquement au code initialement client de g, pour décider d'appeler un code équivalent à g mais qui fait appel à une version mémoizée de f. J'hésite sur les compromis qui me semblent les plus acceptables par rapport à cette vision, et je manque un peu d'un cas concret pour m'aider à choisir.

Ca, je ne vois pas comment faire sans liaison dynamique -- tel que tu le specifies, deux appels differents a g() peuvent utiliser des versions differentes de f(). Donc difficile a faire sans refactoriser pour passer a g l'info necessaire ou passer aux astuces plus ou moins avouables.

Evidemment, trivial avec un lisp scope dynamiquement -- mais bon ils sont un peu hors mode -- ou qui permet le choix (Common Lisp, demande a Pascal, il se fera un plaisir de te renseigner )

C'est effectivement une piste intéressante. C'est la partie "rendre f non visible" qui me pose problème, je ne vois pas trop comment y parvenir dans mes hypothèses de travail.

En toute generalite, ce n'est pas simple; et ca ne permet pas le choix dynamique. Mais c'est une approche qui peut etre utile.