Surcharge de new/delete mais limité a un namespace.

C'est une idée de feature du C++ qui m'est apparu plusieurs fois évidente (et visiblement je suis pas le seul) mais qui visiblement n'existe pas, donc je voudrais savoir si il y a un problème intrinsèque avec le principe que je ne verrais pas.

L'idée est simple : actuellement nous ne pouvons surcharger les fonctions new et delete qu'au niveau
- du namespace global
- d'une classe.

Cela est assez contraignant pour des tas de raisons déjà discutées.
Une manière peut être efficace de régler le probleme (mais qui est interdite aujourd'hui) serait de pouvoir surcharger ces fonctions mais au niveau du namepsace.

C'est à dire permettre d'avoir un monnamespace::new() qui ne soit appelé que pour tout ce qui est contenu dans ce namespace ( après inclusion de la déclaration du new/delete evidemment).

De cette manière, on peut potentiellment avoir une allocation customisée pour tout une bibliothèque par exemple, sans avoir a utiliser d'héritage de classe pour surcharger new/delete dans les classes de base.

Est-ce que ça vous parait choquant? Est-ce qu'il y a un probleme qui vous semble fondamental? Peut être que le nesting de namespace poserai des problèmes ou ça serait un détail d'implémentation? De loin ça n'a pas l'air bien compliqué à implémenter (ça ressemble a une surcharge "classique") mais peut être qu'il y a une implication que je ne vois pas?

Salut,

Cela ne me paraitrait pas forcément choquant, mais je verrais quand même deux problèmes majeurs :aie::

Au niveau de l'imbrication des espaces de noms, tu forcerais, effectivement, l'utilisation de la surcharge dans l'espace de noms imbriqué. Cela peut avoir du sens, ou non

Ensuite, il y a le problème de la directive using namespace : Tant qu'elle n'est pas utilisée, tu n'auras pas de problème particulier, mais, étant donné qu'elle peut être utilisée à peu près n'importe où, tu risques, dans le meilleur des cas, d'avoir un conflit entre les différentes versions et, dans le pire des cas, d'utiliser une version non adaptée.

C'est sans doute pour cela que la feature n'est pas permise par la norme, non :question:

Il ne faut pas non plus oublier que new et delete ne sont pas des fonctions "comme les autres": ce sont des opérateurs ;)

Et puis, pour être honnête, les opérateurs new et delete sont de parfait candidat à la création de politiques :D

En fait je pensais plutot que dans le cas ou on surcharge new/delete dans un namespace, il n'y a que les classes déclarées DANS le namespace qui l'utiliseraient par défaut comme new/delete global. Ca serait (encore une fois du coup) un cas spécial.


Hmmm... du coup effectivement c'est pas très clair quand on tente d'instancier une classe dans un namespace avec un allocateur maison ...

Il faudrait de toutes façons des règles spéciales.

Citation:

---

Envoyé par Klaim

En fait je pensais plutot que dans le cas ou on surcharge new/delete dans un namespace, il n'y a que les classes déclarées DANS le namespace qui l'utiliseraient par défaut comme new/delete global. Ca serait (encore une fois du coup) un cas spécial.

---

Oui, oui, je l'avais bien compris ainsi...

Mais je voulais surtout attirer l'attention sur le fait qu'il faut tenir compte des règles existantes lorsque l'on veut en ajouter une nouvelle.

On peut, éventuellement, adapter l'existant, mais il faut alors veiller à garder malgré tout la rétro compatibilité, et cela devient assez facilement un "casse tête chinois" :D

Effectivement, ça y est maintenant je ne vois plus cela comme quelque chose d'evident. :aie:

De loin, j'ai l'impression qu'on pourrait faire quelque chose d'assez orthogonal pour etre compatible avec l'existant si on a une feature du même genre au niveau des futures "modules".

Future trop lointain, sans doute.

bonjour,

personellement, c'est vrai que je ne l'ai pas fait dans un namespace,

par contre je le fait par classe ce qui par contre est simple.
ensuite, une technique très détournée qui n'est pas aussi pratique (mais qui par contre ne pause pas de problème de compatibilité) est de créer un object de base sur lequel new et delete sont redéfinit et d'en hériter de base.

ou alors se faire une macro genre USE_MY_NEW_DEL (un peu comme si tu faisait QOBECT dans qt) et de le mettre dans chaque classe ou tu veut redéfinir cette propriété.

bon ca ne le fait pas par namespace, mais en effet un namespace doit etre compatible avec ses namespaces parents et ce ne serait probablement plus vrai si on pouvais le faire par namespace.

Evidemment, je suis au courant de cette pratique (que j'évoque dans mon premier message) mais c'est justement parceque je ne pense pas du tout que ce soit si simple que je réfléchissais à une eventuelle extension aux namespaces.

Parceque l'héritage est trop lourd et devrait être orthogonal à l'implémentation de l'allocation des objets.

@Koala: Les problèmes que tu soulèves sont bien réel, mais ils sont déjà présent actuellement si tu définis une fonction dans un namespace alors qu'elle est définie dans l'espace global et que tu utilises un using

Code:

---

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

struct A {}; void foo(A&) {}   namespace N { //ou using ::foo; struct B : A {}; void foo(A&) {} }   //ou using namespace N;

---

Après, effectivement vue que son utilisation est un peu spécial, ca reviendrait à bannir tout using dès que new est définie dans le namespace. Peut-etre un peu trop contraingant.

Comment tu fais pour savoir s'il y a une surchage pour le namespace? Pour rappel ceux-ci sont ouverts.

Ça marche pour le namespace global parce que ce qu'on fait, c'est remplacer l'implémentation fournie par la SL.

Ha, j'aurai cru que les namespace detecé par le koenig lookup seraient prioritaire sur le namespace global, mais apparament pas. (et j'avais cru avoir testé, mas j'ai du faire une bourde)

Je pensais qu'il cherchais dans cet ordre : namespace courant (si il y a) -> namespace des arguments -> namespace global. (Je suppose un cas simple sans héritage et namespace imbriqué, mais apparament il cherche dans ces trois là en même temps.

Code:

---

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

struct A {}; void foo(A&) {} //1   namespace N { struct B : A {}; void foo(A&) {} //2 }   namespace P { void foo(A&) {} namespace M { void foo(A&) {} //3 void bar() {N::B b; foo(b);} } }

---

Ce code m'inquide une erreur entre les 3 déclarations indiquées. Alors que j'aurais cru que le namespace M devait être visité en premier.

Donc après tests, redéfinir des fonctions (que ce soit new ou autre) juste pour un namespace à l'air problématique.

Ou alors le namespace global est detecté comme faisant partie des namespaces des arguments ? (par remonté)

Le fait est qu'un espace de noms agit comme une boite "semi transparente":

Ce qui se trouve à l'intérieur d'un espace de noms est invisible "depuis l'extérieur" de celui-ci, mais, quand on est à l'intérieur d'un espace de noms, on a accès à tout ce qui est déclaré en dehors de celui-ci.

C'est, quelque part, la grosse différence qu'il peut y avoir entre un espace de noms et une structure ou une classe:

Dans une structure ou une classe, il y a le pointeur this, d'utilisation implicite, qui permet, effectivement de rechercher un fonction en priorité parmi les fonctions membres de la structure ou de la classe (qu'elles soient héritées ou non ;))

Mais il n'existe aucune référence à l'espace de noms "courent": on a juste la possibilité, quand on est à l'extérieur d'un espace de noms, d'indiquer qu'il faut aussi aller voir à l'intérieur de cette "caisse magique" qu'est l'espace de noms, grâce aux directives using ou using namespace ;)

Par courant j'entendais celui où est fait la définition qu'on est en train de faire et qui dépend de choses déjà déclaré.

Citation:

---

Ce qui se trouve à l'intérieur d'un espace de noms est invisible "depuis l'extérieur" de celui-ci, mais, quand on est à l'intérieur d'un espace de noms, on a accès à tout ce qui est déclaré en dehors de celui-ci.

---

Oui, ca n'empèche pas qu'il y puis y avoir une autre fonction avec le même nom, par exemple :

Code:

---

1 2 3 4 5 6 7 8

void foo() {} namespace N { void foo() {} void bar() {foo();} } }

---

Ne pose pas de problème. (sauf peut-etre dans certains cas mais ce n'est pas la question).

La seul différence entre ca et le code précédent c'est la présence de paramètre dont les types sont définie dans l'espace global, ce qui inclue celui-ci dans la première passe pour la recherche des noms et créé donc un conflit.

Et pour le code d'avant ca pose problème car à cause du paramètre A (ou de l'arguments b de type B un sous-type de A, je ne sais pas trop), l'espace global fait partie de la première passe au même titre que l'espace N (car b est de type N::B), d'où l'ambiguité.

Et la troisième ambiguité est plus simple : le namespace "courant" fait aussi partie de la première passe, j'aurais même cru qu'il serait avant ceux detecté par les arguments, par contre la recherche ne se fait pas dans le namespace P car celui ci fait partie de la seconde passe, qui n'a jamais lieu car la première suffit.

Pour les classes c'est presque le même principe

Code:

---

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

struct A {}; void foo(A&) {} //1   namespace N { struct B : A {}; void foo(A&) {} //2 };   struct P { static void foo(A&) {} //3 struct M { void bar() {N::B b; foo(b);} }; };

---

Change le struct P en namespace P et tu auras une ambiguité entre 1 2 et 3. Il effectue la recherche à travers les classes avant de passer au namespace, mais sinon c'est exactement le même principe (on commence de la plus proche et on remonte, classe mère avant les classes imbriquantes).

Je crois que vous ne m'avez pas compris ma remarque (ou alors ce n'est pas a elle que vous reaggissez)
- si la proposition soit d'utiliser un new/delete attache au namespace dans lequel se trouve la fonction qui fait le new/delete; il va falloir faire tres attention a faire le delete dans le namespace ou on fait le new et ne pas pouvoir deleguer.
- si la proposition soit d'utiliser un new/delete attache au namespace dans lequel se trouve la classe qui dont on fait un new/delete, il va falloir faire tres attention dans les cas d'heritage reparti entre different namespace
- que la proposition soit soit d'utiliser un new/delete attache au namespace dans lequel se trouve la fonction qui fait le new/delete ou a la classe qui dont on fait un new/delete, il faudrait faire tres attention a toujours avoir les deux visibles partout ou c'est necessaire.

Au final, ca me semble bien fragile pour l'utilite apportee. Faire chercher l'allocateur dans la hierarchie est bien plus sur. De mon point de vue -- influence par Ada -- l'allocateur devrait faire partie du type du pointeur avec un type de pointeur attache a aucun allocateur sur lequel on ne peut pas faire delete; mais ce modele n'est pas celui du C++.

Si j'ai bien compris, ce que proposais l'op était le deuxième point. (ou alors je n'ai pas compris non plus). Et j'avais bien compris votre message, j'avais cru un instant que les méchanismes de résolutions de nom du C++ règlais le problème, mais ce n'est pas le cas. (C'est le problème que vous soulevez en disant "il va falloir faire tres attention dans les cas d'heritage reparti entre different namespace" il me semble, ou alors en effet je n'ai pas compris).

Non, je pensais a

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class NS1::C1 { public: virtual ~C1(); };   class NS2::C2: public NS1::C1 { };   NS1::C1* x = new NS2::C2; delete x;

---

ou il faut une recherche dynamique pour trouver le delete de NS2 (bon, c'est ce qu'on a pour les new/delete par classe).

Mais surtout je pensais au fait qu'il est tres difficile de savoir si un namespace a un operator new/delete defini. Pour une classe, on sait qu'on a la definition de tous les ancetres. Pour un namespace, on n'est jamais sur d'avoir une vision complete. Si quelqu'un decide d'ajouter au projet un fichier contenant une definition de new/delete pour un namespace, est-ce qu'on s'attend a le voir utiliser (c'est le cas pour la definition dans le namespace global)?

Tout est resolvable, mais il faut voir a quel cout.

Pour le premier point comme vous le dites c'est déjà ce qui est fait pour les classes, donc je ne pense pas que ce soit un problème majeur.

Pour le second, j'aurais pensé que le compilateur ne prendrais en compte que ce qui est déjà définie au moment de l'appel, mais étant donné le dynamisme c'est peut-etre pas aussi évident.

Je vois un peu mieux ce que vous vouliez dire, merci :)

Citation:

---

Envoyé par Flob90

Pour le second, j'aurais pensé que le compilateur ne prendrais en compte que ce qui est déjà définie au moment de l'appel, mais étant donné le dynamisme c'est peut-etre pas aussi évident.

---

Le fait est que le compilateur travaille, essentiellement, avec ce qui est déclaré au moment de l'appel, sans s'inquiéter outre mesure de l'endroit où ce sera défini / implémenté. (C'est l'éditeur de liens qui s'occupe de mettre l'appel des fonctions avec leur implémentation ;))

Les exemples qui permettent de s'en rendre compte sont légions: il suffit de voir le contenu de n'importe quel fichier d'en-tête ;)

Et, comme tu es confronté au jeu des inclusions en cascades, il devient particulièrement délicat de garder le contrôle sur ce qui sera ou non déclaré lors d'un appel donné :P

J'imagine que le problème ne change pas si on définit un objet global dans le namespace qui servirait d'allocateur par défaut?

Ben, tu peux, bien évidemment, définir tes propres allocateurs dans tes espaces de noms, et décider de les utiliser (ou non).

Mais cela rentre beaucoup plus dans une optique de mise en place de traits et de politique, même s'il y a moyen d'arriver à des trucs sympa, grâce à quelques instructions préprocesseur ;)

Après tout, la STL présente déjà une série d'allocateur (cf toute la section 20.9 (dédiée au fichier <memory> du draft de la prochaine norme ;))