En C++, on généralise les fonctions aux foncteurs, c'est à dire tout type qui peut s'appeler tel une fonction (donc éventuellement une classe avec un operator() surchargé).
C'est comme ça qu'on fait des closures etc.
boost::lambda (et autres du même genre) génère automatiquement un foncteur à partir d'une expression lambda.
Et en C++0x y'a une syntaxe spéciale pour exprimer les fonctions lambda.
Donc franchement, je ne vois pas pourquoi tu parles de pointeurCradeSurFonctionDeComparaisonMaisAvecUnLangagePourriCommeC++TasPasLeChoix. D'autant plus que la fonction utilisera par défaut operator==, donc il s'agira d'un argument optionnel.
Et je vois pas non plus pourquoi tu mets des & et * ? C'est n'importe quoi. Et cette définition de result vide alors que tu le redéfinis après, c'est tout simplement sous-optimal et stupide.
Je pense qu'intersection devrait être une fonction libre : il ne s'agit nullement d'une propriété propre à ta liste.
Accessoirement elle devrait écrire sa sortie sur un itérateur pour pouvoir mieux être exploitée.
Bref, un design à la std::set_intersection, mais sans tri. (ça va faire un bel algo en O(n*m) tout pourri)
Quand on voit que les gens qui critiquent le C++ ne savent même pas des trucs basiques comme ça, ça fait peur.
[^] # Re: C++ : RAII et programmation générique
Posté par loufoque . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 4.
C'est comme ça qu'on fait des closures etc.
boost::lambda (et autres du même genre) génère automatiquement un foncteur à partir d'une expression lambda.
Et en C++0x y'a une syntaxe spéciale pour exprimer les fonctions lambda.
Donc franchement, je ne vois pas pourquoi tu parles de pointeurCradeSurFonctionDeComparaisonMaisAvecUnLangagePourriCommeC++TasPasLeChoix. D'autant plus que la fonction utilisera par défaut operator==, donc il s'agira d'un argument optionnel.
Et je vois pas non plus pourquoi tu mets des & et * ? C'est n'importe quoi. Et cette définition de result vide alors que tu le redéfinis après, c'est tout simplement sous-optimal et stupide.
Je pense qu'intersection devrait être une fonction libre : il ne s'agit nullement d'une propriété propre à ta liste.
Accessoirement elle devrait écrire sa sortie sur un itérateur pour pouvoir mieux être exploitée.
Bref, un design à la std::set_intersection, mais sans tri. (ça va faire un bel algo en O(n*m) tout pourri)
Quand on voit que les gens qui critiquent le C++ ne savent même pas des trucs basiques comme ça, ça fait peur.