qu'est ce qui ne vas pas dans l'appel à la fonction transform ?
 
merci

j'ai pas le droit de passer les arguments par référence .?why

D'après ce que je viens de lire le problème me semblerai venir du bind2nd.
 
Celui-ci ne supportant pas les références, il faudrait un warper de la même façon que boost règle le pb avec boost::ref...
 
A priori dans la STL, faut aller voir du côté de std::tr1::bind

les bind de la STL sont obsoletes. Utilise boost::bind et boost::lambda

c'est normal que ça ne compile pas ça :
 
result_of< bind(std::less<int>(),_1,2) >::type;

bind c'ets une fonction par un type.
Accessoirement le type de retour de bind est tres complexe et a peu d'interet vu que ca se stocke dans un boost::function.

le problème c'est que ça implique de connaitre/spécifier le type exact de l'objet function résultant de bind que l'on souhaite stocké dans un objet boost::function, sauf erreur de ma part

non tu as besoin de son prototype c'est tout.

bind(std::less<int>(),_1,2) a pour prototype  bool(int)
dont tu mets ton bind dans un boost::function<bool(int)>

et mieux tu utilise cash _1 < 2 dans ton appel vu tu as acces à de vrais lambda

faut mettre quoi comme directive using pour que _1 soit reconnu quand on utlise bind de lambda ?
 

ne suffit pas
 
 
EDIT : using boost::lambda; OK

énorme cette librairie lambda

à minima pour utiliser boost::lamnda dans un projet on a besoin de  quoi comme entête ?

boost/lambda/lambda.hpp et boost/lambda/bind.hpp de tete
Je te conseil aussi d ejeter un oeil à Phoenix qui etends lambda.

à terme les deux vont fusioner ?

oui on (je) travaille sur ça

et la lib bind continuera de subsister à côté ?

ouais pour comaptibilité ascendante.

Quelle genre de fonctionnalité la lib phoenix n'implémentera pas ? (par rapport à un vrai langage fonctionelle )

je sais pas. EN gros l'idée de Phoenix et de forunir tout C++ en mode lazy-evaluable. Genre

on entends quoi par "lazy-evaluable" ?

bah evalutation paresseuse. Tu ecris du C++ mais tu défére son exécution.

quel est le principal intérêt ?

http://en.wikipedia.org/wiki/Lazy_evaluation

 
mais en quoi ici on a "The benefits of lazy evaluation include: performance increases due to avoiding unnecessary calculations"
 
in finé ça revient au même que d'éxécuter une fonction, je capte pas l'avantage
 
 

l'avantage c'ets que une fois construit, tu peux passer f à une autre fonction. et l'évaluer pluis tard.

mais d'ou provient le gain en performance exactement ? à l'exécution quand la fonction qui reçoit ce pointeur sur ce code en paramètre est appelée, l'éxécution/évaluation à lieu, et donc à priori  ça va prendre le même temps CPU.
 
Autrement dit ma question est en quoi le fait de délayer l'évaluation induit un gain en perf
 
PS: l'évaluation et l'exécution ça désigne deux choses différentes ?

L'idée est de créée une representation du code sous forme transportable qui n'est pas évalué. Puis, tu n'évalueras cette fonction que si tu en as réeellement besoin.

"L'évaluation paresseuse est une technique de programmation où le programme n'exécute pas de code avant que les résultats de ce code ne soient réellement nécessaires."

Dans l'exemple f ne fait que construire un objet fonction. rien n'est executé tant que f(x) n'est pas appelé. Dans un cadre plus dynamique, tu peut ne jamais avoir à l'appeler, là ou si tu avais évaluer directement tu aurais consommé du CPU pour rien.

L'aure exemple ets le cas de la fonction qui construit une fonction recursivement puis, à l'éape termianl, appelle la fonction ainsi construite.

ok en faite ce que je vois pas c'est dans le cadre d'une fonction normal , si celle ci n'est jamais appelée,  à quel moment est ce qu'elle va prendre du CPU ? où à quel moment va t-elle être évaluée ?
 
je pensais qu'une fois compilée, et le code générée, si la fonction n'est jamais appelée elle ne bouffera pas un yota de CPU ?
 
C'est du gain en perf juste à la compilation ?

l'idée, c'est : plutôt que de passer le résultat d'une fonction en guise de paramètre à une autre, tu file la fonction elle-même pour qu'elle ne soit évaluée que si on a effectivement besoin du résultat.
 
Dans le cas opposé, tu aurais consommé du CPU à calculer une valeur dont la fonction n'a peut-être pas besoin dans le contexte actuel des choses.

humm ok je crois voir le truc, par exemple :
 
drawCircle( computeSomething() )
 
drawCircle(double val )
{
if(...)
 utiliser val
else(..)
  fare autre chose
}
 
 
si on est dans le else computeSomething a été évalué pour rien...

je suis preneur d'un meilleur exemple

 
c'est ça en faite oui  
 
mais dans le cas d'une fonction qui prend en param une autre fonction quelle est l'avantage de ce type de technique par rapport à un bête pointeur sur fonction?

c'est générique, typée et ca permet de faire des optimisation au site d'appel ce que empeche le passage de pointeur de fonction

1) ok ça fait des raisons, t'aurais un exemple en tête pour le coup des optimistion au site d'appel please
2) et avec le support des lambad dans C++0X phoenix aura encore un intérêt ?

Franchement t'as vu la syntaxe des lambda en 0x ? Même Douglas Gregor se demande pourquoi on a accepté cette proposal avec cette syntaxe.
Autre avantage de phoenix, tu peut introspecter l'AST que tu viens de créer

je sais pas perso la syntaxe m'a pas choqué

Personellement je préfére :

à

- j'aurais envie de dire que 2) est plus en homogénie avec la syntaxe du reste de langage
- faut voir les perfs aussi

y a pas de différence.