bonjour,
 
je travaille sur un projet en C++ embarqué. J'ai pas droit par defaut aux allocateurs new, delete et leurs versions tableaux.
pour new et new[], j'ai fait 2 surcharges a la con a base de malloc/calloc (oui tres con je sais )
et j'aurais besoin tres vite d'une implémentation correcte de delete et delete[]
(m'etais jamais penché sur ces deux operateurs en details )

ben free, non ?
 
edit : vois pas trop ce que tu nous a magouillé avec tes "surcharges a la con"

ben ...ca marche po des masses ....
 
pour delete simple oui, ca peut passer si je vais :
 
1)appel du destructeur
2)Free
3)pointeur mis a nul
 
mais ca plante pour les tableaux d'objets alloues avec calloc ...

chrisbk a écrit a écrit : ben free, non ?   edit : vois pas trop ce que tu nous a magouillé avec tes "surcharges a la con"

j'y ai pas droit a new et delete, c'est la premiere fois qu'ils font du C++ pour leur projet embarque donc je bosse sur un noyau Linux, gcc 296, adapte en cross compiler power pc
et generation de code pour un OS qui n'a pas le support de ces fonctions.

BotMan a écrit a écrit : ben ...ca marche po des masses ....   pour delete simple oui, ca peut passer si je vais :   1)appel du destructeur 2)Free 3)pointeur mis a nul   mais ca plante pour les tableaux d'objets alloues avec calloc ...

 
hum y'a des chances, si je me rapelle bien, calloc = malloc + memset(..,0,...), ce qui pue pas mal pour un tableau d'objet car en faisant un memset bourrin sur des objets, tu efface la vtable dedits obj
 
Donc si ton constructeur est en virtuel, ca plantera a la desallocation (ou bien si tu essaye d'appeler des fonctions virtuelles)
 

Y aurait moyen de visualiser la déclaration originale new, revue calloc ou malloc, et l'ancien delete / nouveau free du truc qui coïnce ???
Y a peut-être "astuce" basique.

ca plante que sur les tableau alloué au calloc ou aussi sur ceux alloué au malloc ?

le new ca va, le new[] aussi, mais le free
je trouve pas de code source sur le web

BotMan a écrit a écrit : le new ca va, le new[] aussi, mais le free je trouve pas de code source sur le web

 
 
et tout mon delire sur la vtable ?
t'avais des destructeurs virtuels ?

BotMan a écrit a écrit : le new ca va, le new[] aussi, mais le free

je pige pas du tout le problème ... si tu surcharges le new [], tu dois appeler calloc, boucler pour mettre les vtables (s'il y en a), appeler les constructeurs . donc pareil mais à l'envers pour le delete[] ...
 

ckoi un vtable

BotMan a écrit a écrit : ckoi un vtable

 
les fonctions virtuelles c juste des pointeurs de fonctions
ces pointeurs sont stocké dans chaque objet, et la ou c stocké c'est la vtable

BotMan a écrit a écrit : ckoi un vtable

hou
 
c'est la virtual table, un pointeur qui contient les pointeurs vers les fonctions de l'objet. ce pointeur est généralement situé au tout début de l'objet alloué. il est présent seulement si l'objet a des méthodes virtuelles.
 
tu espères surcharger des opérateurs d'alloc c++ sans savoir ça ?

chrisbk a écrit a écrit :     les fonctions virtuelles c juste des pointeurs de fonctions ces pointeurs sont stocké dans chaque objet, et la ou c stocké c'est la vtable

j'appelle ca une classe abstraite moi ca
mais bon, personne n'a des sources pour delete[]

BotMan a écrit a écrit : j'appelle ca une classe abstraite moi ca mais bon, personne n'a des sources pour delete[]

 
 
nan, spa la meme chose, c l'emplacement physique ou sont stocké ces ptr

youdontcare a écrit a écrit : hou   c'est la virtual table, un pointeur qui contient les pointeurs vers les fonctions de l'objet. ce pointeur est généralement situé au tout début de l'objet alloué. il est présent seulement si l'objet a des méthodes virtuelles.   tu espères surcharger des opérateurs d'alloc c++ sans savoir ça ?

bah je fais mon calloc moi

chrisbk a écrit a écrit :       nan, spa la meme chose, c l'emplacement physique ou sont stocké ces ptr

d'accord mais j'en aurai pas besoin par la suite je pense
 
allez juste le principe du delete[] alors

va falloir être plus précis.
 
si tu fais ton calloc et que ça marche, ça veut dire que ton compilo rajoute du code pour initialiser la vtable & appeller le constructeur. la seule chose que tu dois faire est alors allouer un bloc mémoire (donc ton malloc()).
 
ça marche pareil dans le sens inverse : le compilo appelle le destructeur, il te demande alors de détruire le bloc mémoire (free()).

mais je dois l'appeller a la main non le destructeur, avant le free
je vois pas comment deviner que le truc passe en parametre a delete est un objet et pas un flottant par exemple

Vaut mieux un dessin que 1000 lignes de blabla disait Napoléon.
 
Le principe vaut peut-être mieux que le code générique de delete[] ??
Habituellement, il y a une "logique" à la désallocation de la mémoire, un principe de "base", ..
Les opérateurs génériques doivent rendre service en généralisant leur service, mais en C, je suis obligé de savoir ce que je fais et à quoi j'applique les fonctions (chaîne, tableaux de structures multidimentionnels, ... ).
Le C++, ça me semble plutôt le "côté obscur de la force".
 
M'enfin, vais faire un peu de VB3 pour changer.

je viens de vérifier qq trucs avec vc++ :
 
* l'opérateur new surchargé avec les mfc ne fait que l'allocation (en entrée, une taille à allouer, en sortie, un pointeur vers une zone mémoire avec cette taille dispo)
 
* les constructeurs / destructeurs sont directement appelés dans le code. eg :
 
myClass* mc = new myClass;
 
est assemblé en :
* appel vers l'opérateur new, la taille étant déterminée à la compil ou en runtime (sizeof(myClass) * nombre d'éléments)
* appel du constructeur (qui met la vtable à jour). si plusieurs éléments, appel d'une routine qui fait la boucle d'appel des constructeurs.
 
DONC si gcc marche de la même façon (a priori pas de raison, tu peux toujours debugger pour être sûr) tu n'as qu'à te soucier de deux choses : allouer un bloc mémoire d'une taille donnée, le désallouer lorsqu'on te le repasse pour la destruction. c'est tout.
 
DONC (bis) je ne pige toujours pas ton problème !

youdontcare a écrit a écrit : je viens de vérifier qq trucs avec vc++ :   * l'opérateur new surchargé avec les mfc ne fait que l'allocation (en entrée, une taille à allouer, en sortie, un pointeur vers une zone mémoire avec cette taille dispo)   * les constructeurs / destructeurs sont directement appelés dans le code. eg :   myClass* mc = new myClass;   est assemblé en : * appel vers l'opérateur new, la taille étant déterminée à la compil ou en runtime (sizeof(myClass) * nombre d'éléments) * appel du constructeur (qui met la vtable à jour). si plusieurs éléments, appel d'une routine qui fait la boucle d'appel des constructeurs.   DONC si gcc marche de la même façon (a priori pas de raison, tu peux toujours debugger pour être sûr) tu n'as qu'à te soucier de deux choses : allouer un bloc mémoire d'une taille donnée, le désallouer lorsqu'on te le repasse pour la destruction. c'est tout.   DONC (bis) je ne pige toujours pas ton problème !

ben c'est bien ce que j'ai fais, sauf que je vois pas la difference entre delete et delete[], c'est tjs un free pour liberer la zone memoire nan
 
en tout cas merci bcp

BotMan a écrit a écrit : je vois pas la difference entre delete et delete[], c'est tjs un free pour liberer la zone memoire nan

vi.  
 
la différence c'est que certains types d'allocations stockent des données : pour allouer un bloc de 30 octets, ils allouent 40 et stockent leurs infos au début, puis passent un pointeur sur la mem allouée + 10 (donc 30 octets dispo, plus 10 de headers). apparemment c'est juste pour les opérateurs natifs, pas de distinction quand tu surcharges (toujours un delete() chez vc++).

toujours pour delete / delete [], tu peux apparemment choisir d'overloader les deux, et donc en faire deux cas particuliers (application dans mon message précédents : stockage d'infos, debug & co).
 
si tu ne surcharges que delete, cette surcharge sera utilisée pour delete et delete [].

Kwa ? new/delete sont des fonctions du langage, pas de l'OS...
 
new doit mémoriser le type de l'objet associé à une adresse.
new[] doit mémoriser en plus le nombre d'objets.
Y'a que comme ça que delete et delete[] peuvent faire leur boulot.
 
Mais si tu es sur un système limite en mémoire/puissance, il vaut peut-être mieux abandonner l'aspect polymorphique de 'allocation, et utiliser une version bridée de delete([]) à laquelle il faut spécifier le type/nombre exact d'objets à détruire.