mot-clé 'internal' en c++

Bonjour tout le monde,

en C#, il existe un mot-clé internal. Lorsqu'une fonction membre est déclarée comme internal, elle n'est accessible que dans l'espace de nommage dans laquelle elle est déclarée.

Par exemple (ce pseudo-code est un mix de c++ et de C#):

Code:

---

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

namespace NM1 { class Class1 { internal Class1(); // le constructeur est déclaré comme interne }; }   namespace NM2 { void une_fonction() { Class1 c1; // ne compile pas NM1::Class1 c2; // ne compile pas non plus } }

---

Dans le code ci-dessus, il est absolument impossible d'appeler directement le constructeur de Class1 dans n'importe quel espace de nommage qui n'est pas NM1.

En ce moment je développe beaucoup en c#, et j'aime beaucoup cette fonctionnalité, et je m'y suis habitué. Du coup je cherche une façon pour faire la même chose en C++. Mais je n'ai pas le début d'une idée. Quelqu'un en a une?

Bonjour,

Aprés une petite recherche sur le site, j'ai trouvé un topic qui traite de ton sujet!

va la tu auras ta réponse.

:ccool:

Oui j'avais vu ce topic, mais il traite de philosophie, moi je voudrais du technique. La seule chose concrète qu'il y a dans ce topic est la solution proposée par screetch, à base d'arborescence de fichiers qui, malgrés le fait qu'elle soit très bonne, ne me convient pas, car elle ne résout pas mon problème.

Bonjour,

J'imagine que le constructeur de Class1 reste accéssible pour l'utilisateur (en faisant NM1::Class1()) mais pas du tout pour NM2 ?
Quoi que ... si dans NM2 je fais NM1::Class1() ... on casserai le mot clé ?

Je ne suis donc pas sur de comprendre, mais sinon la solution, c'est juste de mettre le constructeur de class1 en protégé ou privé (comme cela vous arrange).

Et si ... on doit laisser un accès à un utilisateur, on fait une sorte de factory qui est amie de Class1.

Citation:

---

Envoyé par r0d

Oui j'avais vu ce topic, mais il traite de philosophie, moi je voudrais du technique. La seule chose concrète qu'il y a dans ce topic est la solution proposée par screetch, à base d'arborescence de fichiers qui, malgrés le fait qu'elle soit très bonne, ne me convient pas, car elle ne résout pas mon problème.

---

En fait tu as le constructeur "internal" mais pas forcément toute la classe, c'est ça ? Genre seul NM1 peut construire l'objet, mais NM2 peut s'en servir, sans pour autant pouvoir le construire ?

oui, C# a une meilleure granularité sur le contrôle d'accès. Je n'ai rien a rajouter par rapport au post dont tu parles plus haut, ca m'ennuie carrément car la plupart du temps je me retrouve a publier plus que ce que je ne voudrais (trop?)

La division en module est bien mais si on divise trop, on se retrouve a devoir tout publier pour que deux modules proches puissent fonctionner ensemble et on se retrouve au point de départ, tout est public.

J'ai deja vu du code horrible qui avait in define "internal", lorsqu'on compile le projet c'est définit comme "public" et lorsqu'on compile l'executable qui utilise la bibliothèque, internal est défini comme "private". jen e cautionne pas, je dis juste que je l'ai vu :)

je voudrais le mot clé internal (ou package, ou namespace), ainsi que le mot clé friend plus puissant

Code:

---

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

namespace Namespace {   class ComplexScopes { public: ComplexScope(); ~ComplexScope(); namespace: // utilisable seulement si on appelle de Namespace int doWork(); friend class A: // privé et utilisable depuis A int makeAWork(); private: // privé privé, même A peut aller se faire voir. int m_data; };   }

---

/soupire

Citation:

---

Envoyé par jblecanard

En fait tu as le constructeur "internal" mais pas forcément toute la classe, c'est ça ? Genre seul NM1 peut construire l'objet, mais NM2 peut s'en servir, sans pour autant pouvoir le construire ?

---

Dans mon exemple oui c'est bien ça.
Un exemple (un poil) plus complexe pour comprendre un peu mieux l'intérêt de ce mot clé:

Code:

---

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

// module qui gère les resources (mémoire RAM par exemple) namespace ResourcePool { // classe qui gère les images utilisées par l'application class ImagePool { internal: ImagePool(); void PreLoadImages();   public: const Image& GetImage( int img_id ) const; }; }

---

L'idée de la classe ci-dessus est que c'est elle qui gère toutes les images (chargées en RAM) de l'application. Cela peut être fort pratique, et notamment lorsque on va devoir afficher x fois la même image.
L'idée du internal dans le code ci-dessus c'est que seules les classes du namespace ResourcePool auront la possibilité d'instancier ImagePool, et d'appeler certaines fonctions, par exemple ici j'ai mis la fonction PreLoadImages() qui devra charger les images nécessaires en RAM. L'avantage de bien découpler cette action du reste du programme est qu'ainsi on peut facilement gérer l'écran d'attente pendant le chargement (curseur xor splashscreen xor progressbar xor video xor ...).

Bon et donc, l'idée de cet exemple c'est que toutes les classes de l'application qui ne sont pas dans le namespace ResourcePool n'auront pas accès à tout ce qui touche les données, mais elles auront accès à GetImage().

On pourrait utiliser private + friend, mais parfois (pour ce cas-là mon exemple n'est pas bon) il faudrait déclarer 30 friends...

Ma question est juste une question pratique, car ce mot clé est juste pratique. Rien d'indispensable quoi.

Salut,

Citation:

---

Envoyé par r0d

On pourrait utiliser private + friend, mais parfois (pour ce cas-là mon exemple n'est pas bon) il faudrait déclarer 30 friends...

---

30 friend. C'est pas fessebouc le C++. Si tu as autant d'amis, c'est louche pour ton architecture ou pour les responsabilités de ta classe.

Citation:

---

Envoyé par r0d

Ma question est juste une question pratique, car ce mot clé est juste pratique.

---

Pour ton problème : pimpl idiom ? Pattern Adapter ?

D'une certaine façon, je me demande si ce n'est pas un pb de design au départ : interface mal ségréguée ? classe multi responsable ?

Ceci dit tant que la division en module/package n'existera pas, j'ai du mal à voir une solution pertinente qui ne s'appuie pas in fine sur l'arborescence et les options de compil