Afficher le contenu d'une collection via std::for_each ?

Bonjour à tous,

Je pense avoir vu dans le temps une astuce permettant d'afficher le
contenu d'une collection via std::for_each.

Je ne me souviens plus du tout de la manière et cela m'ennuie un peu.

std::for_each (Container.begin (), Container.end (), ...);

Je pense que cette astuce permettait aussi de définir un objet basé sur
la classe std::ostream.

Quelqu'un a-t-il une idée ?

Le moyen le plus simple fourni par la STL pour afficher le contenu d'une
collection passe par std::copy, et std::ostream_iterator<>. C'est ça que
tu cherches?

#include <iterator>
#include <vector>
#include <algorithm>
#include <iostream>

using namespace std;

// ....
vector<int> vec;
// ....
copy( vec.begin(), vec.end(), ostream_iterator<int>( cout, "n" ) );

--
Hopp Schweiz!
Forza Korea!
Go Togo!

Le moyen le plus simple fourni par la STL pour afficher le contenu d'une
collection passe par std::copy, et std::ostream_iterator<>. C'est ça que
tu cherches?

copy( vec.begin(), vec.end(), ostream_iterator<int>( cout, "n" ) );

Il se peut que cela bien cela, en fait, je ne me souviens plus si
c'était avec std::copy ou std::for_each.

En plus, je n'avais pas pensé à std::copy.

Mercy Cyrille,

Bonne journée,

#include <iterator>
#include <vector>
#include <algorithm>
#include <iostream>

using namespace std;

// ....
vector<int> vec;
// ....
copy( vec.begin(), vec.end(), ostream_iterator<int>( cout, "n" ) );
Par contre, je ne pense pas que cela puisse fonctionner avec un

conteneur associatif.

Qu'en penses-tu ?

Stéphane Wirtel wrote:

copy( vec.begin(), vec.end(), ostream_iterator<int>( cout, "n" ) );
Par contre, je ne pense pas que cela puisse fonctionner avec un

conteneur associatif.

Avec Boost, on peut faire

#include <boost/lambda/lambda.hpp>
...
std::for_each(v.begin(), v.end(), std::cout << boost::lambda::_1 << ' ');


Pour std::map, c'est un brin plus compliqué :

#include <boost/lambda/bind.hpp>
#include <boost/lambda/lambda.hpp>
...
typedef std::map<toto_type, titi_type> MyMap;
MyMap m;
// ... remplissage de 'm'
using namespace boost::lambda;
std::for_each(m.begin(), m.end(),
std::cout << bind(&MyMap::value_type::first, _1) << 't'
<< bind(&MyMap::value_type::second, _1) << 'n');

Falk

#include <iterator>
#include <vector>
#include <algorithm>
#include <iostream>

using namespace std;

// ....
vector<int> vec;
// ....
copy( vec.begin(), vec.end(), ostream_iterator<int>( cout, "n" ) );

Par contre, je ne pense pas que cela puisse fonctionner avec un
conteneur associatif.

Qu'en penses-tu ?

Un conteneur associatif contient en fait des std::pair<Key, value>.
Pour que ça marche, il faut que le compilateur sache comment afficher
des std::pair<>.

On le lui dit de cette manière:

namespace std // cf plus loin (*)
{
ostream& operator << (ostream &out, pair<int, double> const &arg)
{
out << arg.first << "t" << arg.second;
return out;
}
}


et ça s'utilise ainsi:

int main()
{
map<int, double> liste;
liste[4] = .5f;
liste[2] = 1.2f;

copy( liste.begin(), liste.end(), ostream_iterator<pair<int, double> >(
cout, "n" ) );

return 0;
}

Surcharger l'opérateur << pour les std::pair, ça ne marche que si on met
la définition de l'opérateur << dans l'espace de nom std. En fait, les
deux arguments de la fonction (out et arg) se trouvant dans std, le
compilateur ne cherchera la fonction que dans cet espace de nom lors de
la résolution de surcharge (règle dite du Koenig Lookup, je crois, mais
je suis pas sûr de moi, là).

--
Hopp Schweiz!
Forza Korea!
Go Togo!

Par contre, je ne pense pas que cela puisse fonctionner avec un
conteneur associatif.

Avec Boost, on peut faire

#include <boost/lambda/lambda.hpp>
...
std::for_each(v.begin(), v.end(), std::cout << boost::lambda::_1 << ' ');
A ce que je peux voir la boost contient pas mal de subtilité, dommage

que j'ai du mal à compiler la toute dernière version sous windows. Je
vais réessayer avant ce soir avec g++ de mingw 5.0

Merci en tout cas,

Stef

Cyrille wrote:

Je pense avoir vu dans le temps une astuce permettant
d'afficher le contenu d'une collection via std::for_each.

Je ne me souviens plus du tout de la manière et cela m'ennuie
un peu.

std::for_each (Container.begin (), Container.end (), ...);

Je pense que cette astuce permettait aussi de définir un
objet basé sur la classe std::ostream.

Quelqu'un a-t-il une idée ?

Le moyen le plus simple fourni par la STL pour afficher le
contenu d'une collection passe par std::copy, et
std::ostream_iterator<>. C'est ça que tu cherches?

#include <iterator>
#include <vector>
#include <algorithm>
#include <iostream>

using namespace std;

// ....
vector<int> vec;
// ....
copy( vec.begin(), vec.end(), ostream_iterator<int>( cout, "n" ) );

C'est bien si tu veux un terminateur (ou pas de séparateur du
tout). Très souvent, ce qu'on veut, c'est un séparateur, voire
même quelque chose de plus dynamique (par exemple, huit éléments
par ligne).

Sans savoir exactement ce qu'il faut, évidemment, c'est
difficile à donner une meilleur solution que celle que tu
proposes.

--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Stéphane Wirtel wrote:

#include <iterator>
#include <vector>
#include <algorithm>
#include <iostream>

using namespace std;

// ....
vector<int> vec;
// ....
copy( vec.begin(), vec.end(), ostream_iterator<int>( cout, "n" ) );

Par contre, je ne pense pas que cela puisse fonctionner avec un
conteneur associatif.

Qu'en penses-tu ?

Pour std::set, je ne vois pas de problème. Pour std::map, le
problème, c'est que le résultat de déréférencer l'itérateur,
c'est un std::pair, dont il n'y a pas d'opérateur >> défini. Si
au moins un des éléments a un type que tu as défini, tu peux
alors définir ton propre opérateur (dans std). Sinon...

Je crois (je ne l'ai jamais essayé) qu'on peut s'en tirer avec
un std::ostream_iterator< MappingType >( ... ), où MappingType
ressemble à quelque chose comme :

struct MappingType
{
MappingType( MapType::value_type const& v )
: myKey( v.first )
, myValue( v.second )
{
}
MapType::value_type::first_type
myKey ;
MapType::value_type::second_type
myValue ;
} ;

std::ostream&
operator<<( std::ostream& dest, MappingType const& obj )
{
dest << '(' << obj.myKey << ',' << obj.myValue << ')' ;
return dest ;
}

Reste le problème que si on veut un séparateur, plutôt qu'un
terminateur. (Encore que... en abusant bien l'opérateur << du
MappingType, avec éventuellement aussi un petit coup de xalloc,
afin d'obtenir de la mémoire...)

--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Cyrille wrote:

Un conteneur associatif contient en fait des std::pair<Key,
value>. Pour que ça marche, il faut que le compilateur sache
comment afficher des std::pair<>.

On le lui dit de cette manière:

namespace std // cf plus loin (*)
{
ostream& operator << (ostream &out, pair<int, double> const &arg)
{
out << arg.first << "t" << arg.second;
return out;
}
}

Et ça, tu n'en as pas le droit. (Au moins, selon la norme.)

et ça s'utilise ainsi:

int main()
{
map<int, double> liste;
liste[4] = .5f;
liste[2] = 1.2f;

copy( liste.begin(), liste.end(), ostream_iterator<pair<int, double>

( cout, "n" ) );

return 0;
}

Surcharger l'opérateur << pour les std::pair, ça ne marche que
si on met la définition de l'opérateur << dans l'espace de nom
std.

Et tu n'as pas le droit d'ajouter n'importe quoi à l'éspace
std::. En fait, à peu près tout ce dont tu as droit, c'est de
spécialiser un template existant sur un type défini par
toi-même.

En fait, les deux arguments de la fonction (out et arg) se
trouvant dans std, le compilateur ne cherchera la fonction que
dans cet espace de nom lors de la résolution de surcharge
(règle dite du Koenig Lookup, je crois, mais je suis pas sûr
de moi, là).

Tu as bien compris la règle. (Formellement, on parle de ADL :
« argument dependant lookup ». Mais c'est ce qu'on entend par
« Koenig lookup ».) Le problème, c'est que tu n'en as pas droit,
selon la norme. Dans la pratique, j'imagine mal un compilateur
où ça poserait des problèmes. Un compilateur -- dans une vraie
application, il y aura toujours la risque que plusieurs
personnes ont la même idée, pour la même pair.

--
James Kanze mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34