faire une macro new

bonjour,

Dans le cadre de la réalisation d'un gestionnaire de mémoire, j'ai besoin de créer une macro qui se comporte de la même manière qu'un new, mais sans l'utiliser.
Je n'ai pas le droit d'utiliser le new, car faisant du middleware, il faut laisser au cilient la possibilité de faire sa propre surcharge de new qui potentiellement pourrait utiliser un autre allocateur que celui que j'utilise en interne.

Donc je voudrais un truc du genre
MyClass* ptr = MY_NEW MyClass(param1, param2);
dans l'idéal
ou peut être de manière plus réaliste
MyClass* ptr = MY_NEW(MyClass, param1, param2);


Est-ce possible?

Est-ce que:
MyClass* ptr = (MyClass*)malloc(sizeof(MyClass));
ptr->MyClass(param1, param2);
et
MyClass* ptr = new MyClass(param1, param2);
sont équivalents?


Merci d'avance pour vos réponses ;)

Bonsoir,

Citation:

---

Est-ce que:
MyClass* ptr = (MyClass*)malloc(sizeof(MyClass));
ptr->MyClass(param1, param2);
et
MyClass* ptr = new MyClass(param1, param2);
sont équivalents?

---

Oui sauf que on ne doit pas faire un delete sur une mémoire allouée par malloc, et inversement, il ne faut donc pas confondre malloc et new.

Pour faire ce que tu veut, on utilise habituellement le placement new:

Code:

---

MyClass* ptr = new(MonAllocateur(sizeof(MyClass))) MyClass(param1, param2);

---

Citation:

---

Donc je voudrais un truc du genre
MyClass* ptr = MY_NEW MyClass(param1, param2);
dans l'idéal
ou peut être de manière plus réaliste
MyClass* ptr = MY_NEW(MyClass, param1, param2);

---

On peut faire quelque chose comme ca:

Code:

---

1 2 3 4

#define MY_NEW(T) new(MonAllocateur(sizeof(T))) T   MyClass* ptr = MY_NEW(MyClass)(param1, param2);

---

Cela dit cette méthode n'est pas recommandée, d'une part car elle utilise des macro, mais aussi parque tu risque de faire un delete normal sur un objet alloué avec autre chose qu'un new.

La meilleur solution a mon avis, est de surcharger les new et delete spécifique de tes classe concernée.

Citation:

---

Envoyé par Nogane

On peut faire quelque chose comme ca:

Code:

---

1 2 3 4

#define MY_NEW(T) new(MonAllocateur(sizeof(T))) T   MyClass* ptr = MY_NEW(MyClass)(param1, param2);

---

Cela dit cette méthode n'est pas recommandée, d'une part car elle utilise des macro, mais aussi parque tu risque de faire un delete normal sur un objet alloué avec autre chose qu'un new.

---

Merci pour cette solution je n'y avais pas pensé :ccool:
Je pense utiliser quelque chose comme ça:

Code:

---

1 2 3 4 5 6 7 8

#define MY_NEW(T) new(MyAlloc(sizeof(T), __FILE__, __LINE__)) T   template<class T> void MY_DELETE(T* p) { p->~T(); MyFree(p); }

---

Qu'est ce que cela implique exactement d'utiliser ce code en termes de
-performances
-sécurité
-temps de compilation
-taille du programme
?

Citation:

---

Envoyé par Nogane

La meilleur solution a mon avis, est de surcharger les new et delete spécifique de tes classe concernée.

---

J'avais pensé utiliser cette solution en créant une classe MyObject dont dériverait chacune de mes autres classe, et qui surchargerait l'opérateur new et delete pour passer par mon manager, mais c'est un peu lourd comme solution. Cela impliquerait beaucoup trop de changements.

En tout cas merci pour ta réponse

As tu pensé à une surcharge globale de new/new[] et delete/delete[] ?

Ca évite de bidouillage/hack sur new avec des macro qui est un code smell et surtout une très grosse source de bugs.

Citation:

---

Envoyé par Davidbrcz

As tu pensé à une surcharge globale de new/new[] et delete/delete[] ?

Ca évite de bidouillage/hack sur new avec des macro qui est un code smell et surtout une très grosse source de bugs.

---

Je crois qu'il veut pas le faire car il veut pas "obliger" l'utilisateur final à passer par sa surcharge. Qui a mon avis n'est pas un réel problème, il suffit de mettre la surcharge dans son propre espace de noms.

Code:

---

1 2	#define MY_NEW(T) new(MyAlloc(sizeof(T), __FILE__, __LINE__)) T template<class T> void MY_DELETE(T* p)

---

Citation:

---

Qu'est ce que cela implique exactement d'utiliser ce code en termes de:

---

-performances
Pour les performance ca dépend surtout de ton allocateur.

-sécurité
C'est le principale problème: Une macro c'est obscure pour le programmeur, et le compilateur n'as aucun moyen de tester ca validité d'un point de vue C++. C'est le préprocesseur qui gère, et il est "bête et méchant". En plus tu risque fort d'avoir des problème si tu alloue avec une méthode et désalloue avec une autre. Et ne dit pas "Il suffit d'y penser", quand on dit ca c'est qu'on est déjà entrain de ce tirer une balle dans le pied.

-temps de compilation
Effet probablement dérisoire.

-taille du programme
Effet dérisoire aussi.


Je me demande si tu fait ca juste pour détecter les fuite mémoire, corriger des fuites, ou pour réellement modifier ton allocateur?
- Dans le première cas, un simple conteur d'instance devrai pourvoir te rassurer, et tu n'aurais même pas a le mètre dans le produit final.
- Dans le deuxième cas, dit toi qu'il suffit généralement d'appliquer proprement le RAII (par exemple: vector,scoped_ptr,shared_ptr) pour que les fuite mémoires disparaissent d'elle même. Si elles restent après ca, il sera toujours temps d'en reparler.
- Dans le troisième cas, ce n'est que rarement utile, mais bon, la meilleur solution reste de surcharger tes new/delete. Ca peut ce faire très proprement, en héritant d'une class qui fait tout pour toi. Tu n'as plus qu'a spécifier ton allocateur.
Je doit avoir ca dans un coin donc n'hésite pas a me demander le code. pareil pour le conteur d'instance.

tu pourrais faire un override global de new/delete et proposer un moyen de changer les allocateurs en demandant un set de fonctions malloc/free

Es-tu au courant que tu peux définir des versions spécifiques à la classe des opérateurs new et delete?

Citation:

---

Envoyé par JulienDuSud

Je crois qu'il veut pas le faire car il veut pas "obliger" l'utilisateur final à passer par sa surcharge. Qui a mon avis n'est pas un réel problème, il suffit de mettre la surcharge dans son propre espace de noms.

---

C'est exactement cela.
par contre on ne peut pas faire de surcharge de new/delete dans un espace de noms. Le compilateur me renvoit l'erreur:
allocation/deallocation functions shall be global scope or class members

Citation:

---

Envoyé par Nogane

En plus tu risque fort d'avoir des problème si tu alloue avec une méthode et désalloue avec une autre. Et ne dit pas "Il suffit d'y penser", quand on dit ca c'est qu'on est déjà entrain de ce tirer une balle dans le pied.

---

Je ne pense pas que ce soit un problème, à partir du moment où l'on impose de passer par une macro, après il suffit de faire des recherches sur delete/new et ça se détecte très rapidement. Mais je suis d'accord que s'il y avait une solution transparente ça serait beaucoup mieux.

Citation:

---

Envoyé par Nogane

Je me demande si tu fait ca juste pour détecter les fuite mémoire, corriger des fuites, ou pour réellement modifier ton allocateur?

---

En fait le but est
1) de pouvoir tracer la mémoire (connaitre la mémoire allouée à tout moment, les leaks, affichiers noms de fichiers et numéros de lignes des appels de new/delete, afficher la call-stack...)
2)avoir un allocateur interne différent de l'allocateur client.

Citation:

---

Envoyé par Nogane

- Dans le deuxième cas, dit toi qu'il suffit généralement d'appliquer proprement le RAII (par exemple: vector,scoped_ptr,shared_ptr) pour que les fuite mémoires disparaissent d'elle même. Si elles restent après ca, il sera toujours temps d'en reparler.

---

Certes mais cela ne répond pas vraiment à mes besoins. Mais je suis d'accord que cela permet d'éviter des fuites mémoires.

Citation:

---

Envoyé par Nogane

- Dans le troisième cas, ce n'est que rarement utile, mais bon, la meilleur solution reste de surcharger tes new/delete. Ca peut ce faire très proprement, en héritant d'une class qui fait tout pour toi. Tu n'as plus qu'a spécifier ton allocateur.
Je doit avoir ca dans un coin donc n'hésite pas a me demander le code. pareil pour le conteur d'instance.

---

Citation:

---

Envoyé par Jean-Marc.Bourguet

Es-tu au courant que tu peux définir des versions spécifiques à la classe des opérateurs new et delete?

---

oui je suis au courant, mais je n'ai pas envie d'utiliser cette solution qui est trop lourde. Il y aurait beaucoup trop de code à traiter et je crois pas que rajouter de l'héritage partout soit très bon pour les perfs.

Citation:

---

Envoyé par screetch

tu pourrais faire un override global de new/delete et proposer un moyen de changer les allocateurs en demandant un set de fonctions malloc/free

---

Je n'ai malheureusement pas le droit de faire un override global de new/delete pour des raisons évoquées plus haut.