J´ai terminé ! Si quelqu´un veut un . dll aux symbols exportés ( donc qui vient avec un . h et un . lib, prévu pour VC++ . NET) pour lire des tga 24/32 bits avec ou sans compression RLE, vous pouvez me faire signe ! J´ai même écrit le décodeur RLE sans NeHe ( faut pas m´en vouloir pour l´auto-publicité, je suis fier de moi ) !

Quoiqu´il en soit, j´ai une question. En OpenGL, une fois la texture binder, un peu libérer sans problème les données RGB en chargé précédemment en RAM ( OGL fait sa propre copie des informations requises).

Les guides que j´ai vu font toujours un free ( ou un delete, c´est selon) de la variables dynamiques qui a servi pour les infos RGB.

Mon . dll fonctionne avec pour idée de base un objet et une fonction. On déclare un objet, on lance la fonction en passant un filename et l´objet en paramètre et l´objet est bon tant que rien ne call le destructeur. Ainsi, je ne veux pas faire un delete[] ( C++ , je n´utilise pas malloc et free ) . Est-ce que c´est propre de faire un new de taille 0 ? Question de libérer la mémoire sans rendre la variable inutilisable.

Jusqu´à maintenant c´est ce que je fais, ça fonctionne sans plantage. Mais bon, aucune certitude, je connais pas vraiment les outils qui pourraient me permettre de constater une erreur en mémoire ou quoique se soit du genre.

Merci !

Errrr... quelques corrections pour la clareté... merde j´arrive jamais à me relire dans cette foutue minuscule boîte de texte de forum.

" un peu libérer sans"
on peut libérer sans

" données RGB en chargé"
données RGB chargé

Hah et encore pour clarifier...

" Est-ce que c´est propre de faire un new de taille 0 ? "

On parle ici de quelque chose du genre

GLubyte *Variable = new GLubyte[TAILLE_TGA];

et plus tard...

Variable = new GLubyte[0];

• • En fait, pour le plaisir de préciser, j´initialise Variable avec un new GLubyte[0] et je la resize avec TAILLE_TGA plus tard. Ainsi, Variable est obligatoirement une allocation dynamique et le delete[], que je fais dans le destructeur de mon objet, ne peut pas planter, même s´il est fait sans que la réallocation à la taille du TGA est été faite préalablement ( logiquement en tout cas). Mais c´est du détail...

bon, autant le dire tout de suite, j´ai pas *tout* saisi à ta démarche :-?

virer les données que t´as chargées à la main pour créer ta texture, c´est sans risque, à partir du moment où OpenGL en a sa propre copie.

" l´objet est bon tant que rien ne call le destructeur. Ainsi, je ne veux pas faire un delete[]"

je saisis pas le lien :-?

Dans tous les cas, le malloc ou ::operator new ou new [] de taille zero est absolument IGNOBLE. Un tableau ne peut PAS avoir une taille nulle : d´ailleurs si tu testes ton pointeur apres un new [0] tu constateras qu´il est invalide.. Si si...

La manière de procéder usuelle :

dans ta classe, t´as un pointeur, disons :
CHAR *m_pData;

dans le ctor, on l´init ou le fixe à NULL :
MyClass::MyClass() : m_pData(NULL)
{
}

dans le dtor, on le delete SI il est valide :

1. define SAFE_DELETE(p) { if ( p) { delete ( p): ( p) = NULL; } }

MyClass::~MyClass()
{
SAFE_DELETE(n_pData);
}

comme ça, aucune risque et c´est propre
La méthode est la meme avec des new/delete []

ensuite, si tu as besoin de savoir si tu objet contient des infos valides, il te suffit d´implementer une méthode en ce sens, ex :
BOOL MyClass::isValid() const
{
return m_pData ! = NULL;
}

Enfin, pour améliorer le design global, tu peux masquer tout ça en créer un TextureManager ou dans le style ; en gros, un singleton qui charge des textures à la demande, gère leur durée de vie, et integre un systeme d´indexation ( pour éviter le chargement multiple d´une meme texture, ou pour les trier en vue du rendu, etc.)

Je vois, je vais donc virer une partie de mon système pour éviter de faire cette gaffe.

Pour, disons, simplifier un peu ma question:

est-ce qu´il y a un problème à assigner une variable dynamiquement après l´avoir deleter ?

du genre...

char *message = new char[10];
delete[] message;
char *message = new char[xx];

En gros je cherche simplement à libérer une variable allouer dynamiquement sans la rendre inutilisable.

et merde

je voulais dire

char *message = new char[10];
delete[] message;
message = new char[xx];

Je viens de faire quelques corrections, j´aimerais savoir si ce processus est propre ( je le résume grossièrement ici)

J´ai un pointeur dans un objet

ex.:

struct MonObjet
{
GLubyte *MonPointeur

MonObjet();
~MonObjet();
void FreePtr();

}InstanceDeMonObjet;

J´ai un constructeur qui initialise le contenu de mon objet...

MonObjet::MonObjet()
{
MonPointeur = NULL;
}

J´ai un destructeur qui efface le pointeur seulement s´il n´est plus NULL... Hors, c´est un destructeur donc, normalement, une fois qu´il est lancé, pour InstanceDeMonObjet, InstanceDeMonObjet n´existe plus.

MonObjet::~MonObjet()
{

if(MonPointeur ! = NULL)
{
delete[] MonPointeur;
}

}

J´ai une fonction qui efface le pointeur sans pour autant détruire InstanceDeMonObjet.

void MonObjet::FreePtr()
{

if(MonPointeur ! = NULL)
{
delete[] MonPointeur;
}

}

J´ai une fonction - hors de l´objet - qui alloue dynamiquement MonPointeur à la grosseur " taille".

MonPointeur = new GLubyte[taille];

--

Ainsi, ma question est, si je lance

InstanceDeMonObjet.FreePtr();

est-ce que InstanceDeMonObjet va amener une opération très louche s´il repasse par la procédure qui fait

MonPointeur = new GLubyte[taille];

ou est-ce qu´il est légal de resizer un pointeur après effacement ?

char *message = new char[10];
delete[] message;
message = new char[xx];

est propre.

tu ne peux pas " rendre" une variable " inutilisable", à partir du moment où elle connue dans la portée en cours, tu en fait ce que tu veux... Donc enchainer les new et les delete sur un meme pointeur, c´est tout à fait correct, à condition qu´au final tu delete bien tout ce que tu new ( du verbe " newer" c´est bien connu...)

Merci beaucoup, c´est ce que je voulais savoir ! Mon . dll est donc propre . Je vais devoir résumer un peu mes questions je pense, y´a eu de l´exagération ici .