Discussion :

[Jean-Marc.Bourguet]

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

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.

[koala01]

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

[JolyLoic]

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.

[JolyLoic]

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.

[Jean-Marc.Bourguet]

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.

[r0d]

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 :

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

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 :

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

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 :

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

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 :

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

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?

[gbdivers]

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 :

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

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)

[r0d]

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

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

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

pourquoi est-ce moche?

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?

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
souvent, coucher sur papier un problème aide grandement à le résoudre

[germinolegrand]

Aïe gbdivers, ta lambda est un monstre . 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

Code :

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

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 *

[gbdivers]

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

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 ?)

[gbdivers]

@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)

[r0d]

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

Il est où ton article?

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é :/

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.

[Arzar]

pourquoi est-ce moche?

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

Code :

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

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

est équivalent à:

Code :

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

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 :

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

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

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 :

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

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.
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 :

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

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

Et si on veut être explicite pour la capture :

Code :

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

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

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.

[gbdivers]

@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++ ?" )

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)

[germinolegrand]

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é (c'est la 3e fois en 2 jours que je fais du pur copier collé de son contenu xD)

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

[r0d]

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

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

[germinolegrand]

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...

[gbdivers]

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.