#include <iostream>
#include <vector>

using namespace std;

void f(vector<int> v)
{
	for (auto& e : v)
		cout << e << endl;
}

int main()
{
	vector<int> v{1,2,3,4,5};

	for (auto& e : v)
		cout << e << endl;

	f(move(v));

	cout << "v size=" << v.size() << endl;

	for (auto& e : v)
		cout << e << endl;

	v.push_back(7);
	v.push_back(8);

	for (auto& e : v)
		cout << e << endl;

}

gbdivers, tu peux continuer à utiliser ta variable après le move puisse qu'elle n'a pas de partie dynamique allouée sur le tas. Même avec un vecteur, une fois "mové" tu peux continuer à l'utiliser, il est juste redevenu vide puisse son contenu dynamique lui a été volé. Vas expliquer ça sans les pointeurs !

-
Edité par ChristopheDrieu1 11 octobre 2019 à 8:14:09

michelbillaud a écrit:

Perdu. C'est parce qu'un vector, ça planque un tableau alloué dynamiquement , qui sera réalloué de temps en temps quand on ajoute des éléments. Et reallouer, pas forcément au meme endroit.

Si ce n'est que je n'ai parlé d'un tableau que pour le like, celui qui contient les référence vers les utilisateurs... je n'ai rien dit concernant les utilisateurs en eux même

Il n'y a rien qui empêche de maintenir les utilisateurs eux-même dans une map, vu qu'il sera toujours intéressant d'en assurer la recherche rapide au moyen d'un critère bien spécifique

Et puis, si tu vas jusque là, dois-je te rappeler qu'une classe utilisateur a -- typiquement -- sémantique d'entité, que l'on s'attend à trouver dans une hiérarchie de classes avec les notions d'héritage et de polymorphismes qui y sont rattachées?

Or, nous n'avons jamais dit qu'il ne fallait pas aborder le problème des pointeurs : on a juste dit qu'il ne fallait pas l'aborder lors des tous premiers cours, qu'il est préférable, justement, d'attendre d'en arriver à un point où l'on commencera réellement à ne pas savoir faire autrement que d'y avoir recours pour les utiliser correctement.

Et, devine quoi? le moment où tu n'auras pas d'autre choix que de les expliquer coïncide, justement, avec cette période où tu vas aborder les notions d'héritage et de polymorphisme.

Avant, tu n'en as tout simplement pas besoin.

D'ailleurs, c'est bien simple : au lieu de te parler d'un tableau de reference_wrapper, j'aurais très bien pu te parler d'un tableau d'entiers (sans doute exclusivement positif) représentant l'identifiant unique spécifique à chaque utilisateur, et tu n'aurais même plus eu cette excuse fallacieuse

ChristopheDrieu1 a écrit:

gbdivers, tu peux continuer à utiliser ta variable après le move puisse qu'elle n'a pas de partie dynamique allouée sur le tas. Même avec un vecteur, une fois "mové" tu peux continuer à l'utiliser, il est juste redevenu vide puisse son contenu dynamique lui a été volé. Vas expliquer ça sans les pointeurs !

Tu prends les choses comme tu veux, mais :

Unless otherwise specified, all standard library objects 
that have been moved from are placed in a valid but
unspecified state. That is, only the functions without 
preconditions, such as the assignment operator, can be 
safely used on the object after it was moved from:

Et utiliser un objet qui est dans un "unspecified state" est un UB.

Ton code n'est pas valide et sera détecté comme tel par clang avec le warning bugprone-use-after-move.

Ton code "tombe en marche", ie il est trop simpliste pour que faire apparaître le bug. Il n'en reste pas moins invalide (ie ça te pétera au nez dans un autre code ou le comportement pourra changer selon l'environnement).

Les explications à base de pointeurs sont souvent fausses, parce qu'elles ne correspondent pas à la réalité de ce qui se passe au niveau du compilateur et du hardware.

Montrer un code invalide qui "tombe en marche", ça passe dans un code d'exemple de quelques lignes ou dans un (mauvais) cours, mais dans un vrai code pro de plusieurs centaines de milliers de lignes et qui va être maintenu pendant des années, ça finit toujours par péter.

Donc mon conseil reste valide : si c'est pour lire pendant 2-3 semaines un cours de C++ et ne plus jamais faire du C++ ensuite, lisez ce cours. Si c'est pour faire du C++ professionnellement et que vous ne voulez pas apprendre du code invalide, lisez autre chose.

-
Edité par gbdivers 11 octobre 2019 à 9:56:05

Bien sûr que l'on ne doit pas utiliser ce genre de chose, et de toute façon on utilise plutôt un move d'une fonction appelée vers une fonction appelante , c'était juste pour illustrer le fait qu’il y a redirection de pointeur interne, l’objet reste.

(J'ai inséré l'image pour les debutants)

-
Edité par ChristopheDrieu1 11 octobre 2019 à 10:27:55

koala01 a écrit:

michelbillaud a écrit:

Perdu. C'est parce qu'un vector, ça planque un tableau alloué dynamiquement , qui sera réalloué de temps en temps quand on ajoute des éléments. Et reallouer, pas forcément au meme endroit.

Si ce n'est que je n'ai parlé d'un tableau que pour le like, celui qui contient les référence vers les utilisateurs... je n'ai rien dit concernant les utilisateurs en eux même

On aurait cru que tu essayais de répondre à la question, qui ne portait pas sur les utilisateurs, mais sur les entités en général, et pourquoi il ne faut pas les allouer dans un vector.

Donc l'annuaire, c'est (par exemple) un ensemble (vector si on veut) de références à des objets abonnés, et dans chaque abonné, il y a un vecteur de références à ceux qu'il "like".

Question 1 : pourquoi des vecteurs de références, et pas d'objets directement ?