Discussion :

[Lucyberad]

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.

[Klaim]

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.

[koala01]

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

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).

[Lucyberad]

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.

[koala01]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Klaim]

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.

[koala01]

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

[Lucyberad]

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.

[camboui]

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"

[Lavock]

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 ?

[screetch]

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.

[3DArchi]

Salut,

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[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)
un 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
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

[3DArchi]

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.

[koala01]

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

[koala01]

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

[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.

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 >< !

[camboui]

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...

[koala01]

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

[Lavock]

Ç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 >< !