Le mot cl� "Internal" de C# en C++

Bonjour � tous,

Voila je m'initie au fur et � mesure au dev C++ et venant de C#, j'ai beau avoir cherch� comme un forcon�, je n'arrive pas � trouver ou m�me � reproduire l'effet du mot-clef "internal" qui � l'�norme avantage de proposer les �l�ment appos� de par ce mot clef uniquement visible dans le namespace.
Il est vrai que 3 choix interm�diaire se propose:
* mettre tout en public au point de rendre public des �l�ments qui ne devrait pas l'�tre.
* utiliser un sous-package mais ceci ne fonctionnne pas si l'on souhaite mettre la classe publique avec des fonctions priv�es.
* Utiliser du friend � outrance avec tout ce qui devrait �tre internal en priv�/protected et c'est la solution que j'ai choisit actuellement qui commence r�ellement � �tre bouffante et chiante. Surtout qu'il n'est m�me pas possible de faire un "friend namespace".

Bref, j'aimerais connaitre les solutions les plus viables pour palier � cet ENORME manque.

D'avance merci,
Lucyberad.

Salut!

Je pense qu'il va falloir que tu revoies totalement comment une application C++ est organis�e car tu peux oublier la notion de package. #include n'a rien a voir avec import et les namespaces n'ont pas le m�me effet en C++ qu'en C#/Java/ActionScript.

Il n'y a pas d'equivalent d'internal en C++ parcequ'il n'y a pas de package en C++.
Un namespace est avant tout un "nom" qui servira de prefix automatique pour tout ce qui est dans le namespace, vraiment rien de plus. Tu peux d�clarer n'importe o� le contenu d'un namespace en C++ : c'est un concept orthogonal � la fa�on d'organiser les fichiers (ce qui n'est pas le cas avec les packages). De la m�me fa�on, tu peux mettre n'importe quoi dans tes fichiers, m�me un programme entier dans un unique cpp si �a te chante. En C++, tu organises les fichiers de la mani�re que tu veux. La seule contrainte est que quand tu compiles un cpp, il doit contenir au moins les d�clarations de tous les symboles (variables, classes, etc) qui sont utilis�s dans le cpp. C'est pour cela qu'on inclus les fichiers (les headers) qui d�tiennent ces d�clarations. Une fois le cpp compil�, le linker va faire le lien entre les d�clarations et les d�finitions manquantes, qui sont (ou pas) d�finies dans d'autres cpp.

Maintenant dans ton cas, tu veux en gros que l'impl�mentation de ton application ou module ne soit pas accessible � l'utilisateur. C'est exact? De loin, je dirais qu'il faurait utiliser l'idom "pimpl" mais je ne suis pas certains que ce soit ce que tu veux faire.

Salut,

A vrai dire, je me pose la question de savoir si tu en as vraiment besoin...


Je m'explique:

D'abord, est-il *r�ellement* de notre ressort de d�cider, � partir du moment o� l'on a d�cid� d'exposer une classe, un comportement ou une fonction libre, de l'endroit � partir duquel il est possible d'y acc�der :question:

Ensuite, si tu respecte un tant soit peu demeter, et que tu veilles d�j� � ce que chaque classe n'expose pas plus que le stricte n�cessaire pour qu'elle puisse fournir les services que l'on peut attendre d'elle, tu arrive d�j� � un point o�, finalement, tu peux clairement ne pas t'inqui�ter de l'endroit � partir duquel le service est appel�.

Apr�s tout, le but d'un espace de noms est, tout simplement, de "regrouper entre eux" les diff�rents �l�ments qui "travaillent bien ensemble".

De plus, la compilation sous la forme d'unit� de compilation (un fichier d'en-t�te + un fichier d'impl�mentation) te permet, si tu s�pare correctement les d�finitions des diff�rentes classes et que tu veille � n'inclure dans un fichier d'en-t�te que le stricte minimum en pr�f�rant, chaque fois que faire se peut, la d�claration anticip�e, te donne parfaitement le moyen de permettre l'utilisation d'une classe sans, pour autant, permettre � l'utilisateur d'utiliser un autre type qui ne sert qu'� titre d'argument de fonction, par exemple.

Enfin, il faut savoir qu'une structure imbriqu�e n'est accessible que selon l'accessibilit� dans laquelle elle est d�clar�e.

Ainsi, si tu as besoin d'une structure qui n'a strictement pas vocation � �tre expos�e pour un usage strictement interne, tu peux la d�clarer dans une accessibilit� priv�e et "le reste du programme" en ignorera jusqu'� l'existence (cela va d'ailleurs encore plus loin car il est possible de d�finir une classe ou une structure � l'int�rieure m�me d'une fonction... Elle n'est alors utilisable que dans cette fonction particuli�re)

Et tu peux m�me envisager, pour "compl�ter le tableau", de ne faire qu'une d�claration de la structure imbriqu�e dans la d�finition de la structure qui l'emploie, et de d�finir la structure imbriqu�e que... dans le fichier d'impl�mentation, avec cependant les restrictions d'usages pour les d�clarations anticip�es (il ne doit �tre question de la structure imbriqu�e que sous forme de pointeur ou de r�f�rence jusqu'� ce que la d�finition r�elle soit apparue dans le code).

L� encore, j'ai bien compris le concept de la d�claration dans le CPP (et non le .h) et les nested class ou nested function.

Il est vrai que dans l'absolu, une classe qui partage une moiti� publiquement et une autre seulement au namespace peut en toute th�orie se permettre de montrer le tout � tout le monde car une classe doit �tre autonome. N�anmoins, c'est toujours mieux de faire cette "formalisation" qui permet de clairement d�limiter les pouvoirs de celui qui l'utilise.
Dans mon cas, je vais quand m�me plus loin car l'ensemble de mes classes sont destin�es � un framework et certaines m�thodes sont clairement destin�es � un usage interne au framework. Je vois donc clairement une classe comme un composant int�gr� � un framework dont le package/namespace sert � en donner les limites. Apr�s tout, le package comme je le pense est un objet auquel un autre package objet fait appel.
Or, le namespace comme tu dit n'est que structuration du code n'influant en rien sur la visibilit� de ce qui le compose.
En demandant l'internal, je pense donc avant tout � l'exemple suivant: prenons le cas d'une entreprise; les patrons et employ�s sont dans la m�me entreprise mais il parait logique que le patron soit le seul � avoir acc�s � la signature des contrats avec le client ext�rieur. Un client communiquant direct avec un technicien pour la signer un contrat peut mettre � mal l'entreprise pour avoir entrepris une production contr�l�e et d�sir�e sauf si on a valid� ce technicien comme apte � recevoir les clients.
Je trouve juste un petit peu dommage que le "croulant de vieillesse" C++ soit plut�t r�fractaire � ce point, mais bon: je vais faire avec...

J'ai pens� � la solution de l'objet public (pimpl), mais en gros ca double tout les objets pour rien et alourdi le tout, m�me si ca me permettrait symboliquement d'obtenir ce que je souhaite.

Merci de vos infos,
Lucyberad.

Mais ce qu'il faut comprendre, c'est que, si tu as une (ou plusieurs) classe(s) qui ne servent qu'� usage interne dans ton espace de noms, en organisant "correctement" tes en-t�tes et tes inclusions, il t'est tout � fait possible de "simplement" ne pas exposer le fichier d'en-t�te dans lequel elle(s) est(sont) d�clar�e(s)...

Le r�sultat imm�diat sera que celui qui utilisera ton framework ignorera purement et simplement l'existence de cette (ces) classe(s), ou, du moins, sera dans l'impossibilit� totale de l'utiliser...

Cela ne t'oblige absolument pas � "doubler" tes objet, cela t'oblige "seulement" � impl�menter les choses diff�remment.

Par exemple, tu peux parfaitement envisager une premi�re classe proche de
fichier MaClassPrivee.h

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#ifndef MACLASSPRIVEE_H #define MACLASSPRIVEE_H namespace MonEspaceDeNoms { class MaClassPrivee { public: MaClassPrivee(int i, int j){} }; } // namespace MonEspaceDeNoms #endif

---

Si tu as besoin de cette classe de mani�re uniquement interne, tu peux parfaitement l'utiliser sous la forme de
fichier AutreClass.h

Code:

---

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

#ifndef AUTRECLASS_H #define AUTRECLASS_H namespace MonEspaceDeNoms { class MaClassPrivee; // juste une déclaration anticipée class AutreClass { public: AutreClass(int i, int j); ~AutreClass(); private: MaClassPrivee * pm_; }; } // namespace MonEspaceDeNoms #endif

---

fichier AutreClass.cpp

Code:

---

1 2 3 4 5 6 7 8 9 10

#include "MaClassPrivee.h" #include "AutreClass.h" namespace MonEspaceDeNoms { AutreClass::AutreClass(int i, int j):pm_(new MaClassPrivee(i,j)){} AutreClass::~AutreClass() { delete pm_; } } // namespace MonEspaceDeNoms

---

Tu peux inclure le fichier MaClassPrivee.h dans n'importe quel fichier d'impl�mentation qui aura besoin de cette classe (�ventuellement avec une d�claration anticip�e dans le fichier d'en-t�te correspondant), et, pour autant que tu ne fournisse pas le fichier MaClassPrivee.h aux utilisateurs, tu as, de facto, limit� l'utilisation de cette classe au d�veloppement de ton framework ;)

Citation:

---

Je trouve juste un petit peu dommage que le "croulant de vieillesse" C++ soit plut�t r�fractaire � ce point, mais bon: je vais faire avec...

---

Il est plus probable que tu n'aies pas compris qu'en C++ il n'y a pas besoin de mot cl� pour "cacher" du code (ne pas le rendre accessible au code client), comme l'a expliqu� koala01. Le mot cl�e internal est apparu dans les langages a package pour combler le fait que ce probl�me n'�tait pas r�solvable, alors qu'en C++ il n'y a tout simplement rien a ajouter, il suffit d'organiser son code en cons�quence. La structure m�me du code donne l'accessibilit� (au dela des private/public/protected/friend).
Mais j'imagine que tant qu'on ne comprends pas comment faire, �a n'a rien d'evident.

Citation:

---

Envoy� par Klaim

Il est plus probable que tu n'aies pas compris qu'en C++ il n'y a pas besoin de mot cl� pour "cacher" du code (ne pas le rendre accessible au code client), comme l'a expliqu� koala01. Le mot cl�e internal est apparu dans les langages a package pour combler le fait que ce probl�me n'�tait pas r�solvable, alors qu'en C++ il n'y a tout simplement rien a ajouter, il suffit d'organiser son code en cons�quence. La structure m�me du code donne l'accessibilit� (au dela des private/public/protected/friend).
Mais j'imagine que tant qu'on ne comprends pas comment faire, �a n'a rien d'evident.

---

J'irais presque plus loin en disant que si ce mot est devenu n�cessaire en C#, c'est parce qu'ils ont commis la b�tise (tout comme ne java, d'ailleurs) de vouloir rassembler la d�finition des classes et l'impl�mentation de leurs fonctions membre.

Bien sur, il y a "� boire et � manger" dans cette d�cision, car, effectivement, cela peut apporter comme avantage de ne plus *forc�ment* recourir � un pr�processeur pour effectuer le regroupement � notre place, et l'on peut imaginer que cela facilite le travail du compilateur (ou de la machine virtuelle), ou encore, il faut avouer que cela permet de ne plus avoir qu'un fichier par unit� de compilation � g�rer...

Mais, � cot� de cela, cela occasionne plusieurs probl�mes connexes, comme le fait que, tout le code se trouvant dans un m�me fichier, il devient de facto beaucoup plus volumineux ou celui qu'il devient impossible de limiter l'acc�s � une classe donn�e � un nombre restrient d'unit�s de compilaton.

Encore une fois, voici bien la preuve que rien n'est gratuit en informatique, et que la plupart des d�cisions prises font souvent perdre d'un cot� ce qu'elle font gagner de l'autre ;)

Il est clair que comme vous dites, c'est une vision differente.

Le mot clef internal, je m'en suis toujours servit pour bien nomenclaturer les fonctionnalit� d'un framework plus que de masquer des fonctions sensibles.
En effet, ce mot clef permet d'aborder un package comme un objet poussant plus loin la conception.
Je me souvient avoir commenc� la prog avec VB.net et j'ai tout appris avec l'intellissense car ce dernier me permettait de facilement faire une appli winform sans tout casser.
Alors qu'avec MFC, � tout moment je tout tr�s facile de tout casser et d�tourner pour faire quelquechose que MFC ne voulait pas.

Donc dans l'absolu, comme je l'ai dit, je peux mettre ce que je mettait en internal public, avec quelques modification, mais j'aime vraiment pousser la rigueur jusqu'au bout avec internal et je ne peux pas que ce soit une faiblesse de Java ou C#.


Je trouve donc que les deux sont viable m�me si ma pr�f�rence personelle va clairement � l'internal. Mais je vais m'y faire et revoir l�g�rement ma copie.

A noter: je trouve un friend bien plus d�gueux qu'un internal d'ailleurs. Je pense (suite � ce post) qu'il faut que je trouve une solution pour ne pas devoir en mettre 1 seul.

Simple question un peu en marge du sujet: qu'est-ce qui am�ne un d�veloppeur � passer du C# au C++ ? En g�n�ral les d�veloppeurs ont tendance � fuir le C++ au profit d'autres langages dit "plus simples" ;)

Citation:

---

Envoy� par Lucyberad

En effet, ce mot clef permet d'aborder un package comme un objet poussant plus loin la conception.

---

Je pense que la sel chose qua �a pousse, c'est le (bouchon trop loin) paradigme objet.

En toute rigueur, le mieux ne serait-il pas que les fonctions et classe inaccessible (private/internal) ne soit m�me pas connu de l'utilisateur ?

salut,

l'equivalent le plus proche de "internal" que j'ai trouv� je l'ai �mul� avec des fichiers include "cach�s".

en gros mon code est divis� en 3 branches :
src/ contient les sources
api/ contient les fichiers include avec les classes export�es
include/ contient des include priv�s (internal) que les modules externes ne peuvent pas utiliser (ils ne sont pas dans le repertoire $(INCLUDE) du makefile, donc invisibles)

et j'ai divis� mon code en sous-repertoires qui sont des "modules"

par exemple, il est possible d'acceder a la classe Module qui contient le code pour charger un executable
mais les classes concr�tes sont dans des fichiers include cach�s, et les classes "Helper" qui ne doivent pas etre utilis�es directement sont �galement inaccessibles.

j'ai donc ainsi un peu "�mul�" la notion de package, non pas avec des namespace mais avec l'arborescence de fichiers.

Salut,

Citation:

---

Envoy� par screetch

salut,

l'equivalent le plus proche de "internal" que j'ai trouv� je l'ai �mul� avec des fichiers include "cach�s".

---

J'ai aussi vu ce genre de d�coupage dans des projets : sources, include_externes, include_internes.
D'une certaine fa�on Boost, reprend ce principe. Par exemple :
boost>function
boost>function>details

Les espaces de noms permettent quand m�me de renforcer cette encaspulation :

Code:

---

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

namespace my_lib { namespace lib_details { class c_impl; } class my_class { private : lib_details::c_impl *p_impl; } }; // écrire [my_lib::]lib_details::XXX devrait interpeller

---

Enfin, sans que ce soit identique, le 'package' peut �tre mis en �uvre par la biblioth�que dynamique : seules les classes export�es sont visibles par l'utilisateur.

et pour Koala :
�Programming is a race between Programmers who create bigger and better idiot-proof programs, and the Universe which is trying to create bigger and better idiots. So far the Universe is winning.� (Rich Cook)

je suis toujours dans cette course; a mon avis si je laisse un moyen meme infime de mal utiliser ma bibliotheque alors un idiot le fera (et pire, me jettera la pierre)
alors je restreint ce que l'on peut utiliser, je cache, je nettoie, je mets en priv�, de sorte que l'utilisateur ne puisse plus se tromper (ou, en tous cas, aient moins de chance)
un exemple :

Code:

---

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

class Mutex { private: void* m_data; public: Mutex(); ~Mutex();   void release(); WaitResult wait(unsigned int waitTime = Forever); };   class ScopedMutexLock { private: Mutex& m_mutex; public: inline ScopedMutexLock(Mutex& m) : m_mutex(m) { m_mutex.wait(); } inline ~ScopedMutexLock() { m_mutex.release(); } private: ScopedMutexLock& operator=(const ScopedMutexLock& other); ScopedMutexLock(const ScopedMutexLock& other); };

---

laisse le choix entre appeler mutex.lock et release a la paluche, ou bien utiliser le code exception-safe et idiot-proof ScopedMutexLock.
Si la fonction est priv�e, seul le ScopedMutexLock peut etre utilis� (je me demande pourquoi mon code est toujours public d'ailleurs, j'etais persuad� de l'avoir chang� il y a des mois... TODO!)


et cacher les classes que l'on ne souhaite pas publier, ca evite de devoir repondre aux idiots qui voulaient QUAND MEME les utiliser

Citation:

---

Envoy� par screetch

et pour Koala :
�Programming is a race between Programmers who create bigger and better idiot-proof programs, and the Universe which is trying to create bigger and better idiots. So far the Universe is winning.� (Rich Cook)

---

C'est marrant. J'ai le sentiment que c'est, d'une certaine fa�on aller un peu contre le C++. Le langage n'a pas renonc� � son expressivit� au profit de la s�curit�. On peut faire de grosses bourdes avec le C++. Cela n�cessite certains idioms pour se faciliter la vie (comme le RAII que tu montres). Mais d'un autre c�t�, tu peux t'en passer, ce qui dans certain cas permet aussi d'�tre plus efficace. Dans un sens, le C++ est un langage qui fait confiance au d�veloppeur. Alors que toi, visiblement non. Pourquoi pas, apr�s tout. Mais personnellement, je pr�f�re pouvoir me taper avec un marteau sur le doigt que ne d'avoir qu'un maillet en mousse pour enfoncer des clous.
Mais c'est un peu HS.

Citation:

---

Envoy� par screetch

et pour Koala :
�Programming is a race between Programmers who create bigger and better idiot-proof programs, and the Universe which is trying to create bigger and better idiots. So far the Universe is winning.� (Rich Cook)

je suis toujours dans cette course; a mon avis si je laisse un moyen meme infime de mal utiliser ma bibliotheque alors un idiot le fera (et pire, me jettera la pierre)
alors je restreint ce que l'on peut utiliser, je cache, je nettoie, je mets en priv�, de sorte que l'utilisateur ne puisse plus se tromper (ou, en tous cas, aient moins de chance)

---

Je travaille �galement en ce sens (et j'ai presque du mal � imaginer un d�veloppeur ou un programmeur qui ne le ferait pas), mais ce n'est pas du tout le sens de mes �crits.

Le sens de mes �crits est, plut�t, proche de

Commence d�j� par n'exposer (m�me � l'�quipe de dev) que ce qui est utile opportun en respectant au mieux demeter.

Ensuite, arrange toi pour que ce qui est expos� (� l'�quipe de dev) mais qui n'est utile qu'en interne ne soit pas expos� � l'utilisateur final en en "sortant" l'en-t�te du circuit des en-t�tes fournies � l'utilisateur

Citation:

---

Envoy� par 3DArchi

C'est marrant. J'ai le sentiment que c'est, d'une certaine fa�on aller un peu contre le C++. Le langage n'a pas renonc� � son expressivit� au profit de la s�curit�. On peut faire de grosses bourdes avec le C++. Cela n�cessite certains idioms pour se faciliter la vie (comme le RAII que tu montres). Mais d'un autre c�t�, tu peux t'en passer, ce qui dans certain cas permet aussi d'�tre plus efficace. Dans un sens, le C++ est un langage qui fait confiance au d�veloppeur. Alors que toi, visiblement non. Pourquoi pas, apr�s tout. Mais personnellement, je pr�f�re pouvoir me taper avec un marteau sur le doigt que ne d'avoir qu'un maillet en mousse pour enfoncer des clous.
Mais c'est un peu HS.

---

Oui, mais non, pas tout � fait...

En fait, il faut quelque part cr�er deux cercles de survie concentriques:

Dans le premier, le plus "proche" de toi (quand tu te trouve au milieu), il y a tes coll�gues et l'�quipe de dev dont tu fais partie.

Tu n'as, a priori, aucune raison de leur faire moins confiance qu'� toi-m�me, et il est sens� (ils en auront de toutes fa�ons sans doute besoin) de leur laisser l'acc�s � "ce qui est � usage interne".

Dans le deuxi�me, tu trouve tous les utilisateurs lambda de ton travail.

Certains sont surement dignes de confiance, mais, juste � d'eux tu risque de trouver le "clampain" parfait, plus b�te que tes pieds, et auquel tu ne confierais pas une boite de conserve vide et �cras�e.

C'est surement "dommage" pour le premier, mais, si cela te permet de "pousser" le second dans la bonne direction, il vaut r�ellement la peine de placer des limites � ce � quoi il a acc�s ;)

C'est quand m�me un peu du nivellement par le bas >< ! Je suis plut�t de l'avis d'Archi sur le coup... Mais j'ai l'impression qu'on s'�loigne.

Au moins, on est tous d'accord pour dire que si l'utilisateur n'as pas � l'utiliser, autant qu'il n'est n'est m�me pas la connaissance... Donc imiter internal par la non-d�livrance des fichiers d'ent�tes probl�matique.

PS : je trouve quand m�me la citation monumental >< !

Dois-je me remettre en cause ?
Cesser de regarder le source des #include de librairies et me contenter de lire la doc ? C'est pourtant instructif/p�dagogique de regarder les #include, surtout quand ce sont des templates...

J'ai un tr�s bel exemple.
Il y a quelques semaines je demandais comment recup�rer le buffer de la sp�cialisation std::vector<bool> afin de le s�rialiser (o� chaque bool n'occupe qu'un bit). Ce n'est qu'en regardant le contenu de l'#include qu'on voit comment faire, mais comme c'est non document� et probablement sp�cifique au compilateur, ce n'est pas standard...

Citation:

---

Envoy� par Lavock

C'est quand m�me un peu du nivellement par le bas >< ! Je suis plut�t de l'avis d'Archi sur le coup... Mais j'ai l'impression qu'on s'�loigne.

---

Encore une fois, oui, mais non, parce que de toute mani�res, tu travaille toujours sur au moins deux cercles de survie...

Je vais prendre un exemple qui sort enti�rement du domaine de la programmation pour me faire comprendre:

Si tu as un coffre fort chez toi, tu laissera surement la combinaison � ta femme, et tu donnera *peut-�tre* un double des cl�s de la maison ou de la voiture "par s�curit�" � un de tes amis.

Ce n'est pas pour cela que tu donnera la combinaison de ton coffre fort � ton ami, ni que tu confiera un double des cl�s de la maison ou de la voiture au premier passant inconnu qui passe dans ta rue ;):

Il ne s'agit nullement de proc�der � un nivellement vers le bas, il s'agit "uniquement" d'appliquer aux gens un "coefficient de confiance" correspondant � la proximit� que tu as par rapport � eux pour d�terminer ce � quoi tu leur donne acc�s de ta personnalit� et de ton intimit�.

Un autre exemple qui me vient en t�te est le secret professionnel / m�dical, auquel est, entre autres, soumie toute personne travaillant dans le domaine des soins.

L�galement, un ambulancier, un infirmier, un toubib ne peuvent pas d�signer une personne et dire "monsieur souffre / souffrait de ..." (le faire est passible d'une amende et d'une peine de prison, et les exceptions sont particuli�rement rares et bien encadr�es par la loi).

Mais c'est oublier un peu vite que tant l'ambulancier que l'infirmier ou le toubib interviennent, finalement, dans la m�me "chaine de secours", et que, si on applique le secret professionnel stricto sensu, cela peut occasionner des retards importants dans le traitement, des analyses faites en double ou en triple, des r�actions inadapt�es et, au final, hypoth�quer les chances de survie de la personne.

C'est la raison pour laquelle il devient "coh�rent" d'appliquer ce que l'on appelle le "secret partag�": on d�cide, en connaissance de cause, de partager le secret avec des gens qui sont soumis au m�me devoir de secret que nous.

Mais ce n'est pas pour cela que l'on d�cidera de partager ce secret avec n'importe qui non plus ;)

�a m�riterait presque qu'on relance l'�ternel d�bat idiot-proof vs doc-only...

Je ne pense pas que se soit un mal de regardait les includes. Le mal est sans-nul doute de faire ce que la doc dit de ne pas faire >< !