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

C++ Discussion :

Hiérarchie de namespaces


Sujet :

C++

  1. #1
    Membre confirmé
    Profil pro
    Inscrit en
    Octobre 2006
    Messages
    63
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Octobre 2006
    Messages : 63
    Par défaut Hiérarchie de namespaces
    Bonjour à tous,
    Comment organiser son projet dans une hiérarchie cohérente d'espace de nommage succeptible d'etre souvent revue ?

    La forme générale pourrait ressemblerait par exemple à ceci:

    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
     
    root{
     a{
      classe1
      classe2
     }
     b{
      classe3
     }
     c{
      d{
        classe4
      }
     }
    }

    Actuellement je me suis dis que je pourrais faire ceci (mais j'ai l'impression que ce n'est pas possible) :

    classe1.h:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
     class classe1{
      ...
     }
     
     namespace a{
      class classe1;
     }
    idem pour les autre headers, ex classe4.h
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
     class classe4{
      ...
     }
     
     namespace d{
      class classe4;
     }

    ensuite j'imagine un fichier .h quelconque reprenant la hiérarchie des namespace que j'espere pouvoir "modeler" comme je veux, par exemple:

    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
     
    namespace root{
     namespace a{};
     namespace b{};
     namespace c{
      namespace d{};
     };
    }
     
    // et pour finir faire des alias sur les namespaces pour qu'ils soient moins
    //rébarbatifs qu'en interne (le but et de rester le plus libre face au noms et a
    //l'organisation des namespaces)
     
    //genre :
    namespace racine = root;
    namespace employes = a;
    namespace batiments = b;
    namespace utilitaires = c;
    namespace base = d;
    est ce que dans ce cas une ligne du type :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    racine::utilitaires::base::classe4 varc4;
    serait valide ?

    Merci de bien vouloir m'éclairer un peu parce que ceci est un peu obscur pour moi ;-)

  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,

    L'idée des espaces de noms, c'est de regrouper "dans un même sac" les différents types et fonctions "qui vont bien ensemble" (comprend ici qui poursuivent un même but).

    Il se fait que j'ai justement fait une intervention sur les thème des espaces de noms, qui, bien que le but premier était d'expliquer la raison qui devait inciter les gens à l'utiliser, me semble tout à fait adaptée pour répondre à ta question.

    Comme cette intervention est assez longue, tu m'excusera de ne te donner que le lien elle se trouve ==>ici<==
    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 confirmé
    Profil pro
    Inscrit en
    Octobre 2006
    Messages
    63
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Octobre 2006
    Messages : 63
    Par défaut
    Salut,
    tout d'abord merci pour ta réponse.
    En fait je savais qu'un namespace agissait comme un "sac" ou sont rangées ensembles les classes qui doivent l'etre.

    Avec cet exemple ce que j'aurais aimé faire c'est de changer les imbrications des namespaces entre eux le plus facilement (grace à un seul fichier, celui qui décrit la hierarchie ; par exemple).

    J'ai fais quelques test mais ça n'a pas donné grand chose mais peut etre m'y suis-je mal pris aussi.

    Actuellement (et corrige-moi si ce n'est pas la bonne façon de procéder) je m'amuse pour chaque classe a la définir dans une imbrication précise de namespaces. Et que donc à prioris, si il faut faire une modification de la hierarchie il faudra la faire pour toutes les classes associées, donc tout les .h

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    namespace niveau1{
     namespace niveau2{
      class maclasse{
       ...
      }
     }
    }
    Voila c'est lourd de ramener ma classe dans un niveau3 par exemple (surtout si il faut le refaire pour d'autres dizaines de classes)

    Mais c'est la configuration que j'ai actuellement, donc déja dans un premier temps faut-il forcément réimbriquer "maclasse" dans ses 2 ou 3 niveaux dans son fichier .h ou il y a plus simple ?

    Ensuite pour en revenir a ma question principal existe-t-il une façon de faire pour changer la hierarchie des namespace "à la volée" on va dire (donc, genre une modif dans un fichier) ?

  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
    Ce qu'il faut bien que tu comprenne, c'est que l'ordre logique de travail, c'est de commencer par analyser "aussi aussi loin que possible", à l'aide d'un simple papier et d'un crayon, ce dont ton application a besoin.

    Tout le monde te dira que, de toutes façons, les besoins de l'application
    • ne sont jamais complets
    • changent tout le temps
    • nous sont souvent cachés par le simple fait que l'utilisateur final "pense que, mais bon sang, sa va de soi"

    Mais il n'empêche que, si tu ne pars pas avec une analyse minimale, ton projet va droit dans le mur.

    L'analyse consiste, principalement, à répondre à quatre questions:
    1. Quel est le but de mon application (ou de ma bibliothèque)
    2. De quelles informations mon application (ou ma bibliothèque) a-t-elle besoin
    3. Où (et comment) mon application (ou ma bibliothèque) va-t-elle obtenir ces information
    4. Quel(s) traitement(s) mon application va-t-elle faire subir à ces informations
    Autant le dire tout de suite, tant que tu n'a pas une réponse "aussi claire et précise que possible" à l'une de ces questions, il n'est même pas nécessiare de vouloir passer à la question suivante.

    Et il ne sert pour ainsi dire qu'à perdre du temps d'essayer de commencer l'écriture de ton code, tant que tu n'a pas au minimum une réponse acceptable à ces quatre questions.

    Ces questions vont, presque "naturellement", t'amener à envisager, entre autres, une série de structures de données, couplées à une série de "messages" que ces structures peuvent envoyer ou auxquels ces structures vont devoir réagir.

    En gros, tu va finir par obtenir ce que l'on appelle en UML un diagramme de classes (et sans doute une série d'autres diagrammes, qui s'inscriront dans ta méthode d'analyse préférée ).

    Et tu remarquera que tes différentes classes présentent une série de relations entre elles:
    • Certaines classes contiennent un certain nombre d'autres classes
    • Certaines héritent d'une (ou de plusieurs) autre(s) classe(s)
    • Certaines utiliisent une (ou plusieurs) autre(s) classe(s) pour parvenir à leur but
    • Certaines poursuivent un "même but générique" (par exemple: envoyer des informations sur le réseau)
    C'est à partir de ces constatations que tu va décider de regrouper ces différentes classes entre elles en espaces de noms.

    Il faut bien comprendre que les décisions importantes (comme par exemple la hiérarchie des espaces de noms) sont donc prises bien avant d'écrire la première ligne de code.

    Si ton analyse a correctement été menée, et malgré le fait que certains aspects puisent apparaitre en cours de développement (nécessitant de reprendre une partie de l'analyse), il est fort vraisemblable que les adaptations ne nécessitent pas de révision en profondeur de la hiérarchie d'espaces de noms.

    Ce qui risque fort de se passer, c'est que tu remarque avoir oublié quelque chose lorsque tu commence à écrire ton code, ou que tu te rende compte n'avoir absolument pas pris un besoin en compte.

    Il est fort vraisemblable que tu décide de rajouter, de retirer ou de modifier des classes, ou encore de modifier certaines relations existant entre deux (ou plusieurs) classes, mais l'organisation générale des espaces de noms sera sans doute ce qui sera le plus stable dans le temps...

    Et la raison en est simple: tu prend la décision de "saucissonner" ton projet en espaces de noms (en "paquetages")... sur base de l'ensemble des relations qui régissent les classes que tu as déterminées.

    S'il se peut (et, si l'analyse est correcte, le risque est très faible) que tu sois tenté de modifier la hiérarchie des espaces de noms, ce seront le plus souvent des modifications qui n'impliquent qu'un nombre restreint de classes
    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 poukill
    Profil pro
    Inscrit en
    Février 2006
    Messages
    2 155
    Détails du profil
    Informations personnelles :
    Âge : 41
    Localisation : France

    Informations forums :
    Inscription : Février 2006
    Messages : 2 155
    Par défaut
    Je met un gros +1 sur ton post !

  6. #6
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Par défaut
    Je ne vois pas trop de moyen simple et propre de faire ce genre de choses. Je verrais deux directions :
    - Tu mets chaque classe sans aucun namespace dans son fichier, et tu as un gros fichier, qui est le seul à être compilé, et qui inclue tous les autres (tu perds donc la compilation séparée...).
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    namespace a {
      namespace b {
        #include "class1.h"
      }
      namespace c {
        #include "class2.h"
      }
      namespace b {
        #include "class1.cpp"
      }
    }
    - Tu défini dans un fichier unique des macros qui représentent les namespaces
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    #define CLASS1_NAMESPACE_START namespace a{namespace b {
    #define CLASS1_NAMESPACE_STOP } }
     
    CLASS1_NAMESPACE_START
    class1 {...};
    CLASS1_NAMESPACE_STOP
    Dans les deux cas, le code client n'est pas franchement protégé des changements.

    Mais bon, à la base, j'ai envie de dire que les namespaces sont souvent une choses assez stable, qui ne demande pas à être changés trop souvent. J'ai tendance à avoir un namespace et un seul par bibliothèque (voire des namespace partagés entre plusieurs bibliothèque de même niveau), une granularité plus fine ayant peu d'intérêt en général je pense. Donc si je veux changer ça, c'est que je change l'organisation de mes bibliothèques, et donc je suis déjà dans une phase de modification lourde, ce n'est donc pas les namespaces qui vont poser problème.
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  7. #7
    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
    Pour pallier ce problème, il est toujours possible de faire confiance à la puissance de ton EDI (ou de quelques instructions bien senties sous linux), qui peut le plus souvent effectuer des remplacements dans plusieurs fichiers, voir dans tous les fichiers d'un projet.

    Ainsi, tu devrais pouvoir faire remplacer toute une imbrication d'espace de noms dans l'ensemble des fichiers, seule serait éventuellement à ta charge de les enregistrer

    Cependant, cela peut nécessiter une hygiène de codage relativement stricte, entre autres, au niveau des indentations.

    Pour la clôture des espaces de noms (l'accolade fermante correspondante), tu peux faciliter le travail de ton EDI avec une habitude toute simple: placer en argument le nom de l'espace de noms auquel elle correspond.

    Ainsi, j'ai pris l'habitude d'écrire mes codes sous la forme de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    namespace Truc
    {
    namespace Brol
    {
    /*...*/
    }//namespace Brol
    }//namespace Truc
    Si, pour une raison ou une autre, je venais, pour avoir repris ma conception à zéro, à décider de changer l'imbrication des espaces de noms, il me "suffirait" de lancer deux recherches/modifications dans mon edi.

    La première porterait sur
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    namespace Truc
    {
    namespace Brol
    {
    la deuxième porterait sur
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    }//namespace Brol
    }//namespace Truc
    les deux étant à appliquer sur l'ensemble des fichiers du projet
    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

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. expression XPath et namespace
    Par gendalf37 dans le forum XSL/XSLT/XPATH
    Réponses: 4
    Dernier message: 26/10/2004, 13h26
  2. parser un XHTML bien formé (problème namespace)
    Par luta dans le forum XML/XSL et SOAP
    Réponses: 2
    Dernier message: 18/10/2004, 12h55
  3. hiérarchie et asso réflexive
    Par Mathusalem dans le forum Langage SQL
    Réponses: 2
    Dernier message: 10/06/2004, 15h13
  4. [Debutant][Divers] - namespace et attributs
    Par sebbb dans le forum XML/XSL et SOAP
    Réponses: 2
    Dernier message: 10/06/2003, 14h40
  5. Erreur récurrente (namespace)
    Par [DreaMs] dans le forum XMLRAD
    Réponses: 3
    Dernier message: 25/02/2003, 10h27

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