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