IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage C++ Discussion :

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


Sujet :

Langage C++

  1. #1
    Membre Expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Par défaut 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?

  2. #2
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 644
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 644
    Par défaut
    Salut,

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

    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

    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  3. #3
    Membre Expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Par défaut
    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.

  4. #4
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 644
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 644
    Par défaut
    Citation Envoyé par Klaim Voir le message
    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"
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  5. #5
    Membre Expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Par défaut
    Effectivement, ça y est maintenant je ne vois plus cela comme quelque chose d'evident.

    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.

  6. #6
    Membre averti
    Inscrit en
    Mars 2007
    Messages
    34
    Détails du profil
    Informations forums :
    Inscription : Mars 2007
    Messages : 34
    Par défaut
    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.

  7. #7
    Membre Expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Par défaut
    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.

  8. #8
    Membre Expert

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2004
    Messages
    1 391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 391
    Par défaut
    @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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

  9. #9
    Expert confirmé

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Par défaut
    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.

  10. #10
    Membre Expert

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2004
    Messages
    1 391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 391
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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é)

  11. #11
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 644
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 644
    Par défaut
    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
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  12. #12
    Membre Expert

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2004
    Messages
    1 391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 391
    Par défaut
    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é.

    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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).

  13. #13
    Expert confirmé

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Par défaut
    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++.

  14. #14
    Membre Expert

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2004
    Messages
    1 391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 391
    Par défaut
    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).

  15. #15
    Expert confirmé

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Par défaut
    Non, je pensais a

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

  16. #16
    Membre Expert

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Août 2004
    Messages
    1 391
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Doubs (Franche Comté)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 391
    Par défaut
    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

  17. #17
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 644
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 644
    Par défaut
    Citation Envoyé par Flob90 Voir le message
    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é
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  18. #18
    Membre Expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Par défaut
    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?

  19. #19
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 644
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 644
    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 )
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

Discussions similaires

  1. Surcharge de new / delete et Memory Manager
    Par LittleWhite dans le forum C++
    Réponses: 11
    Dernier message: 18/10/2010, 23h56
  2. new et delete, mais où?
    Par juloss dans le forum C++
    Réponses: 18
    Dernier message: 02/09/2008, 11h25
  3. intrigue sur la surcharge du new et delete
    Par swirtel dans le forum C++
    Réponses: 12
    Dernier message: 07/09/2006, 15h23
  4. [Débutant]Constructeur et new/delete
    Par Geolem dans le forum C++
    Réponses: 5
    Dernier message: 02/12/2005, 21h11
  5. Namespace et surcharge operator new/delete
    Par ZeLegolas dans le forum C++
    Réponses: 11
    Dernier message: 26/07/2005, 13h55

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo