Je me rends compte que mon autre topic ´Encore une question tech.´ est presque disparu. Je m´y suis étendu en clarification et il est maintenant trop long à lire. Alors je repars un topic avec uniquement la question qui me concerne:

---

J´aimerais savoir si ce processus est propre ( je résume grossièrement ici celui que j´utilise dans mon dll)...

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 ?

Si c´est " illégal", comment pourrais-je faire pour libérer l´espace mémoire occupée par MonPointeur ( parce que, dans mon dll, c´est une image, information RGB/RGBA, qui va la-dedans, inutile de conserver ça après qu´OpenGL en fasse sa copie - question de sauver de l´espace) sans pour autant que l´objet face un truc louche si le pointeur repasse dans un resize ? Devrais-je redéclarer le pointeur après l´avoir deleter ?

Quelque chose du genre...
if(MonPointeur ! = NULL)
{
delete[] MonPointeur;
GLubyte *MonPointeur = NULL;
}

J´ai essayé de faire un resize ( sans redéclarer comme dans l´exemple précédent) sur un pointeur après un delete[] et ça n´a pas planter... mais je cherche la propreté ici !

Merci beaucoup !

Salut, désolé je ne peux pas t´aider pour ton problème; en revanche je me demandais si ton code serait correct si on se tenait à une programmation en C?
Car tu utilises le mot clé struct, qui n´est techniquement pas une classe, mais tu t´en sers comme tel, ce qui m´amène à penser qu´en C on peut utiliser des sortes de pseudos classes?

Heum... je ne connais pas les rigueurs du C comparativement à celle du C++. Je n´ai jamais fait de C pur, j´ai toujours travaillé dans un compilo de C++.

Je sais cependant que C ne gère pas la programmation orientée objet.

Hors, pour autant que je sache, une struct c´est comme une classe, la différence étant que, par défaut, les données qu´une struct contient sont public et non pas private. En gros, c´est de la programmation objet. Résultat, je ne crois pas que mon code fonctionne en C, non.

en C++, struct et class sont du meme ordre, il n´y a que le niveau d´acces par défaut des membres qui change ( public pour struct, private pour class). Ce code ne peut PAS compiler en C.

TechSlash : avais tu lu ma réponse sur ton post précédent ?

LGV, yep, j´ai bien lu ta réponse ( merci d´ailleurs). J´ai corrigé mon pojet par rapport à ce que tu m´as dis. Le problème, vois-tu, c´est que j´ai une structure qui contient ma texture dans une variable ( tableau/pointeur) ainsi que quelques autres variables qui renferment des informations encore utiles après le point où je peux vider le tableau/pointeur qui contient la texture - parce que OGL en fait sa copie -.

Alors je me dis que j´ai un objet dans lequel le tableau qui contenait des bytes de la texture est deleté. Jusque là tout beigne, ton explication m´a permis de corriger ma réallocation avec new GLubyte[0].

Mais j´aimerais pouvoir ensuite faire repasser ma structure dans la fonction qui attribue à la variable de texture le contenu RGB d´une image. Autrement dit, je veux vider un tableau qui est allouer dynamiquement et pouvoir le remplir plus tard et tout ça proprement. Ça ta réponse en le couvrait pas.

D´où ma longue " nouvelle" question qui, en gros, dit

si je delete[] un tableau alloué dynamiquement, est-ce que je peux faire un new[] dessus plus tard sans que ça soit louche.

tiens ben je viens de répondre sur l´autre en fait :D cf. ton premier topic

ok merci bien lgv
Donc même en C, on ne compile pas de struct?
Et est-ce que je peux compiler un . cpp, afin de donner un . o, et linker ce . o avec mes autres . o issus de . c, utilisant une classe définie dans le . o issu du . cpp? ( va y avoir des schémas de dessinés là )

Non, enfin techniquement c´est possible, mais c haut niveau. Le contraire est par contre plus simple:

toto.h:

void test();

toto.c->[compilo c]->toto.o

titi.hpp:

extern " C" {

1. include " toto.h"

};

titi.cpp->[compilo c++]->titi.o

titi.o|toto.o->linker->prog

haut niveau ? un coup de précompilo pour remplacer tous les public/protected/private par rien du tout, et je vais te le faire compiler moi ton code ; ) LOOOOL ( et encore...)
mais c´est ça qu´est marrant : feinte ici, feinte là, feinte par là-bas, feinte dans le coin, etc. On n´en finit pas :D

Oki! ben merci bien à tous, c´est assez intéressant du coup puisque je peux utiliser du cpp tout en restant avec un code en C pur, excepté la classe!

mais, euh... je comprends pas trop comment je dois faire...
J´ai le prototype de ma classe dans gn.h, sa définition dans gn.cpp; j´ai compilé gn.cpp en gn.o, dans test.c j´inclus gn.h, et je tape:

1. include " gn.h"

int main()
{
gn fstNombre(-224);
gn scndNombre(23);
(fstNombre + scndNombre).affiche();

return 0;
}

Mais j´ai plein d´erreurs??? Pourquoi?

t´aurais pas la bonne idée de nous donner les erreurs par hasard ? . ..

hum... non jlaurai pas eue tout seul

In file included from test.c:1:
gn.h:13: parse error before " gn"
gn.h:14: syntax error before ´{´ token
gn.h:18: parse error before ´:´ token
gn.h:20: warning: data definition has no type or storage class
gn.h:21: parse error before ´&´ token
gn.h:21: warning: data definition has no type or storage class
gn.h:23: parse error before ´;´ token
gn.h:24: warning: data definition has no type or storage class
gn.h:25: parse error before " operator"
gn.h:28: parse error before ´}´ token
test.c: In function `main´:
test.c:5: parse error before " fstNombre"
test.c:7: `fstNombre´ undeclared ( first use in this function)
test.c:7: ( Each undeclared identifier is reported only once
test.c:7: for each function it appears in.)
test.c:7: `scndNombre´ undeclared ( first use in this function)
test.c:10:2: warning: no newline at end of file

déjà ton gn.h est foireux visiblement ; pastes le code sur un site dédie et file un lien... Celui qui passera le prochain te fileras p-e un coup de main

ben là j´ai un souci: j´arrive plus à compiler mon . cpp
J´ai touché à qqch, mais je sais plus quoi...

pour le . h
http://walljv.free.fr/index.php?to=view&id=49

et le . cpp:
http://walljv.free.fr/index.php?to=view&id=50

Je sais que le code est dégueu lol, vous me le dites tout le temps, mais j´arrive pas à faire qqch de propre...

je n´ai pas le temps de tester sur le moment, mais qq conseils :

utilises des fonctions templates plutot que tes macros

pour les macros, parentheses les opérandes ( ça peut etre des expressions, et l´évaluation peut donner un mauvais resultat)

t´a un ; qui traine ligne 9 du . h

dans le . cpp , c´est la fete des magic numbers... fait des static const pour clarifier

oublie les alloc et les free, t´es en C++ il me semble

plein d´autres trucs, mais déjà améliorer ça, ça serait bien

comment ça la fete des magic numbers?
Et static const c´est quoi? parce que je connais const, mais static...

comment ça la fete des magic numbers?
Et static const c´est quoi? parce que je connais const, mais static...

magic number = nombre sans contexte aucun dont on a du mal à comprendre la signification... a regarder ton code, c´est la fete, 45, 38, 22, etc. ça ne veut rien dire si on ne comprend pas la logique de l´utilisation

alors que si tu mets des noms dessus, c´est plus clair ; exemple, si au lieu de mettre en brut 65 dans un algo qui traite des caractères, je définies une constante avec un nom explicite ( s_nAsciiA) on comprend tout de suite ce que c´est.

pour le static, je te renvoi à ton bouquin favori. Tu pourrais avoir :

static const int gn::s_nomDeMaConstante = 45;

et ça serait BCP plus clair dans le code

j´ai pas de bouquin, ms merci de ta réponse