comment transformer un foncteur en lambda non nommée?

Bonjour,

Prenons par exemple le problème suivant: nous voulons remplir un tableau d'entier avec des nombres aléatoires compris entre 0 et un nombre donné. Prenons donc le code suivant qui fais ce qui est demandé:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#include <algorithm>   // foncteur qui génère des nombre aléatoires compris entre 0 et mod struct RandMod { RandMod( int mod ) : mod_(mod) {} int operator()() { return ( (int) rand() ) % mod_; }   private: int mod_; };   main() { int* buffer = new int[10]; std::generate( buffer, buffer + 10, RandMod( 1000 ) ); }

---

Ok, le code ci-dessus fonctionne, mais comme je veux être à la mode, je veux utiliser des lambdas. Comment faire pour faire la même chose sans foncteur mais avec un lambda à la place?

Bonsoir,

Comme ça :

Code:

---

1 2 3 4 5

main() { int* buffer = new int[10]; std::generate( buffer, buffer + 10, []{ return rand() % 1000; }); }

---

Il manque la gestion du max :

Code:

---

1 2 3 4 5 6

main() { int* buffer = new int[10]; int mod = 123; std::generate( buffer, buffer + 10, [=]{ return rand() % mod; }); }

---

(à noter la présence du = qui indique que tous les éléments capturés le seront par copie, comme c'était le cas dans ton foncteur).

En terme de bonne pratique d'écriture, il vaut mieux indiquer explicitement les variables capturées ou pas ?

Code:

---

1 2 3 4

//: capture uniquement la variable mod par copie std::generate( buffer, buffer + 10, [=mod]{ return rand() % mod; }); // capture tout par copie std::generate( buffer, buffer + 10, [=]{ return rand() % mod; });

---

Edit : un peu de lecture sur les lambdas : http://cpp.developpez.com/gbdivers/cpp11/#LIV-A

Il y a aussi la possibilité d'un code un poil plus lisible :

Code:

---

1 2 3

int* buffer = new int[10]; auto RandGenerator = [] { return rand() % 1000; }; std::generate( buffer, buffer + 10, RandGenerator );

---

Citation:

---

Envoyé par gbdivers

En terme de bonne pratique d'écriture, il vaut mieux indiquer explicitement les variables capturées ou pas ?

Code:

---

1 2 3 4

//: capture uniquement la variable mod par copie std::generate( buffer, buffer + 10, [=mod]{ return rand() % mod; }); // capture tout par copie std::generate( buffer, buffer + 10, [=]{ return rand() % mod; });

---

---

J'ai encore du mal à parler bonne pratique, car je manque encore de pratique tout court... Je pense pour ma part ne pas expliciter les captures par valeur, mais expliciter les captures par référence, ces dernières demandant à faire attention à la durée de vie des objets capturés par rapport à celle de la lambda.

Citation:

---

Envoyé par cob59

Il y a aussi la possibilité d'un code un poil plus lisible :

---

Je ne suis pas convaincu que la lisibilité en soit tant améliorée. Et comme la durée de vie de la lambda est prolongée, si jamais il y a capture par référence, je préfère la première version...

Citation:

---

Envoyé par cob59

Il y a aussi la possibilité d'un code un poil plus lisible :

Code:

---

1 2 3

int* buffer = new int[10]; auto RandGenerator = [] { return rand() % 1000; }; std::generate( buffer, buffer + 10, RandGenerator );

---

---

Ce code ne prend pas en compte la variable (mod).

Même correction que pour le code d'Arzar si tu as besoin de mettre mod en paramètre, il suffit de l'ajouter dans la liste de capture

Ok. Merci à tous.

Citation:

---

Envoyé par JolyLoic

Je ne suis pas convaincu que la lisibilité en soit tant améliorée. Et comme la durée de vie de la lambda est prolongée, si jamais il y a capture par référence, je préfère la première version...

---

Il y a des exemples où une référence capturée par une lambda aurait une durée de vie moindre que la lambda elle-même ?
A la rigueur, on peut se demander ce qui se passerait si la fonction retournait une copie de RandGenerator (possible?) mais autrement...

Je suis le seul à trouver indigestes ces lambdas anonymes utilisées en "rvalue" ? Admettons, il nous faut étoffer la lambda :

Code:

---

1 2 3 4 5

std::generate( buffer, buffer + 10, [=] { // code ici // code ici return rand() % mod; });

---

Franchement, une instruction entrecoupée par une bloc {} ça ne vous parait pas hideux ?
En plus un objet RandGenerator aurait l'avantage «d'auto-commenter» l’objectif de la lambda.

Parce que justement, les lambda sont faites pour les microscopiques bouts de codes, pas pour une grande fonction.

Pour ca, on a une fonctionnalité extremement ancienne: les fonctions.

Salut,

Je ne vais pas proposer de réponse au problème de base, mais je voudrais quand même émettre (en fait, répéter, car je l'ai déjà émis dans une autre discussion ;)) mon avis au sujet des lambda expressions:

De manière générale, je ne suis déjà pas certain qu'il soit vraiment intéressant de vouloir refaire quelque chose qui fonctionne et qui reste malgré tout conceptuellement correct simplement pour "faire moderne".

Autant je suis convaincu de l'utilité de remplacer un pointeur de fonction par un foncteur, autant je reste plus que mitigé quand à l'idée de remplacer un foncteur par une lambda expression :P

Concernant les lambda en elles-même, mon ressenti (plus que personnel, mais que je partage :D) est qu'il s'agit d'une chose intéressante, tant que:

• Soit, elle se trouve dans une fonction qui ne fait rien d'autre que d'utiliser la lambda, autrement, on en arrive "facilement" à répéter cette lambda partout dans le code (avec tout ce que cela suppose en terme de maintenance)
• Soit elle est utilisée dans le cadre d'un POC pour s'assurer de la faisabilité d'une chose sans commencer à sortir toute "l'artillerie lourde" qui serait nécessaire si on ne l'utilisait pas

Le premier cas m'est inspiré par ce que je considère comme l'impérieuse nécessité de respecter le SRP et, dans une moindre mesure, par l'intérêt que je porte au fameux principe d'Xp: DRY.

Si, pour faire moderne, tu commences à placer des lambda partout, tu risque fort de te retrouver très facilement dans une situation dans laquelle tu te retrouveras à avoir trois, quatre ou N fois exactement la même lambda à des endroits différent du code.

Si, pour une raison ou une autre, tu en viens à devoir la modifier, il est fort probable que tu doives le faire à ces N endroits, avec un risque d'autant plus accru d'en oublier un que N sera important :aie: ;)

Pour le deuxième cas, cela ne me pose pas vraiment de problème, tant qu'il est clairement entendu qu'un POC est un code jetable, qui devra de toutes manières être réécrit une fois que l'on a la preuve de la faisabilité de la chose.

Encore faut il que cette règle du "code jetable" soit respectée :aie:, mais ca, c'est une politique à mettre en place au niveau du projet ;)

De manière générale, je crois personnellement que les lambda sont une bonne chose, tant que l'on n'oublie pas que c'est comme pour tout le reste: il ne suffit pas de se dire qu' "on peut les utiliser" pour qu'il soit opportun de les utiliser, et il ne faut certainement pas se contenter de la seule raison de "faire moderne" pour décider de le faire ;)

Pour moi l'intérêt des lambda est de proposer une alternative au fait de polluer l'API d'une classe (ou une entête de fonctions) par la définition d'un foncteur d'une utilité très spécifique du genre supprimerLesVoyelles. Ça ne veut pas forcément dire que la lambda tient sur une ligne (surtout si on se limite à 80 colonnes de code).

Quelle idée de vouloir mettre les foncteurs dans l'API aussi :)
A priori, la place d'un foncteur est dans un .cpp ou, s'il est utilisé plusieurs fois, dans son propre .h. Donc pas de raison qu'il pollue une API.

Concernant l'utilisation des lambdas nommées et les lambdas de plusieurs lignes, j'ai des doutes aussi. Pour rappel, le C++11 permet d'utiliser des types locaux dans des templates, donc il faut comparer :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

// version avec foncteur void f(vector<X>& v) { struct Less { bool operator()(const X& a, const X& b) { return a.v < b.v; } };   sort(v.begin(), v.end(), Less()); }   // version avec lambda void f(vector<X>& v) { auto Less = [] (const X& a, const X& b) { return a.v < b.v; } sort(v.begin(), v.end(), Less()); }

---

Bref, pour le moment, je suis dubitatif, aussi bien sur leurs utilisations que contre. J'attend d'avoir plus de pratique

Un bon lambda, à mon humble avis, ne devrait faire qu'une instruction, voire deux.

Je découvre quasiment les lambdas (je faisait essentiellement du c# depuis que le dernier standard a commencé à être implémenté dans les compilateurs), et à première vue, j'ai l'impression que ça peut tout de même résoudre un problème que j'avais régulièrement, qui peut se résumer en une question: "où est-ce que je met mes foncteurs?".

Etant un utilisateur acharné de <algorithm> (je commence à me repentir mais c'est une autre histoire), je me retrouvais vite avec de nombreux foncteurs qui polluaient mes zolis en-têtes. Donc oui, dans le cas d'une opération très simple (comme par l'exemple du premier message), je trouve que les lambdas résolvent un problème existant.

Il reste également une piste à regarder: les lambdas, les foncteurs, les pointeurs de fonction, et stl::function (anciennement boost:function) sont interchangeables. Au moins dans les paramètres de fonctions. Peut-être cette propriété ouvre-t-elle de nouveaux horizons?

Citation:

---

Envoyé par gbdivers

Quelle idée de vouloir mettre les foncteurs dans l'API aussi :)
A priori, la place d'un foncteur est dans un .cpp ou, s'il est utilisé plusieurs fois, dans son propre .h. Donc pas de raison qu'il pollue une API.

---

C'est vrai, je reconnais. C'est d'ailleurs ce que j'avais l'habitude de faire en C++03 : des fonctions static au début de mon .cpp. Reste que dans une logique de "déclarez aussi localement que possible" je trouve les lambda plus abouties.

Le pointeur de fonction est une source de variabilité.

Code:

---

1 2 3

void postfix_xml(std::string& s) { s.append("xml"); };

---

Le foncteur rempli un besoin simple, généraliser le pointeur de fonction, pour avoir de la réutilisation paramétrisé.

Code:

---

1 2 3 4 5 6 7

class postfixer{ public: void operator()(std::string& s) const {s.append(postfix);} postfixer(const std::string& s):postfix(s){} private: const std::string& postfix; };

---

La définition d'un lambda n'est pas déportée ailleurs dans le code. Donc, tant qu'il est petit, il peut améliorer la lisibilité.

Pour ce que j'en vois, std::function permet surtout de prendre un lambda en argument.

En fait, moi, ce qui me gène dans les lambdas, c'est leur "non réutilisabilité", ou, si vous préférez, le fait de devoir en copier le code si, d'aventure, nous avons besoin de la même fonctionnalité à différents endroits :aie:

Je ne suis pas contre le principe lorsqu'il s'agit d'implémenter un besoin bien spécifique, dans une fonction qui l'est tout autant, mais ce qui m'inquiète au plus haut point, c'est le risque d'utilisation abusive simplement "parce qu'on peut le faire", tout comme je serai toujours opposé au fait d'utiliser la récursivité là où une simple boucle ferait tout aussi bien l'affaire.

C'est pour cela que je parlais de deux cas qui, AMHA, peuvent justifier l'utilisation des lambda, tout en me réservant, il est vrai, le droit d'en rajouter au fur et à mesure de l'expérience que j'ai des lambda.

Mais, dans l'absolu, je considère qu'il ne faut pas les utiliser uniquement "pour faire moderne" ou "parce qu'on peut le faire" ;)

Je pense que le problème de la répétition est un faux problème. Enfin, disons surtout que ce n'est pas un problème lié aux lambdas.

Il y a du code réutilisable, et il y a du code qui ne l'est pas. Il y a du code à exécution directe, et du code à exécution déportée. Et les 4 combinaisons de ces deux critères ont de l'intérêt, mais sans les lambdas, on manque d'outils pour une des combinaisons (non réutilisable et déporté).

Imaginons une boucle for, si son contenu est réutilisable, on en fait une fonction, sinon on met directement le contenu dans la boucle.
Imaginons maintenant un parallel_for, si son contenu est réutilisable, on en fait un foncteur nommé, sinon, on en fait une lambda.

Après, certains vont ne pas bien respecter le critère réutilisabilité, ou ne pas être d'accord sur la frontière, mais les lambdas n'introduisent pas un nouveau problème, juste une déclinaison d'un problème ancien.

Citation:

---

Envoyé par koala01

En fait, moi, ce qui me gène dans les lambdas, c'est leur "non réutilisabilité", ou, si vous préférez, le fait de devoir en copier le code si, d'aventure, nous avons besoin de la même fonctionnalité à différents endroits :aie:

---

Tu as le problème avec toute expression. Les lambda, c'est juste un moyen d'avoir une expression de type fonction. Si maintenant tu définis une nouvelle fonction dés que tu as une expression plus complexe qu'un appel de fonction, je comprends ton point de vue sur les lambda, sinon, je trouve que tu manques de suite dans les idées.

Attention, comprenons nous quand meme ;)

Je ne suis absolument pas opposé au lambda, je dis juste que nous avons maintenant un nouvel outil qu'il nous appartient d'apprendre à utiliser "à bon escient".

Les lambda sont finalement comme tout le reste, allant de la récurisivité à l'héritage : c'est une possibilité qui nous est donnée, mais il faut faire la part de ce que l'on peut faire parce que le langage nous l'autorise et de ce qu'il est opportun de faire dans une situation donnée.

Le langage nous permettrait (car il n'est pas armé pour nous l'interdire ;)) de faire hériter une voiture d'une baleine, pourtant ce ne serait très certainement pas opportun ;)

De la même manière, les lambda sont certes très intéressantes, mais je me méfie au plus haut point de la seule raison "je voudrais faire moderne".

Comme toute nouvelle fonctionnalité, il va très certainement falloir un "temps de prise en main", et c'est normal, mais je ne serais pas étonné outre mesure que d'ici peu, on voie "fleurir" les "règles de bonnes conduites" à leur sujet, comme "ne peuvent être utilisées que dans telles ou telles circonstances", et on aura raison d'édicter ces "règles de bonnes conduites".

Je serais très embêté le jour où je verrais une expression lambda recopiée encore et encore parce que l'on trouvera que les lambda "c'est moderne", alors qu'un foncteur aurait pu faire la même chose ;)

Je t'accorde volontiers que ce n'est pas un problème propre au lamba, et je l'ai signalé dés le début de mes interventions, mais je tente juste d'attirer l'attention de tous en disant "utilisez les si c'est utile, mais surtout s'il est cohérent de les utiliser" ;)

Je ne vois donc absolument pas en quoi je manque de suite dans les idées en faisant une mise en garde que l'on a déjà fait à de nombreuses reprises, bien que sur des sujets différents ;)

En fait, je pense que l'effet de mode principal qui va apparaître n'est pas tant "on utilise des lambdas partout", mais plutôt "on peut rendre le code customisable partout, parce que grâce aux lambdas, ça devient utilisable".

Par exemple, à l'ancienne mode, si j'ai une classe qui contient un certains nombre de sous objets, mais dont la manipulation n'a pas à être très riche, en plus d'un insert et d'un delete, j'aurais exposé un begin et un end. Maintenant, il y a plus de chances que j'expose uniquement un for_each.

Citation:

---

Envoyé par leternel

Pour ce que j'en vois, std::function permet surtout de prendre un lambda en argument.

---

std::function permet surtout de gommer le type exact, et donc d'avoir une certaine dynamicité autour de ça (par exemple, un pattern observeur, où l'on va enregistrer des lambdas de type différent sous un même chapeau).

Et bien entendu, cette fonctionnalité supplémentaire a un coût en performances.

Citation:

---

Envoyé par koala01

Comme toute nouvelle fonctionnalité, il va très certainement falloir un "temps de prise en main", et c'est normal, mais je ne serais pas étonné outre mesure que d'ici peu, on voie "fleurir" les "règles de bonnes conduites" à leur sujet, comme "ne peuvent être utilisées que dans telles ou telles circonstances", et on aura raison d'édicter ces "règles de bonnes conduites".

---

On n'a jamais qu'un peu plus de 50 ans d'expérience d'utilisation de lambda. Pas dans le cadre de C++, mais la situation n'est pas celle des templates où l'existence des spécialisations partielles a ouvert tout un champs de possibilités, inattendues et sans rapport avec des choses existantes. Personnellement, je suis toujours plus prudent envers ces possibilités qu'envers les lambda, et quand je les emploie, j'ai souvent encore l'impression qu'il devrait y avoir un meilleur moyen de fournir la même chose. J'ai pas encore eu cette impression avec les utilisations que j'ai vue proposées de lambda, même quand il s'agit de les utiliser pour fournir des structures de contrôles. Au contraire, j'ai presque envie de réfléchir au moyen de faire comme en Scala ou dans certains langage de scripts et j'espère que les compilateurs finiront pas être assez intelligent pour optimiser ces utilisations correctement.

Bonsoir,

je déterre ce sujet car ma question est à peu de chose près la même, avec juste une petite complication supplémentaire.

Prenons le code suivant. Nous avons une structure bête, appelons-là Param, définie comme suit:

Code:

---

1 2 3 4 5 6 7

struct Param { Param( const string & name, double value, int index ) : name(name), value( value ), index(index) {} string name; double value; int index; };

---

J'ai maintenant besoin d'une fonction qui applique un filtre sur un vecteur de Param, c'est à dire qu'elle prend en entrée: un vecteur de Param et un filtre, et génère, en sortie, un nouveau vecteur qui ne contiendra que les Param qui ont passé le filtre. Mais ce filtre doit être très générique, afin de pouvoir utiliser cette fonction avec différents filtres. Nous aurions quelque chose comme ça (avec utilisation de std::function afin d'être le plus générique possible):

Code:

---

1 2 3 4 5 6 7

void ApplyFilter( const vector< Param > & params, function< bool (const Param & ) > filter, vector< Param > & result ) { vector< Param >().swap( result ); // clear result for ( auto it = params.begin(); it != params.end(); ++it ) if ( filter( *it ) ) result.push_back( *it ); }

---

Le premier filtre qu'on va implémenter retournera vrai si le name du Param est égal à une string donnée. Comme je ne sais pas le faire autrement, je le fais avec un foncteur:

Code:

---

1 2 3 4 5 6 7 8

struct FilterByName { FilterByName( const Param & param_to_compare ): name_to_compare( param_to_compare.name ) {} bool operator () ( const Param & param ) { return ( param.name == name_to_compare ); } // <-- ça c'est le filtre proprement dit   private: string name_to_compare; };

---

Le main ressemblera à ça:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#include <iostream> #include <functional> #include <vector> #include <string>   using namespace std;   // struct Param // fonction ApplyFilter // foncteur FilterByName   main() { vector<Param> params; params.push_back( Param( "toto", 1.354, 1 ) ); params.push_back( Param( "titi", 1.354, 2 ) ); params.push_back( Param( "toto", 2.354, 3 ) ); vector<Param> filtered_params;   ApplyFilter( params, FilterByName( params[0] ), filtered_params ); //...

---

Ce code fonctionne et fais ce qui est demandé. Le résultat du main (le vecteur filtered_param) sera le même que le vecteur param mais sans les Param dont name est différent de "toto").

Mais maintenant, je voudrais remplacer mon foncteur FilterByName par une fonction lambda. Est-ce possible? Si oui comment?

Bonjour

Sans répondre à tes questions, 3 remaques :
* ce que tu veux faire, c'est un remove_copy_if, non ?
* c'est quoi ce swap moche pour faire un clear ?
* souvent, pour des questions de généricité (pour pas cher), on utilise des iterateurs et non un conteneur directement
* par similarité avec les algo de la STL, c'est préférable de passer tous les iterateurs puis le filtre à la fin (cela permet de s'y retrouver plus facilement entre les versions des algo avec et sans prédicat personnalisés)

EDIT : pour le lambda : ta fonction dois capturer params[0], dois prendre 1 paramètre Param const& (cf la définition de ApplyFilter) et retourne un bool :

Code:

---

1 2 3

ApplyFilter(params, [=] (Param const& p) { return p.name == params[0].name; }, filtered_params );   remove_copy_if(begin(params), end(params), begin(filtered_params), [=] (Param const& p) { return p.name != params[0].name; });

---

(attention à l'inversion du prédicat)

Citation:

---

Envoyé par gbdivers

ce que tu veux faire, c'est un remove_copy_if, non ?

---

Exactement, mais ce code c'est juste pour comprendre les lambdas.

Citation:

---

Envoyé par gbdivers

c'est quoi ce swap moche pour faire un clear ?

---

pourquoi est-ce moche?

Citation:

---

Envoyé par gbdivers

souvent, pour des questions de généricité (pour pas cher), on utilise des iterateurs et non un conteneur directement

---

J'avais pensé utiliser un template plutôt (templatiser ApplyFilter). Quelle est la "meilleure" solution à ton avis?

Citation:

---

Envoyé par gbdivers

par similarité avec les algo de la STL, c'est préférable de passer tous les iterateurs puis le filtre à la fin (cela permet de s'y retrouver plus facilement entre les versions des algo avec et sans prédicat personnalisés)

---

ok.

Sinon, j'avais résolu mon problème entre temps, et je suis tombé exactement sur le même code que toi :aie:
souvent, coucher sur papier un problème aide grandement à le résoudre :)

Aïe gbdivers, ta lambda est un monstre :aie:. Je développe plus en détail dans Pourquoi la capture aveugle est-elle dangereuse ?, mais là tu copies un vector complet sans que ça te choque :aie:

Code:

---

1 2 3 4 5 6

const auto &param0name(params[0].name);   ApplyFilter(params, [param0name](Param const& p){ return p.name == param0name; }, filtered_params);   remove_copy_if(begin(params), end(params), begin(filtered_params), [param0name](Param const& p){ return p.name != param0name; });

---

*germinolegrand commence à être fatigué de recopier ce qui est marqué dans son article tous les 3 topics :aie:*

Citation:

---

Envoyé par r0d

pourquoi est-ce moche?

---

Parce qu'un clear sert à effacer et un swap à échanger. En utilisant du code qui ne fait pas explicitement ce qu'il dit qu'il fait, ça peut être source d'erreur (ok, très faible dans ce cas là) D'autant plus que je doute ici de l'intérêt

Citation:

---

Envoyé par r0d

J'avais pensé utiliser un template plutôt (templatiser ApplyFilter). Quelle est la "meilleure" solution à ton avis?

---

Template ou non, c'est un autre problème (les algos de la STL utilisent aussi des templates pour les types des itérateurs). Donc dans tous les cas, template

Conteneur ou itérateur ? C'est par habitude de la STL. Mais peut être qu'il faudrait revoir l'habitude (en prenant exemple sur range based for ?)

@germinoland
Oui, je fais le barbare avec la capture de tout ce qui traîne... et oui, j'ai des doutes quand à l'utilisation de [=] (déjà parlé de ce problème)... et oui, utiliser la copie ici est moisi :)

Sinon, rien me choque moi :) (et puis j'utilise des QVector avec le COW moi, pas de problème)

Citation:

---

Envoyé par germinolegrand

*germinolegrand commence à être fatigué de recopier ce qui est marqué dans son article tous les 3 topics :aie:*

---

Il est où ton article? :)

Citation:

---

Envoyé par gbdivers

Parce qu'un clear sert à effacer et un swap à échanger. En utilisant du code qui ne fait pas explicitement ce qu'il dit qu'il fait, ça peut être source d'erreur (ok, très faible dans ce cas là) D'autant plus que je doute ici de l'intérêt

---

Le problème du clear() c'est qu'il ne libère pas la mémoire (et accessoirement, la capacité reste inchangée), ce qui ne me plait pas très bien beaucoup. D'ailleurs, cette étrange logique (selon moi), m'a fais faire des erreurs graves dans le passé :/

Citation:

---

Envoyé par gbdivers

Conteneur ou itérateur ?

---

Telle est, effectivement, la question existentielle... En fait, j'ai en tête l'exemple de la fonction generate(), dont la logique ne me plait pas trop car il faut connaitre la taille du conteneur généré avant l'appel (ou utiliser un back_inserter_iterator ou une étrangeté dans le genre, et je n'aime pas très beaucoup trop ça). Du coup je pencherais plutôt vers la templatization du conteneur, mais sans vraiment y avoir réfléchi plus avant.

Citation:

---

Envoyé par r0d

pourquoi est-ce moche?

---

Car le swap trick peut s'écrire un peu plus simplement en C++11 :

Code:

---

vector< Param >().swap( result ); // clear result

---

est équivalent à:

Code:

---

1 2	result.clear(); // size() à zéro, capacity() inchangée, result.shrink_to_fit(); // capacity() à zéro, toute la mémoire est libérée

---

C'est un poil plus parlant à mon gout.

Autre chose, perso je pense que je ne passerais pas le vecteur filter_param par référence, autant le renvoyer directement comme valeur de retour de la fonction ApplyFilter. Ca simplifie pas mal le code et les perfs seront identiques de toute façon :

Code:

---

1 2 3 4 5 6 7 8 9

std::vector<Param> ApplyFilter( const vector< Param > & params, function< bool (const Param & ) > filter) { std::vector<Param> result; for ( const Param& p = params) // range-based for, un poil plus lisible AMHA if ( filter( p ) ) result.push_back( p ); return result; }

---

Citation:

---

Envoyé par gbdivers

ce que tu veux faire, c'est un remove_copy_if, non ?

---

Il est faux le code qui illustre le remove_copy_if car il va copier brutalement dans filtered_params alors que la taille du vecteur vaut zéro. Il faudrait rajouter un back_inserter quelques part et l'écriture devient assez ragoutante. Je trouve la boucle for beaucoup plus simple :

Code:

---

1 2 3

for ( const Param& p : params) if ( filter( p ) ) result.push_back( p );

---

Pour le coup de la capture [=] en effet on copie inutilement tout le vecteur params juste pour pouvoir récuperer params[0].name ce n'est pas terrible. :aie:
Dans l'exemple présenté il n'y a clairement pas de problème de durée de vie donc on peut simplement prendre par référence :

Code:

---

ApplyFilter(params, [&] (Param const& p) { return p.name == params[0].name; }, filtered_params );

---

Et si on veut être explicite pour la capture :

Code:

---

ApplyFilter(params, [&params] (Param const& p) { return p.name == params[0].name; }, filtered_params );

---

Citation:

---

Envoyé par r0d

J'avais pensé utiliser un template plutôt (templatiser ApplyFilter). Quelle est la "meilleure" solution à ton avis?

---

ça c'est vraiment une bonne question. J'ai souvent le même problème. Est-ce qu'il vaut mieux en C++11 garder le style STL et passer un template qui acceptera tout et n'importe quoi ou est-ce qu'il vaut mieux utiliser maintenant une std::function ? Je me demande s'il existe des guidelines à ce sujet car ce n'est vraiment pas clair pour moi.

@Arzar
Pour le back_inserter et le [=], effectivement.

Pour le range based for, c'est une question de lisibilité et d'habitude. J'aime bien quand même les algos, qui ont un nom explicite (on va relancer la discussion "faut il bannir for du C++ ?" :aie:)

Pour le template, il y a ceux concernant les itérateurs, qu'il faut de toute façon utiliser. Toi, tu parles du template pour le prédicat. On peut effectivement utiliser une std::fonction, et dans ce cas les paramètres de la fonctions sont explicites, alors qu'avec un template pour le prédicat, il faut indiquer la définition que doit prendre la fonction dans la doc. La première est plus explicite pour l'utilisateur, la seconde plus simple pour le dév :) Donc je dirais que std::function est a priviligier (par contre, même avec la version avec template, on peut pas mettre n'importe quoi, la def de la fonction est quand même testé à la compilation)

Citation:

---

Envoyé par r0d

Il est où ton article? :)

---

En cours de rédaction, mais j'ai l'impression que plus tôt il sera fini, plus je m'éviterai de copier-collé :mouarf: (c'est la 3e fois en 2 jours que je fais du pur copier collé de son contenu xD)

Citation:

---

Envoyé par gbdivers

et oui, utiliser la copie ici est moisi :)

---

Par flemme de rajouter une ref const un peu inutile, j'aurais tendance avec les algos STL à prendre tout bêtement le vector par référence puisque je suis assuré que l'utilisation de ma lambda ne sortira pas du cadre de la fonction de l'algo... j'aurais peut-être dû montre de cette façon, la copie par ref const étant réservée aux utilisations un peu moins cadrées des lambdas (genre stockage extérieur, etc.).

Pour le clear qui ne remet pas la taille à zéro, shrink_to_fit juste après permet de bien remettre tout à zéro ;)

Citation:

---

Envoyé par gbdivers

(on va relancer la discussion "faut il bannir for du C++ ?" :aie:)

---

Quelle étrange question. Il y a des gens qui se la posent, sérieusement?

oui. Même si c'est clairement du troll pur et simple tel que c'est posé, c'est une question qui mérite vraiment réflexion...

Citation:

---

Envoyé par r0d

Quelle étrange question. Il y a des gens qui se la posent, sérieusement?

---

Bien sur que non, personne n'oserait poser cette question sérieusement. Ou pas... Faut-il bannir le for du C++ ?

Au delà de l'aspect volontairement trollesque dans la rédaction de la question, il y a quand même des questions de fond intéressantes (et de nombreuses remarques et interrogations pertinentes). En particulier sur l'expressivité du code (ie utiliser des noms qui disent ce qu'ils font), ce qui rejoint les interrogations exprimées ici sur l'utilisation des lambdas et des range based for.