Discussion :

[bolhrak]

Bonsoir,

En voulant implémenter les algorithmes de la bibliothèques standards afin de pouvoir les utiliser avec des fonctions prenant un ou plusieurs arguments, je me suis naturellement orientés vers boost/bind. Un bout de code étant plus parlant qu'une longue explication, voici ce que j'obtiens pour l'algorithe for_each, acceptant un pointeur de membre prenant lui même un argument :

Code :

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

1
2
3
4
5
 
template<Iterator It, class T, class R, class Op>
for_each(It first, It last, R (T::*pmf), boost::call_traits<Op>::parameter_type op) {
    std::for_each(first, last, boost::bind(pmf, _1, op));
}

Le problème est que boost::bind contient une copie interne des paramètres qu'on lui passe (ici op). DU coup l'avantage de l'utilisation de call_traits est perdu. Ma question est de savoir comment invoquer

Code :

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

1
2
 
std::for_each(first, last, boost::bind(pmf, _1, cref(op)))

plutôt que le code précédent lorsque call_traits<Op>::parameter_type est une référence. La spécialisation de template n'est pas vraiment une option envisageable, étant donné qu'avec un pointeur de fonction membre acceptant beaucoup de paramètres, on va devoir écrire beaucoup de code. Idem pour des structures if testant call_traits<Op>::parameter_type. Y'a-t-il une solution plus élégante ?

Merci d'avance.

[Laurent Gomila]

En voulant implémenter les algorithmes de la bibliothèques standards afin de pouvoir les utiliser avec des fonctions prenant un ou plusieurs arguments

J'ai du mal à saisir l'intérêt ?

Ma question est de savoir comment invoquer
[...]
plutôt que le code précédent lorsque call_traits<Op>::parameter_type est une référence

Au pif de tête au réveil :

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
template <typename T> struct Truc
{
    static T Param(T op) {return op;}
};
template <typename T> struct Truc<T&>
{
    static ... Param(T& op) {return cref(op);}
};
template <typename T> struct Truc<const T&>
{
    static ... Param(const T& op) {return cref(op);}
};
 
template<Iterator It, class T, class R, class Op>
for_each(It first, It last, R (T::*pmf), boost::call_traits<Op>::parameter_type op)
{
    std::for_each(first, last, boost::bind(pmf, _1, Truc<...>::Param(op)));
}

[bolhrak]

L'interet est de :
1) Restreindre la dependance a bind dans un seul fichier
2) Alleger l'ecriture du code :

Code :

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

1
2
 
util::for_each(list.begin(), list.end(), &T::pmf, arg);

est plus agreable que

Code :

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

1
2
 
std::for_each(list.begin(), list.end(), boost::bind(&T::pmf, _1, arg));

(enfin je trouve :p)

Sinon j'avais pense a une solution du meme genre que la tienne :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
template <class T> struct bind_param_type {
 
typedef typename boost::mpl::if_<boost::is_reference<T>,
                                 boost::reference_wrapper<T>,
                                 T>::type;
}
 
// ....
 
std::for_each(first, last, bind_param_type<...>::type(arg);

Mais la tienne permet en plus de differencier les references constantes des references non constantes (bon ce serait possible aussi avec la solution exposee mais ca deviendrait tout de suite beaucoup moins lisible), et est mois lourde a implementer :p. La seule chose qui m'ennuie est pour les parametres passes par valeur (dans les deux cas), on a une copie supplementaire, et je ne vois pas de moyen de l'eviter (je ne suis meme pas sur que ce soit possible). Donc a defaut de trouver comment eviter cette copie je vais utiliser ton implementation,

Merci beaucoup pour l'aide.

[Laurent Gomila]

A partir du moment où tu utilises boost::call_traits<T>::param_type, dont le but est de passer par valeur les paramètres pour lesquels ça ne coute "pas cher", alors faire une copie ou (en fait trois ici -- sans optimisation) ne devrait pas vraiment être un problème.