Discussion :

[boli_971]

Salut,

Une question me trotte dans la tête depuis quelques temps, alors je viens vous demander votre avis.
Premièrement voici un exemple de code:

Code :

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

1
2
3
4
5
6
void *ptr = new int[10];
 
    std::cout << "taille en int* " << 10 * sizeof(int) << std::endl;
    std::cout << "taille en char* " << 10 * sizeof(char) << std::endl;
 
    delete[] static_cast<char*>(ptr);

Je me demande alors, est-ce que ce code provoque une fuite de mémoire ?
Sachant que dans mon cas un int est sur 4 octets, et un char est sur un octet.
Je pense que c'est le cas mais je n'en suis pas sûr et c'est bien pour cela que je vous demande votre avis .

Je sais void* c'est mal, mais c'est juste pour illuster le problème .

[koala01]

Salut,

*Normalement*, non... (à vérifier)

Ceci dit, comme tu l'as fait remarquer, void*, c'est mal... En C++, on préférera les template (la programmation générique)

Et puis, s'il y a bien un cas sur lequel je ne ferai jamais de transtypage, c'est bien le cas de delete / delete[]...

Typiquement, un transtypage, quel qu'il soit (et ici, ce serait plutôt un reinterpret_cast, sauf erreur ), ca a pour but de permettre de faire passer quelque chose pour quelque chose d'autre: un pointeur du type de la classe de base pour un pointeur du type de la classe dérivée réelle (static_cast et dynamic_cast), une variable constante pour une variable non constante (const_cast) ou n'importe quoi pour n'importe quoi d'autre (reinterpret_cast) car tu as besoin... de l'"autre chose"

[white_tentacle]

Je pense que c'est un comportement indéfini.

Suivant la manière d'allouer, ça va leaker, ou pas.

Si l'allocateur stocke la taille du tableau en nombre d'éléments, ça va merder. S'il la stocke en taille mémoire, ça va marcher.

Avec malloc/free, ce serait sûr que ça marche (ie, ne leake pas). Avec new/delete, il y a de grandes chances que ça marche, mais ça n'est pas garanti.

[koala01]

The library provides default definitions for the global allocation and deallocation functions. Some global allocation and deallocation functions are replaceable (18.4.1). A C + + program shall provide at most one definition of a replaceable allocation or deallocation function. Any such function definition replaces the default version provided in the library (17.4.3.4). The following allocation and deallocation functions (18.4) are implicitly declared in global scope in each translation unit of a program
void* operator new(std::size_t) throw(std::bad_alloc);
void* operator new[](std::size_t) throw(std::bad_alloc);
void operator delete(void*) throw();
void operator delete[](void*) throw();

Comme tu peux le voir, le parametre de delete / delete[] est... void*...

Tu as donc, de toutes manières, après appel du destructeur (qui n'existe pas en tant que tel sur les types primitifs) conversion en void* pour la libération de la mémoire...

Le comportement peut donc être indéfini si tu essaye avec des types non primitifs (appel du mauvait destructeur ou pas d'appel du tout), mais pas avec les types primitifs

[boli_971]

Merci beaucoup à vous, me voila maintenant rassuré sur ce point

[koala01]

Merci beaucoup à vous, me voila maintenant rassuré sur ce point

Attention, nous sommes bien d'accord sur le fait que, si tu utilise autre chose que des types primitifs, ca va partir en vrille, car le destructeur adéquat ne sera pas appelé...

C'est bien clair dans ta tête

[boli_971]

Ok je prend note, vu que j'avais l' intention d' appliquer cela uniquement sur des types primitifs ce n' est pas un problème. Merci

[loufoque]

Change

delete[] static_cast<char*>(ptr);

en

Code :

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

delete[] static_cast<int*>(ptr);

et plus de comportement indéfini.

Si tu ne traites qu'avec des PODs, tu ferais mieux d'utiliser directement operator new/operator delete, ce qui te permettra d'éviter le comportement indéfini.