Opérateur new pour une classe personalisée.

Bonjour.

je vient de lire que l'opérateur new devait-être redéfini si on voulait l'utiliser pour une classe personalisée.
Cependant, je ne vois pas quelle adresse memoire il faudrais renvoyer pour pointer sur l'objet ainsi créé...

et puis pour créer un tableau .... je me pert dans la forme des opérateurs....:aie:


merci

Citation:

---

je vient de lire que l'opérateur new devait-être redéfini si on voulait l'utiliser pour une classe personalisée

---

Mais encore (quelle est ta source) ? Parce que là tel que tu le dis c'est très faux. La redéfinition de l'opérateur new, c'est seulement si on a des trucs louches à faire avec les allocations, ce n'est en rien une nécessité.

Citation:

---

Cependant, je ne vois pas quelle adresse memoire il faudrais renvoyer pour pointer sur l'objet ainsi créé...

---

L'adresse renvoyée par la fonction d'allocation que tu auras utilisée dans ton opérateur new (malloc, HeapAlloc, ...) -- et non, ce n'est pas toi qui alloue la mémoire à la main :aie:

Citation:

---

et puis pour créer un tableau .... je me pert dans la forme des opérateurs....

---

Il suffit de surcharger l'opérateur new[], après c'est la même chose.

Toutes les réponses que j'ai vu concernant ce sujet sont vagues.
C'est toujours quand on a des "allocations particulières" à faire ou dans des "cas particulier" mais je n'ai jamais eu la vision d'un cas concret. Quoiqu'il en soit, faut quand même avoir du cran pour gérer la gestion de la mémoire à la main alors que dans 99% des cas tout se fera très bien avec l'opérateur par défaut ^^

A part si l'on surcharge les opérateurs new pour détecter les fuites mémoires...
La ca fait partie des 1%!

Ca peut servir si le code est susceptible d'effectuer énormement d'allocation de classe très petite.

Du genre, tu veux pouvoir stocker un tableau de 20000 d'objets polymorphiques.

Tu vas pouvoir te retrouver à faire un truc du genre :

Code:

---

1 2 3 4 5 6 7 8 9

vect.resize(50000);   for(unsigned int i = 0; i<vect.size(); i++) Machin * m = machin.clone(); m->setValue(i); vect[i] = m; }

---

Et bien, la vitesse risque d'en prendre un coup. Tu peux redéfinir l'opérateur new pour faire un malloc ou un HeapMalloc tous les 500 blocs par exemples.


Il y a un autre cas intéressant, c'est si tu te retrouves à devoir instancier une classe plein de fois de suite.

Par exemple, (ça va paraitre artificiel) :

Code:

---

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

for(int j = 0; j< matrice.getHeigh(); j++) for(int i = 0; i< matrice.getWidth(); i++) { compute(matriceout, i,j); };   ..... void compute(Matrice & matriceout, int i, int j) { Buffer de grosse taille pour faire le calcul qui utilise new   ... calcul }

---

Pour une matrice par exemple de taille 1000*1000, tu vas te retrouver à faire tout un tas de new, ce qui peut porter préjudice à la vitesse d'exécution du programme. Si le buffer utilise quelque chose qui permet d'être optimisé au niveau de l'appel à new, alors il est possible de gagner en vitesse.

Maintenant, ça dépend également des implémentations normales de new. Je sais comment est implémenté malloc (du moins des implémentations simples), mais pas new, donc, je ne peux pas en dire plus.

Citation:

---

Envoyé par Laurent Gomila

Mais encore (quelle est ta source) ? Parce que là tel que tu le dis c'est très faux. La redéfinition de l'opérateur new, c'est seulement si on a des trucs louches à faire avec les allocations, ce n'est en rien une nécessité.

---

ha ben ça me rassur alors (j'avais pas envie de le faire). remarque: je redéfinissait déjà l'opérateur "=" à chaque fois alors que c'est utile que s'il y as des allocations dynamiques à faire.

Citation:

---

Envoyé par Laurent Gomila

L'adresse renvoyée par la fonction d'allocation que tu auras utilisée dans ton opérateur new (malloc, HeapAlloc, ...) -- et non, ce n'est pas toi qui alloue la mémoire à la main :aie:

---

Non, je me demandais juste, s'il fallait faire pleins de new dans la redéfinition du new, quelle adresse mémoire renvoyer (puisque new renvoie un pointeur).


millie-> hu ? 8O heu... pas compris désolé, je crois que j'ai pas le niveau :aie:

merci à tous

en fait, tu peux meme passer des parametre supplementaires a ton new ....

ex (syntaxe a verifier)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

class machin {   public:   void * operator new (size_t t){   return malloc(t); }   void * operator new (size_t t,void * buffer){   return buffer; }   void * operator new [] (size_t t){   ... }   void operator delete (void * p){   free(p); }   void operator delete [] (void * p){   free(p); } };

---

apres, tu peux faire:


A * a = new A();

delete(a);


A * a = new A[10];

delete [] (a);


char buffer[sizeof(A)];

A * a = new (buffer) (A); /* ce que l on appel allocation 'inplace' ... */

a.~A(); /* tu fournis toi meme le buffer ... */
/* ca lance alors les constructeurs necessaires. */
/* il faut finir alors par une destruction explicite */
/* de l objet. */
/* ca permet d eviter une couteuse allocation */
/* memoire. */


note :

-si tu redefinis l'allocateur inplace, il te faut definir l'allocateur normal et de tableau sous peine de ne plus y avoir acces

--> c'est la meme chose que quand tu definis un constructeur avec parametres... tu perds le constructeurs par defaut que le compilateur t avais gracieusement offert

Citation:

---

Non, je me demandais juste, s'il fallait faire pleins de new dans la redéfinition du new, quelle adresse mémoire renvoyer (puisque new renvoie un pointeur).

---

Pourquoi plein ? Une seule suffit.

Citation:

---

ex (syntaxe a verifier)

---

Les surcharges de new et delete à l'intérieur d'une classe doivent être des fonctions membres statiques.

Citation:

---

Envoyé par Laurent Gomila

Les surcharges de new et delete à l'intérieur d'une classe doivent être des fonctions membres statiques.

---

il me semblait que non justement (et presque bizarement) .... car sinon l allocation devrait ce faire comme suit :

Code:

---

1 2 3 4

class A {};   A * a = A::new A();

---

note que je n ai pas de compilo C++ a portee de main pour verifier

Citation:

---

Envoyé par smashy

il me semblait que non justement (et presque bizarement) .... car sinon l allocation devrait ce faire comme suit :

Code:

---

1 2 3 4

class A {};   A * a = A::new A();

---

---

Ah... Et en fonction membre non statique, l'appel "a = new A()" te paraîtrait plus logique ?

Bon après vérification, ces surcharges sont bien statiques mais elles le sont implicitement, c'est-à-dire qu'on n'est pas obligé de spécifier le mot-clé static.

Donc quelque part, tout le monde avait raison ;)

effectivement, il bien evident qu'une telle fonction est, en interne au moins, statique : dans le sens, ou aucun pointer this n existe dans le corps de cette fonction (ce n est pas ce que je voulais dire par non-statique)

Et de memoire, effictivement le mot cle static n'avait pas besoin (ne devait pas ?) etre mentionne :D

Citation:

---

Envoyé par Laurent Gomila

Pourquoi plein ? Une seule suffit.

---

si je dois créer plusieurs variables qui appartiennent à ma classe: je dois faire plusieurs new non ?

'Alut.

Voici un exemple:

Code:

---

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

class A { //constructeur A();   //Données int m_Nombre, m_Nombre2; float m_Float; UneAutreClasse m_AutreClasse; };   //constructeur A::A() : m_Nombre(0), m_Float(0) { m_Nombre2 = 0; m_AutreClasse = new UneAutreClasse(); }

---

Tu as ici 2 méthodes pour initialiser tes données.
_ la méthode classique (comme dans une autre fonction (pour m_Nombre2 et AutreClasse)
_ l'autre méthode (je ne me souviens plus de son nom, mais elle est très pratique (pour m_Nombre et m_Float));

Je ne retourne rien , cela est fait de manière implicite.

Citation:

---

_ l'autre méthode (je ne me souviens plus de son nom, mais elle est très pratique (pour m_Nombre et m_Float));

---

C'est la liste d'initialisation.

Citation:

---

Envoyé par Albenejean

Code:

---

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

class A { //constructeur A();   //Données int m_Nombre, m_Nombre2; float m_Float; UneAutreClasse m_AutreClasse; };   //constructeur A::A() : m_Nombre(0), m_Float(0) { m_Nombre2 = 0; m_AutreClasse = new UneAutreClasse(); }

---

---

Oui, je connais cette methode, mais là il y as une erreur: m_AutreClasse est un objet de type UneAutreClasse alors que new UneAutreClasse() renvoie une référence.

De toutes façons, ma question ne portais pas là dessus, mais sur la surcharge de l'opérateur new à l'interieur d'une classe.

j'ai néamoins compris où est-ce que je bloquais.

merci.