Discussion :

[TH-Gemini]

Bonjour,

je poursuis mon exploration de parties de la STL que j'avais jusqu'� pr�sent h�las n�glig� : les algorithmes, et notamment, pour le cas qui nous int�resse, std::for_each et std::transform

Je pense avoir correctement saisi leur fonctionnement dans plusieurs cas de figures, mais bien �videmment, je n'y suis pas encore parvenu pour le mien

Je dispose d'une classe qui a, comme variable interne :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

 std::map<unsigned int, Parcours_Utilisateur> m_m_Etat_Parcours_Utilisateur;

Dans une des fonctions membre de cette classe, je souhaite parcourir cette std::map, pour, en fonction d'un param�tre connu de cette seule fonction, y apporter d'�ventuelles modifications. � ce jour, j'ai �a :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
bool ConnecteurClientImpl::supprime_Client_Connecte(int i_Identifiant_Client)
{
    std::list<int> l_Temporaire(m_m_Etat_Parcours_Utilisateur.size(), i_Identifiant_Client );
    std::transform(m_m_Etat_Parcours_Utilisateur.begin(), m_m_Etat_Parcours_Utilisateur.end(), l_Temporaire.begin(), m_m_Etat_Parcours_Utilisateur.begin(), action_Sur_Suppression_Client());
}

Ce code ne passe pas � la compilation car il semblerait qu'il n'accepte pas un it�rateur sur un std::pair pour l'it�rateur dans lequel il doit �crire les r�sultats. D'o� ma premi�re question : est-ce possible ?

Le second point qui ne me satisfait pas, c'est que afin de pouvoir communiquer � la fonction pass�e en param�tre de l'algorithme le param�tre i_Identifiant_Client, je n'ai pas trouv� mieux que de cr�er une liste et de la passer en tant que second it�rateur de parcours pour le second param�tre de la fonction appel�e. Y avait-il moyen de faire mieux ou plus �l�gants pour que la fonction action_Sur_Suppression_Client() puisse conna�tre i_Identifiant_Client ?


Troisi�me point : cette fonction est aujourd'hui d�finie comme une fonction objet. Pourquoi pas, sauf que j'aurais pr�f�r� en faire une fonction membre de la classe ConnecteurClientImpl. Est-ce possible ?*Toutes mes tentatives ont �t� vaines, mais peut-�tre est-ce d� � mon manque de ma�trise des pointeurs de fonction et approchants �. Je n'y suis parvenu que si la fonction �tait statique, ce que je ne d�sire pas.


Enfin, quatri�me et dernier point : les diff�rences entre for_each et transform ne sont pas toujours �videntes et ce que j'ai pu lire suite � mes recherches est contradictoire : il est affirm� dans une de mes lectures que for_each peut appeler des fonctions � effet de bord, alors que transform ne doit pas.

Dans les cours C++, c'est quasi l'inverse qui y est expliqu� : for_each ne doit en aucun cas modifier le contenu des it�rateurs qu'il parcourt alors que transform, si.

Lequel a raison ? Ou bien c'est moi qui ai mal compris le terme � side effect � du premier article qui est en anglais �

Merci une nouvelle fois � ceux qui pourront m'apporter leurs lumi�re � ma compr�hension incompl�te.

[3DArchi]

(Re),

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
bool ConnecteurClientImpl::supprime_Client_Connecte(int i_Identifiant_Client)
{
    std::list<int> l_Temporaire(m_m_Etat_Parcours_Utilisateur.size(), i_Identifiant_Client );
    std::transform(m_m_Etat_Parcours_Utilisateur.begin(), m_m_Etat_Parcours_Utilisateur.end(), l_Temporaire.begin(), m_m_Etat_Parcours_Utilisateur.begin(), action_Sur_Suppression_Client());
}

Ce code ne passe pas � la compilation car il semblerait qu'il n'accepte pas un it�rateur sur un std::pair pour l'it�rateur dans lequel il doit �crire les r�sultats. D'o� ma premi�re question : est-ce possible ?

Oui. Il faut continuer � explorer la STL
En fait, il faut regarder du c�t� des it�rateurs d'insertion (<iterator>) et utiliser un std::inserter pour le r�sultat. Le foncteur devra bien s�r retourner une pair. Exemple :

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
#include <iostream>
#include <map>
#include <list>
#include <algorithm>
#include <iterator>
#include <sstream>
 
struct foncteur
{
   std::pair<int,int> operator()(std::pair<int,int>const&map_assoc_, int list_item_)const
   {
      return std::pair<int,int>(map_assoc_.first,map_assoc_.second+list_item_);
   }
};
 
struct output_foncteur
{
   std::string operator()(std::pair<int,int>const&map_assoc_)const
   {
      std::ostringstream oss117;
      oss117<<"["<<map_assoc_.first<<"] = "<<map_assoc_.second;
      return oss117.str();
   }
};
 
int main()
{
   std::map<int,int> mon_map;
   mon_map[0] = 0;
   mon_map[1] = 1;
   mon_map[2] = 2;
   mon_map[3] = 3;
   mon_map[4] = 4;
   std::list<int> ma_liste;
   ma_liste.push_back(0);
   ma_liste.push_back(1);
   ma_liste.push_back(2);
   ma_liste.push_back(3);
   ma_liste.push_back(4);
   std::map<int,int> resultat;
   std::transform(
      mon_map.begin(),
      mon_map.end(),
      ma_liste.begin(),
      std::inserter(resultat,resultat.begin()),
      foncteur()
   );
 
   std::transform(
      resultat.begin(),
      resultat.end(),
      std::ostream_iterator<std::string>(std::cout,"\n"),
      output_foncteur()
   );
 
   return 0;
}

Le second point qui ne me satisfait pas, c'est que afin de pouvoir communiquer � la fonction pass�e en param�tre de l'algorithme le param�tre i_Identifiant_Client, je n'ai pas trouv� mieux que de cr�er une liste et de la passer en tant que second it�rateur de parcours pour le second param�tre de la fonction appel�e. Y avait-il moyen de faire mieux ou plus �l�gants pour que la fonction action_Sur_Suppression_Client() puisse conna�tre i_Identifiant_Client ?

Toujours la STL : bind1st dans functional. Mais, l� je te conseille une fonction libre plut�t qu'un foncteur :

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
#include <iostream>
#include <map>
#include <list>
#include <algorithm>
#include <iterator>
#include <sstream>
#include <functional>
 
std::pair<int,int> foncteur(std::pair<int,int>map_assoc_, int increment)
{
   return std::pair<int,int>(map_assoc_.first,map_assoc_.second+increment);
}
 
struct output_foncteur
{
   std::string operator()(std::pair<int,int>const&map_assoc_)const
   {
      std::ostringstream oss117;
      oss117<<"["<<map_assoc_.first<<"] = "<<map_assoc_.second;
      return oss117.str();
   }
};
 
int main()
{
   std::map<int,int> mon_map;
   mon_map[0] = 0;
   mon_map[1] = 1;
   mon_map[2] = 2;
   mon_map[3] = 3;
   mon_map[4] = 4;
   std::map<int,int> resultat;
   std::transform(
      mon_map.begin(),
      mon_map.end(),
      std::inserter(resultat,resultat.begin()),
      std::bind2nd(std::ptr_fun(foncteur),10)
   );
 
   std::transform(
      resultat.begin(),
      resultat.end(),
      std::ostream_iterator<std::string>(std::cout,"\n"),
      output_foncteur()
   );
 
   return 0;
}

Si d'aventure tu avais vraiment besoin d'un foncteur, alors le plus simple serait de passer par Boost.Bind, car la STL apr�s 2 arguments, elle ne sait plus faire

Troisi�me point : cette fonction est aujourd'hui d�finie comme une fonction objet. Pourquoi pas, sauf que j'aurais pr�f�r� en faire une fonction membre de la classe ConnecteurClientImpl. Est-ce possible ?*Toutes mes tentatives ont �t� vaines, mais peut-�tre est-ce d� � mon manque de ma�trise des pointeurs de fonction et approchants �. Je n'y suis parvenu que si la fonction �tait statique, ce que je ne d�sire pas.

Pour utiliser une fonction membre comme foncteur : std::bind1st comme vu avec std::mem_fun toujours dans <functional>. Mais avec la STL, si ta fonction a plus d'un argument, �a ne le fait pas. L� aussi, il faudrait passer par boost
:

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
#include <iostream>
#include <map>
#include <list>
#include <algorithm>
#include <iterator>
#include <sstream>
 
struct output_foncteur
{
   std::string operator()(std::pair<int,int>const&map_assoc_)const
   {
      std::ostringstream oss117;
      oss117<<"["<<map_assoc_.first<<"] = "<<map_assoc_.second;
      return oss117.str();
   }
};
 
struct ma_struct
{
   int mon_increment;
   void just_do_it()
   {
      std::map<int,int> mon_map;
      mon_map[0] = 0;
      mon_map[1] = 1;
      mon_map[2] = 2;
      mon_map[3] = 3;
      mon_map[4] = 4;
      std::map<int,int> resultat;
      mon_increment = 10;
      std::transform(
         mon_map.begin(),
         mon_map.end(),
         std::inserter(resultat,resultat.begin()),
         std::bind1st(std::mem_fun(&ma_struct::do_operation),this)
      );
 
      std::transform(
         resultat.begin(),
         resultat.end(),
         std::ostream_iterator<std::string>(std::cout,"\n"),
         output_foncteur()
      );
   }
   std::pair<int,int> do_operation(std::pair<int,int> map_assoc_)const
   {
      return std::pair<int,int>(map_assoc_.first,map_assoc_.second+mon_increment);
   }
};
 
 
int main()
{
   ma_struct().just_do_it();
   return 0;
}

Enfin, quatri�me et dernier point : les diff�rences entre for_each et transform ne sont pas toujours �videntes et ce que j'ai pu lire suite � mes recherches est contradictoire : il est affirm� dans une de mes lectures que for_each peut appeler des fonctions � effet de bord, alors que transform ne doit pas.

Dans les cours C++, c'est quasi l'inverse qui y est expliqu� : for_each ne doit en aucun cas modifier le contenu des it�rateurs qu'il parcourt alors que transform, si.

Lequel a raison ? Ou bien c'est moi qui ai mal compris le terme � side effect � du premier article qui est en anglais �

Merci une nouvelle fois � ceux qui pourront m'apporter leurs lumi�re � ma compr�hension incompl�te.

Je ne les aie pas lu. Donc difficile de te r�pondre.

La lecture du jour : Les algorithmes de la STL, par notre ami r0d

[Emmanuel Deloget]

std::for_each(first,last,op) peut �tre appel� pour modifier les �l�ments d'un range - je ne vois pas de probl�me avec �a, et la norme non plus. L'op�ration effectu�e est op(*(first + n)), mais op a tout � fait le droit de prendre une r�f�rence non constante en param�tre et donc de modifier *(first + n).

std::transform(first,last,result,op) est utilis� pour transformer les valeurs dans un range en d'autres valeurs - avec le foncteur correspondant. Si n�cessaire, la transformation peut se faire 'en place' (first == result) puisque transform effectue l'op�ration suivant : *(result + n) = op(*(first + n)). Ceci dit, lorsqu'on utilise cette transformation en place, il convient de se demander si le jeu en vaut la chandelle - on risque de forcer l'appel � l'op�rateur de copie alors que ce n'est pas n�cessaire (autant utiliser for_each()). Bien �videmment, la question ne se pose plus si on utilise la forme de transform qui prends deux range en entr�e (std::tranform(first1, last1, first2, result, binary_op), ou l'op�ration effectu�e est *(result + n) = binary_op(*(first1 + n), *(first2 + n)).

Et pour r�pondre � ta question, le probl�me vient de action_Sur_Suppression_Client(), qui ne doit pas prendre les bons param�tres ou renvoyer le bon type. Cette classe doit �tre d�finie comme :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
struct action_Sur_Suppression_Client
{
  int operator()(const std::pair<unsigned int, Parcours_Utilisateur>& valeur)
  { ... }
};

[3DArchi]

J'ai survol� les 2 articles. La confusion vient de ce que l'on peut ou non modifier.
std::for_each prend 2 arguments, un range (begin,end) et un foncteur qui s'applique sur chaque �l�ment du range.
Se pose trois questions :

1. Peut-on modifier le range ?
2. Peut-on modifier le foncteur ?
3. Peut-on modifier l'�l�ment donn� en param�tre ?

(1) : non (pour des raisons �videntes).
(2) : le premier article dit oui et je suis convaincu par l'argumentaire. Rien dans la norme n'indique le contraire et je n'ai pas vu d'exemple o� le compilateur r�le.
(3) : oui. Selon que le param�tre sera pris par r�f�rence ou par r�f�rence constante (ou valeur), on pourra ou non modifier le param�tre.

std::transform prend 3 arguments : un range (begin,end), un it�rateur d'insertion et un foncteur qui prend en argument l'�l�ment et retourne la valeur qui est assign�e au second it�rateur.

Se pose quatre questions :

1. Peut-on modifier le range ?
2. Peut-on modifier l'it�rateur ?
3. Peut-on modifier le foncteur ?
4. Peut-on modifier l'�l�ment donn� en param�tre ?

(1) : non (pour des raisons �videntes).
(2) : std::transform le fait pour toi en ajoutant le r�sultat du foncteur et en incr�mentant l'it�rateur.
(3) : non : c'est ce que dit l'article en anglais et l'explication me semble pertinente : tu ne peux modifier le foncteur car l'ordre d'appel n'�tant pas garanti, tu ne ma�trises pas les effets de bords. Et la norme est tr�s clair l� dessus :

op and binary_op shall not have any side effects.

(4) � mon avis la question la plus d�licate. La norme dit que le foncteur ne doit pas avoir d'effet de bord. Donc en toute logique, la r�ponse devrait �tre non.

Il s'en suit que pour std::for_each, les foncteurs peuvent �tre :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
 
struct foncteur
{
    void operator()(std::pair<int const ,int>&map_assoc_); // tout est modifiable
    void operator()(std::pair<int const ,int>&map_assoc_)const;  // on peut modifier le paramètre mais pas le foncteur
    void operator()(std::pair<int const ,int>const &map_assoc_); // on peut modifier le foncteur mais pas le paramètre
    void operator()(std::pair<int const ,int>&map_assoc_)const; // on peut rien modifier
};

Et pour std::transform:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
 
struct foncteur
{
    void operator()(std::pair<int const ,int>&map_assoc_)const; // on peut rien modifier
};

[3DArchi]

Et pour r�pondre � ta question, le probl�me vient de action_Sur_Suppression_Client(), qui ne doit pas prendre les bons param�tres ou renvoyer le bon type. Cette classe doit �tre d�finie comme :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
struct action_Sur_Suppression_Client
{
  int operator()(const std::pair<unsigned int, Parcours_Utilisateur>& valeur)
  { ... }
};

J'ai plut�t l'impression que son probl�me vient du dernier it�rateur, celui qui re�oit le r�sultat de la transformation. C'est le begin() d'un map. Et l'it�rateur d'un map ne peut �tre utilis� pour ajouter ou mettre � jour des �l�ments dans la map. D'o� la n�cessit� de passer par un std::inserter.

[Emmanuel Deloget]

J'ai plut�t l'impression que son probl�me vient du dernier it�rateur, celui qui re�oit le r�sultat de la transformation. C'est le begin() d'un map. Et l'it�rateur d'un map ne peut �tre utilis� pour ajouter ou mettre � jour des �l�ments dans la map. D'o� la n�cessit� de passer par un std::inserter.

Tu sous-entends que j'ai mal lu le post de TH-Gemini ?

Attention hein, ce n'est pas parce que c'est vrai que je vais me laisser faire. J'ai ma fiert� moi monsieur (et un mal de crane carabin� depuis 2 jours. Tiens, et si j'allais voir un m�decin ?)

[3DArchi]

Tu sous-entends que j'ai mal lu le post de TH-Gemini ?

Pour �tre franc, c'est parce que j'ai eu le m�me r�flexe que toi : le PO a du se tromper sur la signature du foncteur, chose assez courante avec un map. Puis, je me suis dit que le message �tait suffisamment long et argument� pour que ce ne soit pas ce type d'erreur. J'ai regard� � plusieurs reprises le code avant de voir le probl�me sur l'it�rateur r�sultat.

et un mal de crane carabin� depuis 2 jours. Tiens, et si j'allais voir un m�decin ?)

2 approches :
-> la chimie EST-UN progr�s dont il faut savoir b�n�ficier ;
-> il faut laisser le temps au temps et accepter la souffrance.

[TH-Gemini]

Encore une fois, merci pour vos pr�cieuses informations. Je testerai les suggestions de 3DArchi d�s que je parviendrais � trouver un petit peu de temps. Son diagnostic semble le bon, car c'�tait bien sur le param�tre it�rateur r�sultat que se situait mon probl�me.

Je vais en profiter pour d�couvrir un peu mieux les diff�rents types d'it�rateur, en esp�rant que j'y trouverai bient�t des cas d'utilisation pour me faire la main avec.

Concernant mon message initial, j'aurais peut-�tre d� �galement pr�ciser le foncteur action_Sur_Suppression_Client(), ce qui aurait permis d'�viter de cr�er la confusion. Pas taper je ferais mieux la prochaine fois Le mal de t�te devrait ainsi vite passer