Discussion :

[Laurent Gomila]

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

*(arrivee.begin() + i)

Bel emberlificotement pour signifier arrivee[i]

[poukill]

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

Merci !

@Laurent: ben oui, j'avais pas fait gaffe, mais tu as complètement raison! Parti dans le feu de l'action...

[Pragmateek]

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.

[Pragmateek]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

peut être.

[poukill]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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!

[loufoque]

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.

[poukill]

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 :

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
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 :

Sélectionner tout - Visualiser dans une fenêtre à part

float * H_v = new float[2];

ou alors comme je l'ai fait un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 !

[poukill]

euh... personne pour m'éclaircir??? ne serait-ce qu'un tout petit peu...

[Matthieu Brucher]

Non, c'est très bien comme ça.

[poukill]

bon ok, merci

Mais la remarque de seriousme ?

Je marque quand même résolu...

[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.

[Laurent Gomila]

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à

[Pragmateek]

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?
Je n'utilise peut être pas les bon termes.

[Laurent Gomila]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[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.

[Pragmateek]

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

En effet.