Conteneur et habitudes

Version imprimable

Voir 40 message(s) de cette discussion en une page

02/09/2013, 13h16
phi1981

Conteneur et habitudes
Bonjour !

Ce que je trouve le plus difficile quand on apprend un langage, ce n'est pas nécessairement la syntaxe ou les problèmes dans lesquels tout le monde tombe, mais plutôt d'acquérir les pratiques et habitudes de ceux qui ont de l'expérience dans le langage en question. Mon cas aujourd'hui concerne justement une de ces "habitudes" qu'un développeur C++ expérimenté a probablement.

Supposons que j'écrive une fonction censée retourner une liste de fichiers (par exemple les photos présentes sur un périphériques). Pour moi, programmeur c++ inexpérimenté, un prototype naturel serait celui-ci :
Code:

1 2 void GetPhotoList (const std::string& device_name, std::vector<std::string>& picture_list);
Déjà j'ai choisi un vecteur de strings plutôt qu'un std::list parce que cette liste ne sera généralement pas modifiée par l'appelant. C'est peut-être pas le bon choix ?

Ensuite, ce que je n'aime pas dans ce prototype c'est que l'appelant n'a pas la moindre idée de ce que le précédent contenu de mon vecteur va devenir. La fonction va t elle ajouter la liste à la fin ou va t-elle remplacer le contenu existant ?

Alors je me suis dit que je pourrais simplement fournir un template qui prend un iterateur "destination" et laisser l'appelant se débrouiller avec ça. Mon prototype deviendrait donc grosso modo :
Code:

1 2 3 4 5 template<typename It> void GetPhotoList (const std::string& device_name, It dest); // Code appelant : GetPhotoList ("phone", std::back_inserter(mon_conteneur));
J'aime bien, mais voilà ce que j'y reproche :
1) L'implémentation de mon GetPhotoList() va se retrouver dans un header, ce qui me pose quelques problèmes pour encapsuler son fonctionnement (il varie d'une plateforme à l'autre).
2) J'ai pas l'impression de voir ça "souvent" : la majeure partie du code C++ que je rencontre dans ma vie de tous les jours correspond plutôt à mon premier exemple (dois-je trouver des collègues plus expérimentés ? :) ).
3) Dans 99% des cas, je vais utiliser cette fonction avec un vecteur. Pourquoi pas simplifier ce cas général et laisser l'appelant se débrouiller à convertir ensuite vers un autre conteneur pour les 1% restants ?

Voilà où j'en suis, j'aimerais beaucoup des opinions et recommendations pour me faire une idée, non seulement pour ce cas, mais pour mes développements futurs. Merci beaucoup.

Salut,

A vrai dire, le choix d'utiliser le std::vector est sans doute le "choix par défaut" de bien de développeurs, simplement parce qu'il combine énormément d'avantages (dont celui de présenter un accès en temps constant).

Mais il combine également énormément d'inconvénients, parmi lesquelles on peut citer (de manière non exhaustive):

Le déplacement des éléments en mémoire lors de l'ajout
l'impossibilité d'effectuer une recherche dichotomique (en log(n) ) sans s'être au préalable assuré qu'il était trié
La nécessité de disposer d'un espace contigu en mémoire suffisant pour pouvoir y placer l'ensemble des éléments qu'il contient
...
Dans de très nombreuses circonstances, ces inconvénients forcent le développeur à se tourner vers un type de collection différent qui permette d'assurer "la bonne marche" d'un point précis de l'application.

Penses, par exemple, au problème énoncé dans cette discussion, et tu verras que l'utilisation d'un vecteur est très loin d'être sans conséquence, y compris pour les classes ayant sémantique de valeur.

Ceci dit, pour répondre clairement à ta question:

1- C'est à toi que revient la responsabilité de savoir, en fonction du projet sur lequel tu travailles, s'il utilise toujours un std::vector ou s'il lui arrive d'utiliser autre chose.

2- C'est à toi de définir clairement le comportement que tu attends de la part de ta fonction : doit-elle (ou non) vider la collection avant d'y ajouter les nouveaux éléments :question: Peut être peux tu envisager de rajouter un booléen permettant de choisir entre vider ou non la collection :question:

Quoi qu'il en soit, tu dois veiller à ce que le comportement soit explicite pour l'utilisateur de la fonction, en précisant ce fait au niveau du cartouche.

3- pour répondre spécifiquement à ta phrase

Citation:

1) L'implémentation de mon GetPhotoList() va se retrouver dans un header, ce qui me pose quelques problèmes pour encapsuler son fonctionnement (il varie d'une plateforme à l'autre).

je dirais qu'il faut donc veiller à utiliser une abstraction au niveau de GetPhotoList pour obtenir la liste des fichier. Rappelle toi la phrase de David Wheller

Citation:

Envoyé par David Wheller

all problems in computer science can be solved by another level of indirection
(Tout problème en informatique peut être résolu par un autre niveau d'indirection)

4 - Rien ne t'empêche de prévoir deux fonctions si tu te rends compte, dans ton projet particulier, que la liste des fichiers prend parfois la forme d'autres collections qu'un std::vector : la première, template, qui se contente de rajouter les éléments sur base d'un itérateur, la seconde, spécifique à std::vector, qui appellerait la première.

Cela pourrait prendre une forme sans doute très proche de
Code:

1 2 3 4 5 6 7 8 9 template<typename It> void GetPhotoList (const std::string& device_name, It dest){ FileHolder holder(device_name); //l'abstraction dont je te parlais la tantot std::copy(holder.begin(), holder.end(), dest); } void getPhotoList(std::string const & device_name, std::vector<std::string> & vector, bool clearList /* = true */){ if(clearList) vector.clear(); GetPhotoList ("phone", std::back_inserter(vector)); }
Le tout dépendant, bien évidemment, de la situation dans laquelle tu te trouves par rapport à ton projet ;)

02/09/2013, 15h15
dragonjoker59

Tu peux aussi voir ta fonction de manière différente :

Code:

std::vector<std::string> GetPhotoList( const std::string& device_name );

Ca règle au moins le problème de vider ou pas le conteneur en entrée.
02/09/2013, 15h32
koala01

Citation:

Envoyé par dragonjoker59

Tu peux aussi voir ta fonction de manière différente :

Code:

std::vector<std::string> GetPhotoList( const std::string& device_name );

Ca règle au moins le problème de vider ou pas le conteneur en entrée.

Mais cela en pose d'autres :

- Tu forces l'utilisation d'une collection particulière, ce qui peut (ou non) être une contrainte forte qui peut (ou non) impliquer la nécessité de copier le contenu dans une autre collection, plus adaptée à une situation particulière (un std::set, par exemple).

Et la copie prend du temps ;)

- Tu places l'utilisateur face à la nécessité de choisir ce qu'il fait du std::vector récupéré : Doit-il utiliser cette collection "telle quelle", sans s'inquiéter du reste ou doit-il commencer par en rajouter le contenu dans une autre collection :question:

Il serait dommage de forcer l'utilisateur à "refaire" ce que la fonction a déjà fait parce qu'il se trouve dans une situation dans laquelle le contenu du std::vector aurait du être ajouté à celui d'un autre, tu ne crois pas :question:

Je dois cependant, par honnêteté intellectuelle, accorder un avantage certain à cette manière de faire : on évite les effets de bord que le passage de std::vector par référence occasionne.

On pourra donc envisager beaucoup plus sereinement de l'utiliser dans un contexte multi thread ou sous une forme plus ou moins récursive ;)

Voici encore une fois la preuve que tout a un prix en informatique :D
02/09/2013, 15h39
oodini

Citation:

Envoyé par koala01

Et la copie prend du temps ;)

Mais y a-t-il vraiment copie ?
Bien souvent, le compilateur fait en sorte que non.
02/09/2013, 15h47
jblecanard
Salut

Citation:

Envoyé par koala01

Et la copie prend du temps ;)

D'une part le compilateur va optimiser mais d'autre part, avec C++11, la move semantics sera utilisée et on est certain qu'il n'y aura pas de copie du tout (à moins d'avoir implémenté la méthode comme un pied et qu'il y ai une copie en interne, mais c'est une autre histoire).

Citation:

Envoyé par koala01

Tu forces l'utilisation d'une collection particulière, ce qui peut (ou non) être une contrainte forte qui peut (ou non)

Il est quand même rare que ce soit vraiment le cas dans la pratique. S'il se présente, alors on choisit une autre solution (passage par référence avec plusieurs fonctions, templates avec itérateurs).

Avec C++14 et l'inférence par type de retour, on pourra même écrire :
Code:

1 2 std::vector<std::string> GetPhotoList( const std::string& device_name ); std::list<std::string> GetPhotoList( const std::string& device_name );
02/09/2013, 16h15
Arzar

Citation:

Envoyé par koala01

- Tu places l'utilisateur face à la nécessité de choisir ce qu'il fait du std::vector récupéré : Doit-il utiliser cette collection "telle quelle", sans s'inquiéter du reste ou doit-il commencer par en rajouter le contenu dans une autre collection :question:

Je ne comprends pas ce passage. En quoi c'est négatif que l'utilisateur ait le choix de la manière dont il va utiliser le std::vector récupéré ?
02/09/2013, 17h44
r0d

Puisque la question originale concerne les pratiques et habitudes, la mienne, dans ce type de situation, consiste à utiliser la première méthode proposée:

Code:

void GetPhotoList (const std::string& device_name, std::vector<std::string>& picture_list);

Avec 2 remarques:
- Généralement, je retourne un booléen qui permet de tester, si besoin est, que tout s'est bien passé. Pour certaines choses simples, je préfère un bête test plutôt que la gestion d'exceptions*.
- Dans ce cas de figure, je réinitialise systématique le conteneur (ici picture_list) au début de la fonction, généralement en utilisant un swap trick.

Je ne dis pas que c'est la meilleure façon de faire, je n'en sais rien, mais c'est une habitude que j'ai pris et cette méthode répond raisonnablement à la plupart des problèmes qui peuvent se poser. Notamment sur la question de l'optimisation (copie ou pas), là on est sûr qu'il n'y a pas de copie, la question ne se pose pas.

* Dans le cas présent, qui est un contre-exemple de ce que je dis, il y a accès à une ressource donc l'utilisation d'exception sera certainement le plus approprié.
02/09/2013, 18h59
koala01

Je m'absente deux petites heures, et je retrouves un tas de réaction à mes écrits dites donc :D

Citation:

Envoyé par oodini

Mais y a-t-il vraiment copie ?
Bien souvent, le compilateur fait en sorte que non.

Il est effectivement plus que probable que la sémantique de mouvement soit utilisée... Mais ce n'est pas forcément gratuit pour autant :D

Citation:

Envoyé par jblecanard

D'une part le compilateur va optimiser mais d'autre part, avec C++11, la move semantics sera utilisée et on est certain qu'il n'y aura pas de copie du tout (à moins d'avoir implémenté la méthode comme un pied et qu'il y ai une copie en interne, mais c'est une autre histoire).

Même la sémantique de déplacement n'est pas gratuite et prend du temps.

Moins que la copie, je te l'accorde, mais je te rappelle qu'on part du principe d'un std::vector qui a de fortes chances de devoir effectuer un resize pour rajouter le contenu du vecteur obtenu par la fonction à celui qu'il s'agit de "compléter"

Citation:

Envoyé par Arzar

Je ne comprends pas ce passage. En quoi c'est négatif que l'utilisateur ait le choix de la manière dont il va utiliser le std::vector récupéré ?

Primo, parce que cela oblige le développeur à refaire, en cas de besoin, en dehors de la fonction exactement ce que fait (ou du moins une bonne partie de ce que fait ) la fonction... Avoues que c'est un peu dommage, non :question:

Secundo parce qu'il est tout à fait possible de laisser le choix à l'utilisateur de la fonction, tout en faisant en sorte que la "vidange" de la collection se fasse de manière transparente pour l'utilisateur.

Cela te permet de définir beaucoup plus finement les responsabilités de chacune de tes fonctions -- celle de GetPhotoList devenant de mettre à jour la liste des photos, quel que soit le sens donné à "mettre à jour" -- et donc de respecter d'avantage le principe de la responsabilité unique ;)
02/09/2013, 19h21
Flob90

@koala01> Il y aura probablement élision du/des copy/move-ctor, donc le coût est probablement nul en réalité. (Je suis d'accord avec ton autre argument par contre, même si ça peut dépendre de la situation)

Citation:

Envoyé par Flob90

@koala01> Il y aura probablement élision du/des copy/move-ctor, donc le coût est probablement nul en réalité. (Je suis d'accord avec ton autre argument par contre, même si ça peut dépendre de la situation)

Cet argument est peu probant à mon sens:

Tu auras, effectivement, élision de la copie (enfin, on va plutôt parler d'extension de la durée de vie) si l'utilisateur récupère le tableau et le manipule "tel quel" sans plus rien y toucher.

Face à un code proche de
Code:

1 2 3 4 5 6 7 8 void foo(){ std::vector<std::string> tab(GetPhotoList(device_name )); /* Ce pourrait être std::vector<std::string> tab = GetPhotoList(device_name ); for(auto it : tab){ /* manipulations diverses et variées */ } }
tu profiteras de toutes les élisions possibles, sans le moindre problème.

Mais dés le moment où l'utilisateur envisage de rajouter le contenu du tableau renvoyé par la fonction dans une autre collection, par exemple, face à un code proche de
Code:

1 2 3 4 5 6 7 8 9 10 void bar(std::list<std::string> const & devices){ std::vector<std::string> allPhotos; for(it : devices){ std::tab<std::string> recup(GetPhotoList(*it )); /* C'est bizare, mais cette dernière ligne me fait furieusement penser * à quelque chose que j'ai déjà croisé !!!! */ std::copy(recup.begin(), recup.end(),std::back_inserter(allPhotos)); } }
les élisions dont tu pourras profiter n'empêcheront nullement que le compilateur devra copier chacune des chaines de caractères que tab peut contenir.

Il peut éventuellement (mais je suis-je pas en train de donner au compilateur plus "d'intelligence" qu'il n'en a :question:) se rendre compte que tab est une variable locale et utiliser la sémantique de mouvement plutôt que la copie, mais il devra, de toutes manières, insérer tous les éléments de tab dans allPhotos, et ca, ca aura de toutes manières un prix, quel que soit la manière dont il pourra s'y prendre ;)

Citation:
Envoyé par phi1981
Alors je me suis dit que je pourrais simplement fournir un template qui prend un iterateur "destination" et laisser l'appelant se débrouiller avec ça. Mon prototype deviendrait donc grosso modo :
Code:

1 2 3 4 5 template<typename It> void GetPhotoList (const std::string& device_name, It dest); // Code appelant : GetPhotoList ("phone", std::back_inserter(mon_conteneur));
Hello,

Bien que partant d'une bonne idée, je n'aime pas du tout.
Il est ici impossible de déterminer le nombre d'éléments ajouté au conteneur par la fonction, il faut donc toujours utiliser un inserter. Et un oubli est vite arrivé (le back_inserter est construit dans le code appelant).

Pour quelques chose de générique je verrais plutôt
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 // exemple pour un vector, il est bien sur possible de rendre ça template pour avoir une version qui marche pour vectors et lists par exemple // il est aussi possible d'ajouter au milieu d'un conteneur etc.. (et dans ce cas l'inserter est construit dans l'adapter, // pas lors de l'appel de la fonction -> moins de possibilité d'oublis.) struct VectorAdapter { void add(std::vector<std::string>& vec, const string& str) const { vec.push_back(str); } // ... }; template <class Contener, class Adapter> void GetPhotoList(const std::string& device_name, Contener& c, const Adapter& adapter = VectorAdapter()) { // ... adapter.add(c, "some value"); // ... }
Ceci dit, quand il n'y à pas vraiment de raisons de généricité (= je n'en ai pas besoin pour le moment), je ferai
Code:

1 2 3 void GetPhotoList(const std::string& device_name, std::vector<std::string>& photoList); // ou std::vector<std::string> GetPhotoList(const std::string& device_name);
Avec une préférence pour la deuxième forme, sauf si le but est d'ajouter des valeurs à un conteneur non vide.

02/09/2013, 19h54
Flob90

@koala01> Oui, je suis d'accord, mais à mon sens ce que tu viens de développer c'est ton second argument (avec lequel j'étais d'accord) et pas le premier :ccool:
02/09/2013, 21h00
jblecanard

Yo

Citation:

Envoyé par koala01

Même la sémantique de déplacement n'est pas gratuite et prend du temps.

Je trouve que c'est un peu un argument de mauvaise foi dans la mesure où ce coût est de très loin négligeable par rapport à une copie. Si on en vient à ce genre de détails, c'est de la micro-optimisation, et ça les compilateurs le font bien mieux que les développeurs. On peut toujours trouver des cas tordu, mais ça reste vrai presque tout le temps.

Si tu veux "éviter" le coût d'une sémantique de déplacement, tu vas complexifier ton code (rajouter des risques d'erreurs, maintenance plus difficile) pour gagner des cacahouètes, ou même probablement rien vu ce que font les compilos moderne. Honnêtement, la plupart des devs sont loin de se rendre compte à quel point les optimisations compilo sont plus malines qu'eux. Ne serais-ce que d'un point de vue ego, ce n'est pas toujours facile d'admettre qu'une machine fera mieux, et pourtant, en ce qui concerne la compile, c'est quasiment toujours le cas. Il y a une quantité énorme de devs qui se croient malins en écrivant du code "optimisé" alors qu'en fait, ça ne sert juste qu'à le rendre moins lisible :mouarf:

Citation:

Envoyé par koala01

Moins que la copie, je te l'accorde, mais je te rappelle qu'on part du principe d'un std::vector qui a de fortes chances de devoir effectuer un resize pour rajouter le contenu du vecteur obtenu par la fonction à celui qu'il s'agit de "compléter"

D'accord mais cet état de fait est complètement indépendant de la manière de récupérer le vector non ? Je ne vois pas trop le rapport avec le débat sur la copie/mouvement. Même si on passe le vector a remplir par référence, le problème se pose quand même.

D'une manière générale, pour ce genre de problème, la première règle à respecter est d'écrire le code le plus simple et le plus limpide possible. Ce qui va vous coûter cher, c'est le réseau, les accès disques, les grosses allocation de mémoire... Si on prend le cas de notre op ici, qui récupère une liste de fichier sur un device, le coup de copie d'un vector est de très très très loin négligeable par rapport au coût de lecture du dit device.
02/09/2013, 21h08
koala01

Citation:

Envoyé par Flob90

@koala01> Oui, je suis d'accord, mais à mon sens ce que tu viens de développer c'est ton second argument (avec lequel j'étais d'accord) et pas le premier :ccool:

Le fait est que les deux arguments sont intimement liés...

Les élisions diverses et variées ne seront en mesure de n'apporter un gain perceptible et certes sans doute intéressant que dans une situation donnée et bien particulière.

Dans toute autre situation, cette élision n'aura strictement aucun effet, alors que le fait de transmettre la collection par référence offrira un gain équivalent à l'élision dans n'importe quelle situation.

C'est dans cet ordre d'esprit que je trouve l'argument de l'élision peu convaincant ;)
02/09/2013, 21h42
koala01
Citation:

Envoyé par jblecanard

Je trouve que c'est un peu un argument de mauvaise foi dans la mesure où ce coût est de très loin négligeable par rapport à une copie. Si on en vient à ce genre de détails, c'est de la micro-optimisation, et ça les compilateurs le font bien mieux que les développeurs. On peut toujours trouver des cas tordu, mais ça reste vrai presque tout le temps.

Si tu veux "éviter" le coût d'une sémantique de déplacement, tu vas complexifier ton code (rajouter des risques d'erreurs, maintenance plus difficile) pour gagner des cacahouètes, ou même probablement rien vu ce que font les compilos moderne. Honnêtement, la plupart des devs sont loin de se rendre compte à quel point les optimisations compilo sont plus malines qu'eux. Ne serais-ce que d'un point de vue ego, ce n'est pas toujours facile d'admettre qu'une machine fera mieux, et pourtant, en ce qui concerne la compile, c'est quasiment toujours le cas. Il y a une quantité énorme de devs qui se croient malins en écrivant du code "optimisé" alors qu'en fait, ça ne sert juste qu'à le rendre moins lisible :mouarf:

D'accord mais cet état de fait est complètement indépendant de la manière de récupérer le vector non ? Je ne vois pas trop le rapport avec le débat sur la copie/mouvement.

N'inversons pas les rôles, veux tu bien :question:

C'est toi qui est venu mettre la sémantique de déplacement sur le tapis!

Si j'ai argumenté sur ce point particulier, c'était dans le cadre d'une réflexion globale, dont la partie (bien qu'elle citait Azar) que tu as zappée était le pendant!

Tu arrivais avec ton ton péremptoire en disant que, de toutes manières, la sémantique de mouvement c'était pas pour les chiens, et laissant presque penser que c'est une opération " zero cost ".

Je me devais donc d'insister sur le fait que, non, décidément, la sémantique de déplacement n'est pas " zero cost ", et j'ai déjà fait preuve de beaucoup plus d'honnêteté intellectuelle que toi en admettant sans aucun problème le fait que la sémantique de déplacement a un cout largement inférieur à la copie pure et simple!

Mais c'est aussi le mieux que je pouvait t'accorder, en toute honnêteté intellectuelle ;)

Citation:

D'une manière générale, pour ce genre de problème, la première règle à respecter est d'écrire le code le plus simple et le plus limpide possible. Ce qui va vous coûter cher, c'est le réseau, les accès disques, les grosses allocation de mémoire... Si on prend le cas de notre op ici, qui récupère une liste de fichier sur un device, le coup de copie d'un vector est de très très très loin négligeable par rapport au coût de lecture du dit device.

Je n'en disconvient absolument pas!

Mais il n'empêche que, sans chercher à faire de la micro optimisation, le simple fait de transmettre la collection par référence en tant qu'argument pour une fonction:
1. ne rend certainement pas le code plus compliqué ( par rapport à une variable déclarée dans la fonction)
2. supprime tout besoin de copie et ou de sémantique de mouvement
3. Permet de dégager l'utilisateur d'un responsabilité en la prenant en charge de manière transparente, et ce, à moindre cout (un booléen suffit)
En comparaison avec les inconvénients de la technique en termes d'effets de bord, je trouve malgré tout que c'est un compromis des plus acceptables ;)

Citation:

Envoyé par koala01

Il peut éventuellement (mais je suis-je pas en train de donner au compilateur plus "d'intelligence" qu'il n'en a :question:) se rendre compte que tab est une variable locale et utiliser la sémantique de mouvement plutôt que la copie, mais il devra, de toutes manières, insérer tous les éléments de tab dans allPhotos, et ca, ca aura de toutes manières un prix, quel que soit la manière dont il pourra s'y prendre ;)

Parce que j'aime les tests :)

Code:

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
58
59
60
61
62
63
64
#include <chrono>
#include <iostream>
#include <vector>
#include <iterator>
 
const unsigned SIZE = 1000;
const unsigned DEVICES = 100;
const unsigned TESTS = 1000;
 
inline std::string getOne() {
	return "dsjqdjqskdqsjkdjklqsdjkqsdjqsdklqsjkdqsdqsjklmdjqsdjqs";
}
 
void getList(std::vector<std::string>& list) {
	for(unsigned i=0; i<SIZE; ++i) {
		list.push_back(getOne());
	}
}
 
std::vector<std::string> getList() {
	std::vector<std::string> ret;
	for(unsigned i=0; i<SIZE; ++i) {
		ret.push_back(getOne());
	}
	return ret;
}
 
void getAll() {
	std::vector<std::string> all;
	for(unsigned i=0; i<DEVICES; ++i) {
		getList(all);
	}
}
 
void getAllMove() {
	std::vector<std::string> all;
	for(unsigned i=0; i<DEVICES; ++i) {
		std::vector<std::string> recup(getList());
		std::copy(recup.begin(), recup.end(), std::back_inserter(all));
	}
}
 
int main() {
	std::chrono::time_point<std::chrono::high_resolution_clock> start, end;
	std::chrono::duration<double> elapsed;
 
	start = std::chrono::high_resolution_clock::now();
	for(unsigned i=0; i<TESTS; ++i) {
		getAll();
	}
	end = std::chrono::high_resolution_clock::now();
	elapsed = end - start;
	std::cout << "getAll: " << elapsed.count() << "s" << std::endl;
 
	start = std::chrono::high_resolution_clock::now();
	for(unsigned i=0; i<TESTS; ++i) {
		getAllMove();
	}
	end = std::chrono::high_resolution_clock::now();
	elapsed = end - start;
	std::cout << "getAllMove: " << elapsed.count() << "s" << std::endl;
 
	return 0;
}

Code:

1
2
3
4
g++ -std=c++11 -o main main.cpp -O3
./main
getAll: 21.8123s                                                                               
getAllMove: 22.8241s

Il y à un cout, comme prévu (les insertions supplémentaires), mais ce n'est pas énorme non plus.

edit : VS2012

Code:

1
2
getAll: 13.2198s
getAllMove: 22.3273s

Là par contre, ça commence à faire une sacrée différence 8O

02/09/2013, 23h34
jblecanard

Citation:

Envoyé par koala01

Tu arrivais avec ton ton péremptoire en disant que, de toutes manières, la sémantique de mouvement c'était pas pour les chiens, et laissant presque penser que c'est une opération " zero cost "

Allons je ne voulais pas te brusquer, c'est juste que j'étais étonné que le sujet ne soit pas développé dans les posts, j'ai eu l'impression que vous étiez un peu passé à côté, ça peut arriver à tout le monde n'est-ce pas ?

Je regrette si mon ton a paru agressif, ce n'était pas souhaité.
03/09/2013, 00h26
JolyLoic

Il y a aussi un coût au passage par référence : Comme le compilateur ne peut pas savoir s'il y a aliasing ou pas, il est obligé de supposer qu'il y en a, et de faire du code non optimal.

De mon point de vue, et à moins d'en savoir plus sur la manière d'utiliser la fonction (et de se rendre compte que le pattern d'utilisation va à l'encontre de l'interface), je partirais en C++11 vers le plus simple : Une fonction qui retourne un vector.

Elle apporte par rapport à une fonction prenant un paramètre en référence :
- Une sémantique claire et non ambiguë.
- La possibilité d'initialiser directement des variables à la bonne valeur, plutôt que de déclarer une variable à un moment et l'initialiser plus tard, ce qui augmente le nombre d'états d'un programme et complexifie la réflexion à son sujet
- La possibilité de chaîner les appels de fonction processPhotoList(getPhotoList)).

Dans certains contextes (référence sur les objets contenus, beaucoup d'appels pour récupérer les mêmes données), je retournerais un objet range désignant des données stockées ailleurs plutôt qu'un vector.

En tout cas, je crois que dans le cas rare d'une fonction prenant un conteneur par référence pour le modifier, je n’appellerais jamais getXXX. appendXXX peut-être...

Wow .... je m'attendais pas à autant de réponses. Merci beaucoup à tous/toutes.
J'ai lu tous vos posts. J'ai rien vu qui m'ait "surpris", bien que j'aimerais relire les arguments avancés sur les performances à tête reposée (ça vaut la peine, Iradrille a même pris le temps de prendre des mesures:) )

Toutefois, un point avancé par Koala me parait curieux :
Citation:
Envoyé par koala01
Cela pourrait prendre une forme sans doute très proche de
Code:

1 2 3 4 template<typename It> void GetPhotoList (const std::string& device_name, It dest){ FileHolder holder(device_name); //l'abstraction dont je te parlais la tantot std::copy(holder.begin(), holder.end(), dest); }
En fait, si un tel objet FileHolder qui retourne une paire d'itérateurs était à ma disposition, je ne prendrais pas le temps d'implémenter une fonction GetPhotoList(), qui limite forcément les possibilités. Je laisserais l'appelant se débrouiller avec l'objet FileHolder directement, ça lui permettrait de copier la collection vers le conteneur de son choix, ou même d'effectuer certains traitements directement depuis le FileHolder.

J'aime beaucoup les arguments avancés par JolyLoic sur l'idée de retourner directement un vecteur par valeur de retour, à la :
Code:

1 2 std::vector<std::string> GetPhotoList(const std::string& device_name);
Et effectivement, le nom "Get" de la fonction est un peu contradictoire avec l'idée de prendre un vecteur en référence en vue de le modifier.

03/09/2013, 11h40
white_tentacle

Citation:

Envoyé par JolyLoic

Elle apporte par rapport à une fonction prenant un paramètre en référence :
- Une sémantique claire et non ambiguë.

À ce propos, y a-t-il des plans dans les prochaines évolutions c++ pour rajouter les paramètres « out » (façon c# ou ada) ?

C’est à mon sens un manque (et serait une solution simple au problème posé ici).
03/09/2013, 11h48
oodini

Quand on a un seul paramètre à renvoyer, à la lecture du code, utiliser une valeur de retour me semble plus simple.
03/09/2013, 12h52
Arzar
Citation:

Envoyé par Iradrille

Là par contre, ça commence à faire une sacrée différence 8O

A cause d'une copie inutile de recup vers all. En le déplaçant les timings devraient être beaucoup plus proches.:
Code:

1 2 std::vector<std::string> recup(getList()); std::move(recup.begin(), recup.end(), std::back_inserter(all));
Pour ce qui est de la question initiale, je pense que la majorité des codeurs C++ utiliseraient la 1ère méthode, celle avec la référence qui me semble être un bon compromis perf/facilité d'utilisation/lisibilité et qui permet surtout de renvoyer un code d'erreur ou un booléen si le besoin se fait sentir.
03/09/2013, 13h37
koala01

Citation:

Envoyé par phi1981

Toutefois, un point avancé par Koala me parait curieux :

En fait, si un tel objet FileHolder qui retourne une paire d'itérateurs était à ma disposition, je ne prendrais pas le temps d'implémenter une fonction GetPhotoList(), qui limite forcément les possibilités. Je laisserais l'appelant se débrouiller avec l'objet FileHolder directement, ça lui permettrait de copier la collection vers le conteneur de son choix, ou même d'effectuer certains traitements directement depuis le FileHolder.

Ne t'attardes peut être pas trop sur la manière dont j'ai utilisé FileHolder, qui n'était qu'un exemple, d'ailleurs sans doute mal choisi au demeurant (surement mal choisi, à lire ta réaction :D)

Ce qui importe, c'est surtout d'arriver à utiliser une abstraction capable de représenter "n'importe quel système de fichiers".

Qu'il s'agisse d'un serveur, d'une tablette, d'un GSM, d'un GPS ou du troisième sous répertoire du disque E de ton pc, c'est le même combat et tu devrais pouvoir utiliser la même abstraction : tu as un dossier, composé sans doute de répertoires et de fichiers, dont tu peux récupérer le nom et d'autres informations (comme la date et l'heure de la création, la date et l'heure de la dernière modification, les droits pour différents types de personnes, ...) qui te permet de travailler "de la même manière, quelles que soient les conditions de travail".

Je penses, par exemple, à quelque chose comme boost.filesystem qui présente ce genre d'abstraction et qui fonctionne avec n'importe quel système de fichier concret.

La manière d'utiliser une telle abstraction dépend évidemment très largement de l'interface publique quelle présente, et c'est à toi d'en tenir compte ;)
03/09/2013, 13h53
JolyLoic

Citation:

Envoyé par white_tentacle

À ce propos, y a-t-il des plans dans les prochaines évolutions c++ pour rajouter les paramètres « out » (façon c# ou ada) ?

Je n'ai rien vu dans ce sens. Le plus proche que je connaisse est le retour d'un tuple, éventuellement wrappée par l'utilisation de [boost/std]::tie.
03/09/2013, 14h04
Iradrille
Citation:
Envoyé par Arzar

A cause d'une copie inutile de recup vers all. En le déplaçant les timings devraient être beaucoup plus proches.:

Code:

1 2 std::vector<std::string> recup(getList()); std::move(recup.begin(), recup.end(), std::back_inserter(all));
Bien vu,
Code:

1 2 getAll: 13.3958s getAllMove: 15.4859s
03/09/2013, 15h26
phi1981

Citation:

Envoyé par koala01

Ne t'attardes peut être pas trop sur la manière dont j'ai utilisé FileHolder, qui n'était qu'un exemple, d'ailleurs sans doute mal choisi au demeurant (surement mal choisi, à lire ta réaction :D)

Ce qui importe, c'est surtout d'arriver à utiliser une abstraction capable de représenter "n'importe quel système de fichiers".

Oui ok j'aurais dû arriver à cette conclusion vu que la classe de l'objet est "FileHolder" et non pas un truc genre "PhotoExtractor". Désolé :)

Bon j'ai collecté assez d'exemples pour réfléchir tranquillement à mes histoires de conteneurs. Merci beaucoup tout le monde !
03/09/2013, 17h14
koala01

Citation:

Envoyé par phi1981

Oui ok j'aurais dû arriver à cette conclusion vu que la classe de l'objet est "FileHolder" et non pas un truc genre "PhotoExtractor". Désolé :)

Allez, je propose donc un très diplomatique "tords partagés" sur ce coup là :D
04/09/2013, 14h13
CedricMocquillon
+1 avec la réponse de Loic:

Citation:

De mon point de vue, et à moins d'en savoir plus sur la manière d'utiliser la fonction (et de se rendre compte que le pattern d'utilisation va à l'encontre de l'interface), je partirais en C++11 vers le plus simple : Une fonction qui retourne un vector.

Personnellement j'utilise quasiment toujours cette version puisque en tant qu'utilisateur de la classe j'attends avec un nom comme getPhotoList de pouvoir écrire un truc comme:
Code:

1 2 3 4 for(auto const& photo : getPhotoList()) { //traitement sur la photo de la collection }
Alors que la version en passant la collection en paramètre laisse plein d'inconnues: est-ce que le conteneur doit avoir préalloué la mémoire pour les futurs éléments?, est-ce qu'ils seront ajoutés à la fin?, est-ce que le conteneur sera réinitialisé?, ... Tant de question sans réponse (à moins d'aller lire la doc, ce qui est une bonne pratique, mais je préfère une version plus "intuitive" qui évite les quiproquo)

PS: en pratique j'utilise une version renvoyant un range avec un typedef sur le range

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); :mrgreen:

Les avantages selon lui :
1) Plus composable
2) plus efficace

Précision importante, il part du principe que la forme avec la référence ajoute simplement à la fin du vecteur (faire des push_back en gros) plutôt que de réinitialiser et ajouter.

Voici un des exemples qu'il donne pour montrer la supériorité de l'API par référence (il n'en parle qu'à l'oral, sans code, je transcris ce que j'en ai compris).
L'api par référence permet de faire :
Code:

1 2 3 4 5 6 7 std::vector<std::string> v; while(some_condition) { v.clear(); AppendPhotoList(somedir, v); // je l'appelle AppendPhotoList pour distinguer avec celle qui retourne par valeur DoSomething(v); }
alors que l'api avec la valeur par retour oblige à faire :
Code:

1 2 3 4 while(some_condition) { DoSomething(GetPhotoList(somedir)); }
Et dans ce cas naturellement la forme n°1 est bien plus efficace car dans la forme 2 la fonction GetPhotoList va recréer complètement un vecteur à chaque appel, donc à chaque tour de boucle le programme désallouera et reéallouera de la mémoire alors que le vecteur du code 1 finira par atteindre une capacité maximale et ne réallouera plus du tout.

05/09/2013, 11h18
oodini

Je pense que dans ton premier bout de code, la bonne expression est :

Code:

DoSomething(v);
05/09/2013, 11h35
Arzar

Oui, merci, je corrige.
05/09/2013, 11h51
camboui
Intéressant.
En y réfléchissant, et en généralisant, je code bien plus souvent la première forme que la deuxième.
Même si souvent j'hésite parce que c'est plus "lourd" (à taper et à relire).
Code:

1 2 3 4 5 6 7 8 //often recommended MyClass oi; while(some_condition) { //oi.init() or oi.clear(); whatever you need... GetByRef(someparam, oi); DoSomething(oi); }
Code:

1 2 3 4 5 6 //less often while(some_condition) { MyClass oi=GetByVal(someparam); DoSomething(oi); }
D'ailleurs parfois y'a pas le choix.
Code:

1 2 3 4 5 6 7 MyClass1 o1; MyClass2 o2; while(some_condition) { GetByRef(someparam, o1, o2); DoSomething(o1, o2); }
Il m'est arrivé alors d'utiliser des std::pair<> ou des tableaux de variant (des tuples, etc) comme valeur de retour.
Oui... et puis non finalement.
A la longue le retour par valeur des objets "complexes" est finalement pénible (je ne me suis toujours pas fait au retour de std::map<>.insert() par exemple).
On a inventé les références, c'est pour s'en servir. Même si c'est plus ambigue, même s'il faut bien lire et comprendre la doc, même si c'est laid.

Mais, j'y pense...
J'aimerais pouvoir faire quelque chose comme ceci:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 class MyClass1 { int col; }; class MyClass2 { int row; }; main() { std::pair<MyClass1, MyClass2> p=DoSometing(); //Calc(p.first.col, p.second.row); // lourdingue... Calc(p..col, p..row);//accept this shorter syntax if there is no ambiguity }
Je viens d'inventer l'opérateur .. :mouarf:
Il permettrait de désigner un membre ou un sous-membre implicitement, pour autant qu'il n'y ai pas d'amguité.
Vous en pensez quoi ? :aie:

Perso je me prends surtout à rêver d'une syntaxe comme en go qui autorise les valeurs de retour multiples. Quelque chose comme ça ...

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
DoSomething(void) -> MyClass1, MyClass2, bool
{
   MyClass1 m1, m2;
   bool err = false;
 
   // code...
 
   return m1, m2, err;
}
 
main()
{
   MyClass1 m1, MyClass2 m2, bool err = DoSomething();
   if(err )
     Calc(m1, m2);
 
   //
   // Note: En go on n'est pas obligé de définir tout sur la même ligne on peut 
   // aussi faire :
   // MyClass1 m1; MyClass2 m2;
   // ...
   // utilisation de m1 et m2 pour autre chose
   // ...
   // m1, m2, bool err = DoSomething();

05/09/2013, 12h38
white_tentacle

Les tuples sont tes amis (mais les tuples ont un gros défaut : l’absence de nommage de leurs composants, qui font que ça manque en général de sens. Les valeurs de retour ont le même problème, cela dit).
05/09/2013, 12h44
r0d

Wah, Alexandrescu est d'accord avec moi! C'est la consécration, je vais le mettre sur mon cv!
Bon par contre, on est d'accord sur la signature à utiliser, mais c'est pas pour les mêmes raisons :aie:

edit: j'en profite pour faire une remarque sur l'argument de JolyLoic concernant le fait qu'une fonction qui retourne un conteneur permet de chainer des appels. Moi je n'aime pas chainer des appels (c'est une des raisons qui font que je n'utilise plus systématiquement la STL). Je préfère un peu plus de lignes de code, mais des lignes plus simples, plus atomiques, sémantiquement parlant. Mais c'est une pratique, une préférence, je ne sais pas si c'est mieux ou moins bien.
05/09/2013, 12h58
Arzar

Citation:

Envoyé par r0d

Wah, Alexandrescu est d'accord avec moi! C'est la consécration, je vais le mettre sur mon cv!

Il est presque d'accord avec toi :aie: Car Alexandrescu ne ferait jamais ça :

Citation:

Envoyé par r0d

- Dans ce cas de figure, je réinitialise systématique le conteneur (ici picture_list) au début de la fonction, généralement en utilisant un swap trick.

Vu qu'avec un swap trick tu forces la désallocation de la mémoire du vecteur passé en référence, donc tu perds la moitié de l'intérêt à utiliser cette signature (pas d'allocation inutile si le vecteur a déjà une capacité suffisante)

Citation:

Envoyé par r0d

Moi je n'aime pas chainer des appels (c'est une des raisons qui font que je n'utilise plus systématiquement la STL). Je préfère un peu plus de lignes de code, mais des lignes plus simples, plus atomiques, sémantiquement parlant.

+1. :P Je n'aime pas chainer les appels non plus pour la simple raison que ça donne du code complètement indébuggable vu qu'on ne peut pas mettre de breakpoint pour vérifier étape par étape ce que renvoie chaque fonction.
05/09/2013, 13h04
oodini

Citation:

Envoyé par white_tentacle

Les tuples sont tes amis (mais les tuples ont un gros défaut : l’absence de nommage de leurs composants, qui font que ça manque en général de sens. Les valeurs de retour ont le même problème, cela dit).

Il faut les utiliser conjointement avec un enum dont les valeurs seront utilisées dans get().

Voici un exemple dans un contexte de serialisation:
-paramètre par référence pour sequence_in(), sequence_out(), ascending(), descending() (à cause des surcharges);
-valeur retour pour permettre le chainage d'appel avec asc(), desc(), operator,() (bien pratique et très visuel dans ce cas-ci).

input

Code:

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
//input
template<typename Str>
class sequencer_input
{
public:
	sequencer_input(Str const & stream);
	...
 
	template<typename T>
	sequencer_input & operator,(T & v)
	{
		sequence_in(*this, v);
		return *this;
	}
};
 
template<typename T, typename Str>
bool run_sequencer_input(T & t, Str const & s)
{
	...
	sequencer_input<Str> ts(s);
	...
	t.sequence(ts);
	...
	return success;
}
 
template<typename Str, typename T>
void sequence_in(sequencer_input<Str> & ts, T & t)
{
	t.sequence(ts);
}
 
template<typename Str>
void sequence_in(sequencer_input<Str> & ts, int & i)
{
	...
}
 
template<typename Str>
void sequence_in(sequencer_input<Str> & ts, unsigned & u)
{
	...
}
 
template<typename Str>
void sequence_in(sequencer_input<Str> & ts, std::string & s)
{
	...
}

output

Code:

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
//output
template<typename Str>
class sequencer_output
{
public:
	sequencer_output(Str & stream);
	...
 
	template<typename T>
	sequencer_output & operator,(T const & v)
	{
		sequence_out(*this, v);
		return *this;
	}
};
 
template<typename T, typename Str>
bool run_sequencer_output(T const & t, Str & s)
{
	...
	sequencer_output<Str> ts(s);
	...
	const_cast<T &>(t).sequence(ts);
	...
	return success;
}
 
template<typename Str, typename T>
void sequence_out(sequencer_output<Str> & ts, T const & t)
{
	const_cast<T &>(t).sequence(ts);
}
 
template<typename Str>
void sequence_out(sequencer_output<Str> & ts, int i)
{
	...
}
 
template<typename Str>
void sequence_out(sequencer_output<Str> & ts, unsigned u)
{
	...
}
 
template<typename Str>
void sequence_out(sequencer_output<Str> & ts, std::string const & s)
{
	...
}

order

Code:

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
58
59
60
61
62
//order
class sequencer_order
{
	...
 
	template<typename T>
	sequencer_order & asc(T v)
	{
		ascending(*this, v);
		return *this;
	}
	template<typename T>
	sequencer_order & desc(T v)
	{
		descending(*this, v);
		return *this;
	}
};
 
inline void ascending(sequencer_order & sk, int i)
{
	...
}
inline void descending(sequencer_order & sk, int i)
{
	...
}
 
inline void ascending(sequencer_order & sk, unsigned u)
{
	...
}
inline void descending(sequencer_order & sk, unsigned u)
{
	...
}
 
 
inline void ascending(sequencer_order & sk, std::string const & s)
{
	...
}
inline void descending(sequencer_order & sk, std::string const & s)
{
	...
}
 
template<typename T>
struct sequencer_order_pred
{
	mutable sequencer_order sk1, sk2;
	void (T::*mf_)(sequencer_order &) const;	// the member function pointer
	explicit sequencer_order_pred(void (T::*mf)(sequencer_order &) const): mf_(mf) {}
	bool operator()(T const & v1, T const & v2) const
	{
		sk1.clear();
		(v1.*mf_)(sk1);
		sk2.clear();
		(v2.*mf_)(sk2);
		return ::memcmp(sk1.buffer(), sk2.buffer(), std::min(sk1.size(), sk2.size())) < 0;
	}
};

Example d'utilisation, avec les méthodes descriptives MyRecord::sequence() et MyRecord::order_by().

Code:

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
struct MyRecord
{
	int m_age;
	std::string m_nom, m_prenom;
 
	template<typename F>
	void sequence(F & f)
	{
		f, m_age, m_nom, m_prenom;
	}
 
	void order_by(sequencer_order & sk) const
	{
		sk.desc(m_age).asc(m_nom).asc(m_prenom);
	}
};
 
main()
{
	//read
	std::string si;
	sequencer_input<std::string> stri(si);
	std::vector<MyRecord> v;
 
	...
 
	MyRecord r;
	while (cond)
	{
		if (run_sequencer_input(r, stri))
		{
			v.push_back(r);
			...
		}
	}
 
	...
 
	//sort
	std::sort(v.begin(), v.end(), sequencer_order_pred<MyRecord>(&MyRecord::order_by));
 
	...
 
	//write
	std::string so;
	sequencer_output<std::string> stro(so);
 
	...
 
	foreach (MyRecord r in v)
	{
		if (!run_sequencer_output(r, stro))
		{
			...
		}
	}
}

Bon, voilà, vite fait, comme ça, je ne sais pas ce que ça vaut :mrgreen:
Enfin, juste pour dire que les références sont privilégiées, c'est utile pour surcharger ou ajouter des indirections lorsque nécessaire.
Exception faite lorsque la valeur retour est *this, j'adore chainer dans ce cas :aie:

Voir 40 message(s) de cette discussion en une page

Fuseau horaire GMT +2. Il est actuellement 19h51.