Discussion :

[ElPedro]

Bonjour à tous,

J'ai remarqué que dans VS2008, une sous-classe a un accès direct aux attributs de la sur-classe.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
struct B
{
struct SousClasse
{
   void doMeBaby(B* b){b->i = 1;}
};
private : 
 int i;
}; // ceci fonctionne sous VS2008

Quelqu'un peut-il me confirmer ou infirmer que dans le standard C++ (que je ne trouve pas grrr ou alors à 18$) la structure SousClasse ne devrait pas avoir accès à 'i'?

Selon la réponse j'aurais des questions + avancées.

ElPedro

[3DArchi]

Salut,
La Norme (qui est payante et n'existe pas en gratuit) dit bien que :

11.8 Nested classes
1 The members of a nested class have no special access to members of an enclosing class, nor to classes or functions that have granted friendship to an enclosing class; the usual access rules (clause 11) shall be obeyed. The members of an enclosing class have no special access to members of a nested class; the usual access rules (clause 11) shall be obeyed.
[Example:

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
class E {
   int x;
   class B { };
   class I {
      B b; // error: E::B is private (1)
      int y;
      void f(E* p, int i)
      {
         p->x = i; // error: E::x is private (2)
      }
   };
   int g(I* p)
   {
      return p->y; // error: I::y is private (3)
   }
};

—end example]

En pratique, MinGW/gcc laisse passé (1) et (2) mais râle sur (3). Idem pour visual.
Il y a peut être une subtilité quelque part ?

[méphistopheles]

Il y a peut être une subtilité quelque part ?

A mon avis, ils (les compilateurs) considèrent simplement les membres des classes membres comme des membres et les fonctions membres des classes membres comme des fonctions membres. Ce qui justifie (1) et (2). En un sens, c'est logique puisqu'une classe a toujours accès aux variables de son bloc/fichier.

Par contre aucune règle ne permettant d'accéder aux membres privés de ses membres, (3) n'a aucune raison de passer.

ensuite, c'est mon interprétation, il faudrais sûrement demander confirmation aux fabricants de compilateurs.

[koala01]

Salut,

A mon avis, il considère simplement les membres des classes membres comme des membres et les fonctions membres des classes membres comme des fonctions membres. ce qui justifie (1) et (2). En un sens, c'est logique puisqu'une classe a toujours accès aux variables de son bloc/fichier.

Par contre aucune règle ne permettant d'accéder aux membres privés de ses membres, (3) n'a aucune raison de passer.

ensuite, c'est mon interprétation, il faudrais sûrement demander confirmation aux fabricants de compilateurs.

Attention, normalement, une classe n'a acces qu'aux (variable ou fonctions) membres publiques des variables membres qui la composent...

Le fait d'imbriquer une classe ne devrait, normalement, changer que le scope dans lequel cette classe est connue, sans influer sur la connaissance que la classe imbriquée (respectivement imbriquante) a de la classe imbriquante (respectivement imbriquée).

Maintenant, il n'est pas exclu qu'il y ait certaines difficultés techniques à mettre ce fait en pratique

Mais le mieux serait de s'adresser directement aux dev de Gcc ou de visual afin de savoir ce qu'il en est

[méphistopheles]

Salut,
Attention, normalement, une classe n'a acces qu'aux (variable ou fonctions) membres publiques des variables membres qui la composent...

C'est bien pour ça que le (3) ne marche pas, mais cette règle n'interdit pas (1) et (2) puisque ceux cis accèdent non paas à leurs membres, mais aux variables des blocs parents ! (pas au sens de l'héritage bien sûr)

Le fait d'imbriquer une classe ne devrait, normalement, changer que le scope dans lequel cette classe est connue, sans influer sur la connaissance que la classe imbriquée (respectivement imbriquante) a de la classe imbriquante (respectivement imbriquée).

Maintenant, il n'est pas exclu qu'il y ait certaines difficultés techniques à mettre ce fait en pratique

Mais le mieux serait de s'adresser directement aux dev de Gcc ou de visual afin de savoir ce qu'il en est

Je suppose qu'ils se sont dit qu'on avais qu'a déclarer nos classe dont on voulait interdire l'accès comme des classes externes, bien que ça ne permette pas une interdiction totale d'accès à l'utilisateur.

En même temps, cette version là est bien pratique, ça évite d'écrire un friend de plus

[koala01]

En même temps, cette version là est bien pratique, ça évite d'écrire un friend de plus

jusqu'au jour où tu passera sur un compilateur qui respecte ce point de la norme (s'il y en a un ) et où tu te fera jeter comme un malpropre parce que l'amitié n'est pas déclarée

Ceci dit, c'est bel et bien un bug (reconnu comme tel par Gcc: http://gcc.gnu.org/bugs/#known sous le numéro 45 )