Specialisation de classe interne : refusé par le standard c++?

**ElPedro** · 17/09/2011, 16h48

Bonjour,

Le code ci-dessous fonctionne sous visual studio (2008,2010). J'accède à un membre privé depuis l'exterieur du code source d'une classe.

Par ailleurs, il est certain dans le standard que les classes internes ont accès aux membres privés d'une classe (ex: permet de faire les foncteurs internes aux fonctions).

A partir de là, il semblerait logique d'accéder depuis l'extérieur aux membres privés d'une classe, en utilisant une spécialisation de template.

Manque de pot, on me dit que c'est pas du c++ légal. J'aimerai savoir ce qui est issu du standard c++ et justifie ce point de vue.

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
24
25
26
 
class ClassA
{
public:
   template <class T>
    class NestedClass{};
 
private:
    int hiddenValue;
};
 
// I am now outside ClassA source code, and I will grant myself access to hiddenValue.
template <>
class ClassA::NestedClass<float>
{
public:
   void changeIt(ClassA& p){  p.hiddenValue = 6;}
};
 
int main()
{
	ClassA a;
	ClassA::NestedClass<float> b;
	b.changeIt(a);
	return 0;
}

A vos avis éclairés,

ElPedro

**koala01** · 18/09/2011, 00h28

Salut!

Trouvé sur le site d'ibm concernant la norme C++:

A nested class is declared within the scope of another class. The name of a nested class is local to its enclosing class. Unless you use explicit pointers, references, or object names, declarations in a nested class can only use visible constructs, including type names, static members, and enumerators from the enclosing class and global variables.

Member functions of a nested class follow regular access rules and have no special access privileges to members of their enclosing classes. Member functions of the enclosing class have no special access to members of a nested class. The following example demonstrates this:

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
24
25
26
27
28
29
30
class A {
  int x;
 
  class B { };
 
  class C {
 
    // The compiler cannot allow the following
    // declaration because A::B is private:
    //   B b;
 
    int y;
    void f(A* p, int i) {
 
    // The compiler cannot allow the following
    // statement because A::x is private:
    //   p->x = i;
 
    }
  };
 
  void g(C* p) {
 
    // The compiler cannot allow the following
    // statement because C::y is private:
    //   int z = p->y;
  }
};
 
int main() { }

Je n'ai pas retrouvé (je n'ai pas cherché bien longtemps non plus

) dans la norme les articles qui en parlent, mais, de toute évidence, une classe imbriquée n'a aucun droit spécifique sur la classe contenante, et vice versa

**3DArchi** · 18/09/2011, 09h21

Salut,
Ce n'est pas une problématique de générique et spécialisation mais c'est lié au droit d'un classe définie dans une autre classe.
Cf cette discussion où cela avait été évoqué. En gros, en C++03, la classe interne n'a pas de droit spécifique vers la classe englobante ... mais ce n'est pas forcément respecté par les compilateurs. En C++11, la classe interne a visibilité des membres privés de la classe englobante histoire de mettre en conformité compilateur, besoin d'implémentation avéré et normalisation.

Donc la réponse à ta question est : non ce n'est théoriquement pas légal (cependant usité) en C++03 mais oui c'est légal en C++11

**ElPedro** · 18/09/2011, 11h16

Merci beaucoup pour vos points de vue, d'ailleurs j'ignorais ces nouveautés du c++11 cependant j'ai l'impression que c'est valide aussi en C++03.

http://www.open-std.org/jtc1/sc22/wg...efects.html#45
"
Proposed Resolution (04/01):

Insert the following as a new paragraph following 11 [class.access] paragraph 1:

A member of a class can also access all names as the class of which it is a member. A local class of a member function may access the same names that the member function itself may access. [Footnote: Access permissions are thus transitive and cumulative to nested and local classes.]
"

Pour info, c'est B.Soustrup qui me dit que c'est pas légal

. Mais je ne vois pas dans la norme le problème. Ou alors, le defect ci dessus ne fait pas officiellement partie de la norme?

**koala01** · 18/09/2011, 12h13

En fait, dans la norme (C++03), il est explicitement mis au chapitre 11.8 Nested classes [class.access.nest]

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.

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

Strutroup et le site ibm ont donc raison en disant que ce n'est pas légal (en C++03 du moins) ! :

Il n'y a aucun droit d'accès particulier, ni pour la classe imbriquée ni pour la classe imbriquante.