Discussion :

[oodini]

operator,() (bien pratique et très visuel dans ce cas-ci)

Mouais... Si l'opérateur de flux a été créé, ce n'est pas pour rien.
Quand on lit le code, il faut savoir que l'opérateur de flux a été redéfini.
Et pour chercher la définition d'un opérateur, ça ne se fait pas en un seul clic.
Une friction mentale, comme dirait Meyers.

[camboui]

La première fois si j'ai bon souvenir que j'ai vu operator,() c'est dans boost::assign.

Regarde le code de sequence(), il est tantôt "in" tantôt "out", en fonction du paramètre template.
J'aimais pas faire le choix entre << ou >>.
Et puis, c'est perso, je desteste les (io)stream.

Avouons-le, le code C++ est quand même souvent rébarbatif à lire quand il déborde de < et >, autant ne pas se priver quand on peut les éviter (c'est pour la bonne cause).

[Iradrille]

-valeur retour pour permettre le chainage d'appel avec asc(), desc(), operator,() (bien pratique et très visuel dans ce cas-ci).

C'est dur à lire, car c'est un opérateur "jamais" surchargé, il est ici préférable d'utiliser des templates variadics je pense.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
template<typename F>
void sequence(F & f)
{
	f, m_age, m_nom, m_prenom;
}
// deviendrait, avec process une fonction template variadique.
template<typename F>
void sequence(F & f)
{
	f.process(m_age, m_nom, m_prenom);
}

Ça serait plus lisible imo.

Edit : l'utilisation de l'opérateur,() n'est pas très safe non plus :

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
#include <string>
 
struct Foo {
	// pas de surchage de l'operator,()
};
 
struct Bar {
	int m_age;
	std::string m_nom, m_prenom;
	template <class F>
	void sequence(F& f) {
		f, m_age, m_nom, m_prenom;
	}
};
 
int main() {
	Foo foo;
	Bar bar;
	bar.sequence(foo);
 
	return 0;
}

Ce code compile bien que Foo ne fournisse pas de surcharge de l'opérateur,() et n'aura donc pas le comportement voulu.

[Médinoc]

Je plussoie, surcharger l'opérateur virgule est un appel au désastre et au code non-maintenable...

Pour de la sérialisation, je préfère surcharger les opérateurs de décalage. On s'y attend plus.

[Arzar]

Voilà qui est intéressant, Andrei Alexandrescu vient tout juste de faire une présentation à la conf GoingNative (qui est live en ce moment) et tout une section de sa présentation était dédiée au fait que void GetPhotoList (const std::string& device_name, std::vector<std::string>& picture_list); est selon lui une bien meilleure interface que std::vector<std::string> GetPhotoList (const std::string& device_name);

La vod est maintenant dispo en ligne : http://channel9.msdn.com/Events/Goin...in-Cpp-Quickly
Le passage commence à 46m30. Il rentre réellement dans le vif du sujet à 48m30.

[JolyLoic]

La vod est maintenant dispo en ligne : http://channel9.msdn.com/Events/Goin...in-Cpp-Quickly
Le passage commence à 46m30. Il rentre réellement dans le vif du sujet à 48m30.

Je ne suis pas arrivé à cette vidéo, mais Bjarne parle du même sujet dans son introduction http://channel9.msdn.com/Events/Goin...rne-Stroustrup (vers 30m) , et préconise d'utiliser des valeurs de retour pour retourner.

[koala01]

C'est encore bien la preuve que tout le monde voit midi à sa porte

Je crois, sincèrement, qu'il y a du "pour" et du "contre" aux deux techniques et qu'il faut essentiellement s'adapter aux circonstances.

Le passage par référence sera très certainement intéressant dans certains cas, alors que l'utilisation d'une valeur de retour le sera dans d'autres...

Tant que l'on parle de manière théorique, il sera donc tout à fait impossible de se départager, et ce qui sera -- effectivement -- la meilleure solution dans une situation donnée sera -- très certainement -- la plus mauvaise dans une autre

[oodini]

Apparemment, les Dalton ne sont pas d'accord sur plusieurs choses.
Exemple : Stroustrup dénonce la vision multiparadigme, alors que ça doit être un des premiers items dans le bouquin de Meyers.

[koala01]

Apparemment, les Dalton ne sont pas d'accord sur plusieurs choses.
Exemple : Stroustrup dénonce la vision multiparadigme, alors que ça doit être un des premiers items dans le bouquin de Meyers.

En fait, je crois que Stroutrup se base sur la définition d'un paradigme, telle qu'on peut par exemple la trouver sur wikipedia:

Un paradigme est une représentation du monde, une manière de voir les choses, un modèle cohérent de vision du monde qui repose sur une base définie (matrice disciplinaire, modèle théorique ou courant de pensée). C'est une forme de rail de la pensée dont les lois ne doivent pas être confondues avec celles d'un autre paradigme et qui, le cas échéant, peuvent aussi faire obstacle à l’introduction de nouvelles solutions mieux adaptées.

J'ai l'impression qu'il se dit que si on applique trop à la lettre cette définition, on risque de se retrouver sur ... des rails, qui nous empêcheraient d'envisager d'autres solutions.

Il faut avouer que, la première idée qui vient à l'esprit de beaucoup de développeurs C++ est le paradigme OO, alors que le procédural pur et simple ou le générique pourrait parfaitement s'appliquer