OpenGL et allocation dynamique

Bonjour à tous,

Je viens de tomber sur un drôle de problème, et j'aurais aimé savoir si quelqu'un a déjà recontré ce cas avec une autre librairie.

Voici un code que j'ai ramené au plus simple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

#include <iostream>   int main (int argc, char * argv[]) { unsigned int * a = new unsigned int[16];   for ( unsigned int i = 0; i < 16; i++ ) std::cout << i << " : " << (unsigned int)a[i] << std::endl;   return 0; }

---

Si je le compile en tant que projet C++ simple, j'ai une série de zéros qui s'affichent, comme ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

0 : 0 1 : 0 2 : 0 3 : 0 4 : 0 5 : 0 6 : 0 7 : 0 8 : 0 9 : 0 10 : 0 11 : 0 12 : 0 13 : 0 14 : 0 15 : 0

---

Mais si je rajoute au compilateur -lGL pour lier la bibliothèque d'OpenGL et sans rien modifier d'autre dans le code source, j'obtient ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

0 : 841837922 1 : 775106862 2 : 923430771 3 : 909193830 4 : 1701013045 5 : 758132784 6 : 825386551 7 : 1667642678 8 : 808464486 9 : 757953056 10 : 808460400 11 : 808466480 12 : 807415856 13 : 825244216 14 : 892613664 15 : 808530231

---

Et c'est la que je commence à ne plus rien comprendre ...

Donc j'ai un projet utilisant OpenGL, et là ou je pensais allouer des valeurs à 0, je me retrouve avec de larges buffers pleins de valeurs à la noix, ce qui m'embête légèrement. Je peux toujours remettre des boucles un peu partout, mais je trouve ça tout même bizarre.
L'opérateur new n'est pas censé initialiser les valeurs a 0 en toutes circonstances?

Je suis sur une debian 64, avec le dernier pilote nvidia du site proprio (sans quoi pas de 3D).

Voila, celui qui a une idée :)

Salut,

contrairement à d'autres languages C++ (tout comme C ) ne garantissent pas l'initialisation de la mémoire allouée sur le tas ou la pile, seules les variables statiques sont initialisées à 0,

Cdt

Salut,

Comme l'a dit kessoufi, la mémoire alloué n'est pas initialisé. Elle vaut donc ce qu'il y avait dedans à ce moment là. Le fait que tu obtienne des zéros viens juste d'un gros coup de bol :ccool:

Bon ben, je sais pas où j'ai pêché que new initialisait les valeurs a 0 alors... LOL

Merci pour vos réponses. :ccool:

Bonjour,
Une initialisation est possible :

Code:

---

unsigned int * a = new unsigned int[16]();

---

C'est bien une paire de parenthèse vide qui est nécessaire et provoque une initialisation à 0 (ou appel du constructeur par défaut pour une classe). Pour un tableau tu ne peux mettre de valeurs : unsigned int * a = new unsigned int[16](0); => erreur

Ce qui donne :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#include <iostream>   int main (int argc, char * argv[]) { unsigned int * a = new unsigned int[16]();   for ( unsigned int i = 0; i < 16; i++ ) std::cout << i << " : " << a[i] << std::endl;   return 0; }

---

On ne répétera jamais assez : std::vector à la place des allocations new[]/delete[] ... En plus tu peux initialiser avec une valeur spécifique :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

#include <iostream> #include <vector>   int main (int argc, char * argv[]) { std::vector<unsigned int> a(16,42);   for ( unsigned int i = 0; i < 16; i++ ) std::cout << i << " : " << a[i] << std::endl;   return 0; }

---

Je ne connaissais pas les parenthèses vident avec l'allocation d'un tableau.

Par contre, je ne pense pas que je vais pouvoir utiliser des std::vector partout. Parce que je dois créer des tableau de float (GLfloat pour être précis) et les fonctions de chargement d'OpenGL attendent des pointeurs du type "GLfloat *". J'ai pas vu de méthode comme pour std::string ou on sort un pointeur avec c_str() par exemple.

Maintenant je penserais a std::vector dans tout les autres cas :)

merci

Code:

---

&a[0]

---

(attention avec ce genre de blagues; un push_back et paf, ton pointeur a changé!)

Citation:

---

Envoyé par screetch

(attention avec ce genre de blagues; un push_back et paf, ton pointeur a changé!)

---

On est d'accord. Mais, un push_back supposerait avec des pointeurs bruts une réallocation. Donc, le problème serait le même.
L'intérêt &[0] est bien de passer le tableau à une interface C le temps d'un traitement. Le pointeur (comme un itérateur) n'a pas vocation à être gardé.

D'accord, j'aurais même pas penser à faire comme avec un tableau classique.

Bon ben j'en aurais appris des choses aujourd'hui avec cette mésaventure de new :)

Sachant qu'il n'y a plus d'obstacle technique a l'emploi des std::vector. Une question me vient, cela vaut il la peine que je remplace mes new[]/delete[], si je sais qu'une fois alloués mes tableaux ne changeront plus jamais de taille?
C'est généralement des énormes tableaux de floats pour afficher un objet en 3D.

J'ai encore cette petite hésitation a me dire que je vais perdre en memoire/performance en utilisant des conteneurs plutot que du C classique.

merci

Tu vas perdre 24 octets (à peu près) en utilisant un std::vector par rapport à un tableau classique, tu vas rien perdre niveau perf (peut être 1 ou 2 cycles lors de ton &[0]) et tu vas énormément gagner en facilité d'utilisation et en robustesse ;)

Alors 100000 fois oui pour utiliser un std::vector plustot qu'un tableau classique !

A noté aussi que les conteneurs STL verifient les indices (à activer quelque part lors de la compilation mais je sais plus où :oops:), donc plus de segfault intempestif parce que tu a dépassé ton tableau, à la place tu aura une jolie exception qui t'amènera directement au bon endroit :ccool:

Je m'attendais un peu a réponse comme ça :)

ben ok, merci beaucoup.

Citation:

---

Envoyé par 3DArchi

Code:

---

&a[0]

---

---

Bonjour à tous (pour mon premier message),
c'est un peu en dehors du sujet initial mais ça ne vaut pas le coup de lancer un nouveau sujet. J'avais essayé cette méthode qui compilait correctement sur gcc
mais lorsque j'avais essayé de compiler le même code sur Visual (version 8), il compilait mais le code plantait. Sur visual les vector ne seraient pas ré-implémentés ?

Si ton tableau est de taille fixe un std::vector est tout indiqué. Si en plus tu connais sa taille à la compilation, tu peux utiliser std::array (C++0x), std::tr1::array (TR1) ou boost::array (si ni 0X ni TR1) qui te permettront de ne pas avoir l'overhead du std::vector (les 24 octets en plus).

@arthurG
Bien que le &a[0] ne soit pas dans la norme C98, je n'ai jamais vue d'implémentation qui l'interdisait...
Ton vecteur n'est pas vide au moins ? Peut-tu nous montrer le code qui plante ?

MSVC l'interdit

Citation:

---

When compiling with _SECURE_SCL 1, a runtime error will occur if you attempt to access an element outside the bounds of the vector. See Checked Iterators for more information.

---

c'est un comportement indeterminé et sous MSVC ca produit une erreur, sous GCC ca compile et marche.

Ah, voila, le _SECURE_SCL c'est ce que je cherchait tout à l'heure pour fliquer les vecteur :mouarf:
Par contre, ça n'explique pas pourquoi son &a[0] ne marche pas (sauf si le vecteur est vide, auquel cas, ça finira bien par faire un segfault même avec gcc)

Citation:

---

Envoyé par norme C++98

23.2.4 Class template vector [lib.vector]
1 [...]The elements of a vector are stored contiguously, meaning that if v is a vector<T, Allocator> where T is some type other than bool, then it obeys the identity &v[n] == &v[0] + n for all 0 <= n < v.size().

---

Pour moi cela signifie de facto que que peut récupérer &v[0] et parcourir le tableau jusqu'à sa limite.

Citation:

---

&v[n] == &v[0] + n for all 0 <= n < v.size().

---

ici on peut avoir v.size() == 0 donc n n'est pas strictement inférieur a v.size()
si le vecteur est vide, v[0] est un comportement indeterminé (et donc par extension &v[0]) qui sous visual C++ ne fera pas le café mais lancera une assertion si _SECURE_SCL est défini

c'est un cas particulier donc si le vecteur est vide.

Citation:

---

Envoyé par arthurG

Bonjour à tous (pour mon premier message),
c'est un peu en dehors du sujet initial mais ça ne vaut pas le coup de lancer un nouveau sujet. J'avais essayé cette méthode qui compilait correctement sur gcc
mais lorsque j'avais essayé de compiler le même code sur Visual (version 8), il compilait mais le code plantait. Sur visual les vector ne seraient pas ré-implémentés ?

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

void fonction(unsigned * v, unsigned l) { for(;l>0;--l) { *v++=42; } }   #include <iostream> #include <vector> #include <algorithm> #include <iterator>   int main () { std::vector<unsigned int> a(16); fonction(&a[0],a.size()); std::copy(a.begin(),a.end(),std::ostream_iterator<unsigned int>(std::cout,"\n"));   return 0; }

---

Compilé avec MinGW, Visual 2010 et Visual 2008

Citation:

---

Envoyé par screetch

ici on peut avoir v.size() == 0 donc n n'est pas strictement inférieur a v.size()
si le vecteur est vide, v[0] est un comportement indeterminé (et donc par extension &v[0]) qui sous visual C++ ne fera pas le café mais lancera une assertion si _SECURE_SCL est défini

c'est un cas particulier donc si le vecteur est vide.

---

Oui, oui. 0 comme un accès hors borne est un comportement indéterminé (enfin, un pointeur à n doit pouvoir se comparer mais pas se déréférencer alors qu'un pointeur <0 et >n ne peut ni se comparer ni se déréférencer => undefined behaviour).

Merci pour vos réponses.
Je ne peux plus montrer le code, comme il posait problème je l'ai modifié en utilisant des tableaux standarts. D'après ce que vous dites l'erreur devait venir de mon code alors, et pas d'une éventuelle réécriture des vector de la part de visual (version 8 qui date un peu quand même).
En tout cas l'écriture &v[0], même si elle n'est pas standart, est utilisée par Sutter dans More Exceptional C++ il me semble, donc je pense que ça vaut le coup.