[vecteur] passage d'adresse

Version imprimable

28/12/2005, 20h22
ZaaN

[vecteur] passage d'adresse

hello,

Peut passer une adresse d'un vecteur de la meme manière que celle d'un tableau, dans le but de permettre à un autre objet d'aller lire (lecture seule) la collection sans recopie ?

merci d'avance :D

PS peut etre ai je meilleure temps de faire un vecteur de ptr et de recopier le vecteur puique que je fais de la lecture seule ?
28/12/2005, 20h30
Laurent Gomila

Citation:

Peut passer une adresse d'un vecteur de la meme manière que celle d'un tableau, dans le but de permettre à un autre objet d'aller lire (lecture seule) la collection sans recopie ?

Pourquoi ne pas simplement essayer ? (bon, la réponse étant quand même "oui"). Tu peux même utiliser un passage par référence, ce sera encore mieux.

Citation:

PS peut etre ai je meilleure temps de faire un vecteur de ptr et de recopier le vecteur puique que je fais de la lecture seule ?

Surtout pas.
28/12/2005, 21h36
JolyLoic
Je ne suis pas certain du tout de ce que tu veux faire. Mais sache à tout hasard qu'une fonction prenant en paramètre un pointeur sur un tableau :

Code:

void f(T* t, int nbElem);

Peut être appelée ainsi :
Code:

1 2 3 vector<T> v; f(&v[0], v.size());
29/12/2005, 13h00
Volune
Citation:
Envoyé par JolyLoic

Je ne suis pas certain du tout de ce que tu veux faire. Mais sache à tout hasard qu'une fonction prenant en paramètre un pointeur sur un tableau :

Code:

void f(T* t, int nbElem);

Peut être appelée ainsi :

Code:

1 2 3 vector<T> v; f(&v[0], v.size());
Je ne m'y risquerais pas. L'adresse de v[0] n'est pas, il me semble, garantie d'être constante durant l'exécution de f(). En fait elle ne l'est pas si le vecteur risque d'être modifié durant la fonction.
En revanche avec ceci, il y a probablement moins de risque :

Code:

void f(const T* t, int nbElem);
29/12/2005, 13h06
JolyLoic

Avec ton écriture, on empêche de modifier les éléments du vecteur. Mais modifier ces éléments n'a aucune incidence. C'est ajouter/enlever des éléments qui pourrait causer problème, ce que la fonction n'est pas à même de faire, sauf si elle connait v par ailleurs.

A priori on ne sait pas de quelle manière la fonction agit sur les objets, ni dans le cas actuel si les objets agissent sur le vecteur.

Exemple :

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
 
class Class
{
	vector<Class> &v;
public:	
	Class(vector<Class> &vect) : v(vect) {}
	Class(const Class &c) : v(c.v) {}
	~Class() {}
	Class & operator = (Class &) {}
	Class & operator ++ (void)
	{
		v.push_back(*this);
		return *this;
	}
};
 
template<class T>
void test(T *t, int ne)
{
	for (int i = 0; i < ne; ++i, ++t) ++*t;
}
 
int main(void)
{
	vector<Class> v;
	Class c(v);
	for (int k = 0; k < 5; ++k) v.push_back(c);
	test<Class>(&(v[0]), v.size());
	return 0;
}

Il y a donc un dangers, qu'il est bon de signaler ;)

Ok. D'ailleurs, ce problème peut aussi apparaître avec ta signature pour f...
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 struct ALaCon { vector<ALaCon> *v; }; void f(const ALaCon* t, int nbElem) { ALaCon a; t->v->push_back(a); } int main() { vector<ALaCon> v; ALaCon a; a.v = &v; v.push_back(a) ; f(&v[0],1); }
Ou plus simple encore :

Code:

int f(T const * t, int nbElem, vector<T> v)

Pour peu que le troisième élément réfère au même tableau que le premier, on peut avoir des surprises.

Il n'est reste pas moins que le code marche dans les cas non pathologiques, et que ce qui est important, c'est de savoir que la valeur retournée par &v[0] n'est valide que jusqu'à la prochaine modification du nombre d'éléments du vector, ce qu'aucune déclaration de fonction n'est capable d'assurer.