Discussion :

[r0d]

Bonjour,

c'est l'été, alors je vous propose un petit jeu.
Dans le code qui suit, nous avons un conteneur, qui contient un tableau (vector). Nous voulons récupérer ce tableau pour y ajouter un élément.

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
#include <iostream>
#include <vector>
#include <string>
#include <algorithm>
using namespace std;
 
struct Container
{
	// constructeur
	Container() : my_vector ( { 1, 2, 3 } ) {}
 
	// accesseur au contenu qui renvoie un référence sur le vector (et non constante, pour qu'on puisse le modifier)
	vector<int> & get_vector() { return my_vector; }
 
private:
	// le contenu
	vector<int> my_vector;
};
 
int main()
{
	// on créé un conteneur
	Container my_container;
 
	// on récupère le contenu du conteneur
	auto content_reference = my_container.get_vector();
 
	// on a joute un élément à ce contenu
	content_reference.push_back(4);
 
	// on vérifie que l'élément a bien été ajouté
	copy(my_container.get_vector().begin(), my_container.get_vector().end(), ostream_iterator<int>(cout, " "));
 
	cout << endl;
	getchar();
	return 0;
}

Questions:
Quel est l'output de ce programme?
Pourquoi?

[Ehonn]

C'est assez vicieux ^^
auto va être remplacé par std::vector<int> et non std::vector<int> &, et donc le 4 ne sera pas ajouter au vecteur de la structure (mais à la copie).

Pour avoir le comportement attendu, il faut écrire auto & ou, en plus "barbare", decltype(my_container.get_vector()).

PS : le code ne compile tel quel, il faut rajouter #include <iterator> pour std::ostream_iterator.

[ternel]

Ma réponse, faite sans compilateur, ni retour à la norme.
Il sera affiché le contenu du vecteur interne. Ça, c'est certain, et sans piège.

Reste le point de détail important: auto.
auto content_reference = my_container.get_vector();.

auto peut être qualifié de const ou de const&.
Sauf que là, il est explicitement nourri par une référence.
En typage, on a : auto = std::vector<int>&, j'espère sans certitude absolue que auto sera bien une référence.

Si c'est le cas on aura 1 2 3 4, sinon, ce sera 1 2 3
A présent, je ne suis pas fan du retour par référence modifiable d'une partie.
Je préfèrerai en général créer des fonctions délégatrices, chaînables sur la classe englobante.
Cela explique pourquoi je ne suis pas certain de mon analyse

édit: j'en déduis qu'Ehonn est plus rapide que moi, et que mon gros doute était fondé.

[r0d]

C'est assez vicieux ^^
auto va être remplacé par std::vector<int> et non std::vector<int> &, et donc le 4 ne sera pas ajouter au vecteur de la structure (mais à la copie).

Pour avoir le comportement attendu, il faut écrire auto & ou, en plus "barbare", decltype(my_container.get_vector()).

Bien joué

Au début j'étais parti sur un truc plus simple: int & get_number() /* ... */ auto = my_container.get_number(). Le problème est le même mais je trouvais que c'était trop facile alors j'ai rajouté l'histoire du vector, pour brouiller les pistes

PS : le code ne compile tel quel, il faut rajouter #include <iterator> pour std::ostream_iterator.

Ha. Chez moi, sous visual 2013, ça compile comme ça. Bizarre

edit: je viens de voir que dans la version de la STL de visual 2013, <iterator> est inclus dans <string>

[Ehonn]

ne compile pas avec g++ 4.9.1*
C'est assez casse-pied les #include inclus par d'autres, la quasi-totalité des échecs de compilation de mes projets sous Clang viennent de là (je développe avec GCC mais teste de temps en temps avec Clang).