vie d'un pair < >

Version imprimable

vie d'un pair < >

Bonjour à tous, je me demandais si ce code là était correct? peut-on renvoyer une paire d'éléments comme ceci? La variable ne va t-elle pas mourir à la fin de la fonction (et donc le programma qui l'appelle va se planter lamentablement).
Faut-il détruire la paire?

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

 
template <typename T> std::pair<float, float> pointInterpolation(std::pair <int, int>& H, 

std::vector< std::pair <int, int> >& depart, const cimg_library::CImg<T>& u, constfloat coeff_mul) {std::pair<float, float> H_v; //vecteur déplacement pour le point à remplir

int a = depart.size();

/* Allocation dynamique de mémoire */
std::vector< std::pair <int, int> > pointschoisis;

// calcul des points nécessaires pour l'interpolation
nProchePoints(H, depart, NBPOINTSCHOISIS, pointschoisis);
 
int x,y; // point de controle regardé
float d; // distance entre le point courant et le point de controle
float D=0; // distance totale
float v_x,v_y; // vecteur déplacement du point de controle

 
 
 

for (int i=0; i<NBPOINTSCHOISIS; i++ ) {x = (pointschoisis.begin() +i)->first;
y = (pointschoisis.begin() +i)->second;
v_x = u(x,y,0);
v_y = u(x,y,1);
d = dist(H, pointschoisis[i]);
D+=1/d; 
 
 
// pour la normalisation
H_v.first += v_x / d;
H_v.second += v_y / d;

 
 
}
H_v.first = H_v.first/D;
H_v.second = H_v.second/D;
return H_v;

 
 
}

Merci à vous ! ;)

23/05/2006, 16h54
Matthieu Brucher

C'est le principe du passage par valeur, la variable sera recopiée.
23/05/2006, 16h58
poukill

Citation:

Envoyé par Miles

C'est le principe du passage par valeur, la variable sera recopiée.

C'est mieux ou pas que de renvoyer un float* ?
Vu que dans ce cas, il n'y a pas de copie....;)
23/05/2006, 17h00
Matthieu Brucher

Sauf que pour un float*, tu as de l'allocation dynamique, alors avant que tu constates qu'effectivement c'est critique au niveau temps, utilise le passage par valeur.
23/05/2006, 17h03
Laurent Gomila

Il faut arrêter de voir la recopie comme un démon tout droit sorti de l'enfer ; au contraire c'est bien souvent la meilleure solution.

Ca posera très rarement problème, encore plus pour une simple paire de flottants.
23/05/2006, 17h05
poukill
Mais là aussi il y a de l'allocation dynamique non?
Sinon, ça ne marcherait pas.

Exemple
Code:

1 2 3 4 5 int *maFonction (....) { int H[5]={0,1,2,3,4}; return(H); }
plante car la variable est détruite avant même d'être renvoyée, non?
23/05/2006, 17h07
poukill

Citation:

Envoyé par Laurent Gomila

Il faut arrêter de voir la recopie comme un démon tout droit sorti de l'enfer ; au contraire c'est bien souvent la meilleure solution.

Ca posera très rarement problème, encore plus pour une simple paire de flottants.

Oui, je comprend bien Laurent, je m'y mets!!! C'est d'ailleurs sur les conseils de Miles et autres que j'ai tout recodé dans cette optique!;)
Preuve de bonne volonté non?:mrgreen:
23/05/2006, 17h07
Pragmateek
Citation:
Envoyé par poukill

Mais là aussi il y a de l'allocation dynamique non?
Sinon, ça ne marcherait pas.

Exemple

Code:

1 2 3 4 5 int *maFonction (....) { int H[5]={0,1,2,3,4}; return(H); }

plante car la variable est détruite avant même d'être renvoyée, non?
Pour que ça marche il faut allouer dynamiquement H.
23/05/2006, 17h08
Laurent Gomila

Citation:

Mais là aussi il y a de l'allocation dynamique non?

Non. Tu en vois où ?

Citation:

Exemple

Dans ton exemple tu renvoies un pointeur sur le tableau, pas une copie de celui-ci (ce qui n'est d'ailleurs pas réalisable directement pour ce genre de tableaux).
23/05/2006, 17h10
poukill

Citation:

Envoyé par seriousme

Pour que ça marche il faut allouer dynamiquement H.

C'est pour ça que je dis qu'il doit y en avoir pour la paire???8O
23/05/2006, 17h12
poukill

Citation:

Envoyé par Laurent Gomila

Dans ton exemple tu renvoies un pointeur sur le tableau, pas une copie de celui-ci (ce qui n'est d'ailleurs pas réalisable directement pour ce genre de tableaux).

Ah ok, j'ai compris... Le pointeur pointera alors sur une zone non allouée...
Donc pair renvoie une copie, ce qui fonctionne évidemment!;)

Merci Laurent, Miles et seriousme !
23/05/2006, 17h15
Pragmateek

Citation:

Le pointeur pointera alors sur une zone non allouée...

Le problème est que la zone n'est plus réservé pour la "pair" donc comportement indéfini.
23/05/2006, 17h17
Matthieu Brucher

Citation:

Envoyé par poukill

C'est pour ça que je dis qu'il doit y en avoir pour la paire???8O

Allocation dynamique = malloc/free ou new/delete.
23/05/2006, 17h24
poukill

Citation:

Envoyé par seriousme

Le problème est que la zone n'est plus réservé pour la "pair" donc comportement indéfini.

Pourtant, Laurent dit qu'il n'y a pas de problème en renvoyant un pair? Pourquoi un comportement indéfini?

@Miles : oui bien sûr. Alors dans mon cas, il faudrait que je fasse un new pair ?
23/05/2006, 17h27
Matthieu Brucher

Il parle de la "pair", pas du std::pair<>, mauvaise utilisation d'un mot...

Pourquoi vouloir faire un new ??? C'est largement plus léger de faire un passage par copie qu'une allocation mémoire pour un std::pair. Où ai-je dit d'utiliser l'allocation dynamique ?
23/05/2006, 17h28
Pragmateek

Citation:

Laurent dit qu'il n'y a pas de problème en renvoyant un pair

En tant que paramètre d'une fonction.

Citation:

Pourquoi un comportement indéfini

Car on lit une zone mémoire qui peut être réutilisée pour stocker d'autres variables, puisqu'elle n'est plus réservé pour le "pair" créé dans la fonction.
23/05/2006, 17h29
Matthieu Brucher

Citation:

Envoyé par seriousme

En tant que paramètre d'une fonction.

Car on lit une zone mémoire qui peut être réutilisée pour stocker d'autres variables, puisqu'elle n'est plus réservé pour le "pair" créé dans la fonction.

Je ne sais pas trop ce que tu dis, si tu pouvais un peu expliciter sans quoi on va vraiment perdre poukill...

Laurent ne parlait pas de passer un pointeur vers un std::pair, que je sache...
23/05/2006, 17h31
Pragmateek

Citation:

Laurent ne parlait pas de passer un pointeur vers un std::pair, que je sache...

Je parlais du passage par valeur à une fonction au lieu d'utiliser un pointeur.

of course! Ok merci tout le monde!
J'en profite pour glisser un tout petit pb pour ne pas polluer le forum:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 template <typename T> cimg_library::CImgl <T> affichageArrivee (std::vector < std::pair <int, int> >& arrivee, cimg_library::CImgl <T>& visu) { const unsigned char green[3]={0,255,0}; for (int i=0; i <arrivee.size(); i++) {int x = (arrivee.begin() + i)->first; int y = (arrivee.begin() + i)->second; visu[1].draw_rectangle(x -1, y-1, x+1, y+1, green, 1); } return visu; }
Le compilo me met un warning incompatibilié signed/unsigned sur la ligne rouge. Y a t-il une façon plus propre de coder ceci sans faire un cast?;)

23/05/2006, 17h40
Matthieu Brucher

Citation:

Envoyé par seriousme

Je parlais du passage par valeur à une fonction au lieu d'utiliser un pointeur.

Ah... Je ne vois toujours pas le rapport avec Laurent, mais bon. A la limite, on peut faire un passage par référence.

Pour ton pb :
size() renvoie un unsigned int, tu compares avec un int, normal qu'il y ait le warning.
23/05/2006, 17h41
Laurent Gomila

Déclarer i en std::size_t ? Ou plus simplement itérer avec un itérateur plutôt qu'un indice ?

Citation:

*(arrivee.begin() + i)

Bel emberlificotement pour signifier arrivee[i] :D
23/05/2006, 17h49
poukill

Citation:

Envoyé par seriousme

Car on lit une zone mémoire qui peut être réutilisée pour stocker d'autres variables, puisqu'elle n'est plus réservé pour le "pair" créé dans la fonction.

Moi c'est ce qu'on m'avait appris à l'école, que l'espace n'étant plus reservé, on perdait l'information... Maintenant, c'était à l'époque des pointeurs...
est-ce que je pourrai avoir plus d'info là dessus, car c'est pas très clair:koi:

Merci !

@Laurent: ben oui, j'avais pas fait gaffe, mais tu as complètement raison! Parti dans le feu de l'action...:mrgreen:
23/05/2006, 18h12
Pragmateek

Citation:

on perdait l'information

Si je ne me trompe la zone est accessible mais il n'y a aucune garantie que les données stockées précedemment y soit toujours, et encore moins qu'elle le resteront.
23/05/2006, 18h13
Pragmateek

Code:

int *buf = newint[4*a+1];

Code:

int *buf = new int[4*a+1];

peut être.
23/05/2006, 18h16
poukill

Citation:

Envoyé par seriousme

Code:

int *buf = newint[4*a+1];

Code:

int *buf = new int[4*a+1];

peut être.

non ça c'est le copier/coller qui marche pas bien....
Mais je vais chercher !

Merci!
24/05/2006, 02h51
loufoque

Citation:

Vu que dans ce cas, il n'y a pas de copie....

Les compilateurs modernes ne feront de toutes façons pas de copie.

Sinon pour ton problème avec i, il faut mettre std::vector < std::pair <int, int> >::size_type et non int.

Citation:

Envoyé par seriousme

Si je ne me trompe la zone est accessible mais il n'y a aucune garantie que les données stockées précedemment y soit toujours, et encore moins qu'elle le resteront.

Donc pour toi, c'est une betise de faire le code suivant :
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 template <typename T> std::pair<float, float> pointInterpolation(std::pair <int, int>& H, std::vector< std::pair <int, int> >& depart, const cimg_library::CImg<T>& u, constfloat coeff_mul) { std::pair<float, float> H_v; //vecteur déplacement pour le point à remplir int a = depart.size(); /* Allocation dynamique de mémoire */ std::vector< std::pair <int, int> > pointschoisis; // calcul des points nécessaires pour l'interpolation nProchePoints(H, depart, NBPOINTSCHOISIS, pointschoisis); int x,y; // point de controle regardé float d; // distance entre le point courant et le point de controle float D=0; // distance totale float v_x,v_y; // vecteur déplacement du point de controle for (int i=0; i<NBPOINTSCHOISIS; i++ ) {x = pointschoisis[i].first; y = pointschoisis[i].second; v_x = u(x,y,0); v_y = u(x,y,1); d = dist(H, pointschoisis[i]); D+=1/d; // pour la normalisation H_v.first += v_x / d; H_v.second += v_y / d; } H_v.first = H_v.first/D; H_v.second = H_v.second/D; return H_v; }
Ais-je donc intérêt à faire un

Code:

float * H_v = new float[2];

ou alors comme je l'ai fait un

Code:

std::pair <int, int> H_v;

Le but étant, au final, que ma fonction renvoi quelque chose de non vide pour la suite !!!!!!! ^^
C'est très important pour moi que vous mettiez d'accord sur le fait qu'on puisse au non procèder comme je l'ai fait dans ce petit bout de code!
Merci beaucoup pour vos éclaircissements ! ;)

24/05/2006, 10h42
poukill

euh... personne pour m'éclaircir??? ;) ne serait-ce qu'un tout petit peu...
24/05/2006, 11h20
Matthieu Brucher

Non, c'est très bien comme ça.
24/05/2006, 11h27
poukill

bon ok, merci

Mais la remarque de seriousme ?:aie:

Je marque quand même résolu...
24/05/2006, 16h33
Pragmateek

Je parlais du cas des variables locales statiques.
Pour ce qui est des "pair" et autres objets dynamiques apparemment il n'y a pas les mêmes problèmes.
24/05/2006, 19h34
Laurent Gomila

Citation:

Pour ce qui est des "pair" et autres objets dynamiques apparemment il n'y a pas les mêmes problèmes

il n'y a rien de dynamique là-dedans... Honêtement je crois que tu embrouilles tout le monde pour rien, là ;)
24/05/2006, 19h41
Pragmateek

Citation:

Envoyé par Laurent Gomila

il n'y a rien de dynamique là-dedans... Honêtement je crois que tu embrouilles tout le monde pour rien, là ;)

Ce que j'appelle objet dynamique ce sont les objets redimensionnable après compilation, ce qui est le cas des conteneurs de la STL, non?:roll:
Je n'utilise peut être pas les bon termes.:oops:

Un std::pair n'a rien de dynamique.

Code:

1
2
3
4
5
6
7
8
9
namespace std
{
    template <typename T, typename U>
    struct pair
    {
        T first;
        U second;
    };
}

24/05/2006, 20h53
Luc Hermitte

Dès que tu as une sémantique de valeur (copiabilité + comparabilité), et plus précisément les opérations de copie, le retour par copie est ... OK. Surprenant, non?
Dès que tu as une sémantique de référence (des pointeurs), il faut commencer à réfléchir.

std::pair<> tente de s'appropier l'éventuelle sémantique de copie de ce qu'elle contient. Si le truc à l'intérieur est copiable. Tout va bien. Si le truc à l'intérieur est un pointeur, il faut réfléchir.

Tous les conteneurs standard, et nombre de ceux qui s'en inspirent, sont copiables.
24/05/2006, 22h32
Pragmateek

Citation:

Envoyé par Laurent Gomila

Un std::pair n'a rien de dynamique.

En effet.:oops::mrgreen: