sous classes et friend?

Version imprimable

08/11/2009, 21h11
ElPedro

[Résolu]sous classes et friend?
Bonjour à tous,

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

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

Salut,
La Norme (qui est payante et n'existe pas en gratuit) dit bien que :
Citation:
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:

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 ?

10/11/2009, 13h28
méphistopheles

Citation:

Envoyé par 3DArchi

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.
10/11/2009, 13h35
koala01

Salut,

Citation:

Envoyé par méphistopheles

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 :P

Mais le mieux serait de s'adresser directement aux dev de Gcc ou de visual afin de savoir ce qu'il en est ;)
10/11/2009, 15h07
méphistopheles

Citation:

Envoyé par koala01

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)

Citation:

Envoyé par koala01

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 :P

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 :aie:
10/11/2009, 15h53
koala01

Citation:

Envoyé par méphistopheles

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

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

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 )
10/11/2009, 17h15
3DArchi

Citation:

Envoyé par koala01

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 )

Ce qui est surprenant c'est qu'il soit aussi sur Visual. Quand le même bug est sur 2 compilos, même si ce n'est pas représentatif, j'ai plus de doute sur ma compréhension de la norme.
Si d'autres intervenants ont des compilos pour tester, ce serait intéressant de connaître leur comportement.
10/11/2009, 17h32
koala01

Je ne serais pas plus étonné que cela si l'on venait me dire que c'est du à un problème dont le parser ou le lexer sont implémentés...

Pour peu qu'ils le soient de manière plus ou moins similaire sous Gcc et sous VC, il devient relativement cohérent que le même problème se pose sous les deux :D

Maintenant, peut être la norme présente-t-elle une règle qu'il est matériellement (enfin, on se comprend sur le terme hein:question:) impossible de suivre dans l'état actuel des choses :P
11/11/2009, 17h32
ElPedro

1/ Merci à tous pour les réponses très claires.

2/ La norme serait donc 'incompatible' avec la STL?!

En effet, j'aime écrire des sous classes dans des fonctions. Par exemple pour écrire des foncteurs. Et bien je me fais jeter par Visual quand je la déclare en friend (qui me dit qu'il est interdit dans une fonction de déclarer en friend des sous classes locales à une fonction).

Bref, sans ce 'bug', plus de foncteurs, sauf remontés / déclarés en tant que classes (et non sous classes) !

Ou alors je me trompe complètement (ce qui est fort probable)?
11/11/2009, 18h53
méphistopheles
Citation:

Envoyé par ElPedro

1/ Merci à tous pour les réponses très claires.

2/ La norme serait donc 'incompatible' avec la STL?!

J'en doute :roll:... La stl étant le résultat des précédentes normes...

Citation:

Envoyé par ElPedro

En effet, j'aime écrire des sous classes dans des fonctions. Par exemple pour écrire des foncteurs. Et bien je me fais jeter par Visual quand je la déclare en friend (qui me dit qu'il est interdit dans une fonction de déclarer en friend des sous classes locales à une fonction).

Bref, sans ce 'bug', plus de foncteurs, sauf remontés / déclarés en tant que classes (et non sous classes) !

Ou alors je me trompe complètement (ce qui est fort probable)?

Je ne sais pas s'il est possible d'écrire des classes dans des fonctions (jamais essayé, jamais posé la question), mais par contre, un foncteur n'est pas une classe dans une fonction, mais une sous-classe d'une classe, sous-classe elle-même munie d'un opérateur double parenthèses du genre
Code:

1 2 3 4 5 6 7 class Classe { class Foncteur_comp { operator()(const Classe &,const Classe &); }; };
pour un foncteur de comparaison.

(si l'on ne pouvait faire de foncteur sous VC++, je crois pas que grand monde l'utiliserait... déjà que pour l'optimisation en vitesse c'est pas ça....)
11/11/2009, 19h38
Goten

Citation:

Je ne sais pas s'il est possible d'écrire des classes dans des fonctions

Si des classe locales à des fonctions, c'est possible, et y'a quelques applications. (ça court pas les rues).
Quand on foncteur jvois pas où vous voulez en venir :
un foncteur est par définition un objet qui peut avoir la sémantique d'une fonction. (un classe surchargeant l'op())
11/11/2009, 19h55
ElPedro

>>(jamais essayé, jamais posé la question)
C'est extrêmement courant. C'est une technique basique très utile pour circonscrire le code à des fonctions, et pour écrire certaines macro.:ccool:

>>un foncteur n'est pas une classe dans une fonction, mais une sous-classe d'une classe
Désolé, mais un foncteur est juste une classe (avec l'operator()). :aie:

>>>La stl étant le résultat des précédentes normes...
Encore raté, la stl a été intégrée dans la norme (après avoir été écrite par Stepanov). D'ailleurs le dernier papier 'on iterator' (qui est sorti il y a 2 jours) de A.Alexandrescu revient là dessus.

>>>déjà que pour l'optimisation en vitesse c'est pas ça....
Ben voyons ^^! :lol:

L'idée est que certes la STL est certes utilisable, mais sans ce fichu friend, on perd encore plus au niveau ergonomie du code entre "l'endroit où la fonction est utilisée" et "l'endroit où la fonction est codée".

@Goten
exemple:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
class CBase
{
    int mMember; // private
    void doSomething(std::list<CBase>& pVec);
};
 
// cpp:
void CBase::doSomething(std::list<CBase>& pVec)
{
    struct CFoncteur
   {
        void operator()(CBase& c)
        {
              c.mMember = 3; // acces membre private!
         }
   };
 
   std::for_each(pVec.begin(), pVec.end(), CFoncteur());
 
}

Ce code n'est pas valide d'après la norme.:(

11/11/2009, 20h08
Goten

Et c'est pour ça qu'on inventa les lambda :'). Sinon ouai à chaud là je vois pas d'autre solutions que d'écrire un accesseur. Mais j'ai pas les idées trop en place, peut être que quelqu'un verra une solution plus élégante.
11/11/2009, 20h39
Arzar

Citation:

Envoyé par koala01

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

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 )

??
Au contraire, cette page liste le comportement "Nested classes can access private members and types of the containing class." dans la catégorie "Non-bugs" car c'est le comportement préconisé par le comité dans le defect 45 !
11/11/2009, 23h22
screetch
scrogneugneu bon peut etre je reviens de soirée et je suis pas de bonne humeur, mais suis-je le seul a etre exaspéré par

Code:

class C { // entire body is private

qui pourrait etre ecrit sans commentaire
Code:

1 2 class C { private:
juste pour la clarté ? (oui je chipotte)
11/11/2009, 23h51
Goten

Jsuis du même avis.. mais bon c'était qu'un test case so...

A vrai dire, je suis dans les premiers à m'autoriser un code proche de
Code:

1 2 3 4 5 6 7 8 9 10 class MaClass { /* des typedef (privés) voire, des classes imbriquée * à usage interne de la classe */ public: /* interface publique */ private: /* membres privés */ }
Mais, je suis d'accord avec toi que, quitte à placer un commentaire pour rappeler que la visibilité par défaut d'une classe est private, il est bien plus opportun de, simplement, le signaler explicitement :D

12/11/2009, 00h14
ElPedro

Merci mille fois Azrar!
Bien vu!:D

Thread complété!

Edit : Arf j'avais pas vu qu'il y avait une seconde page :aie:. Effectivement, pas de soucis, j'utilise toujours public: private: mais je voulais ne pas encombrer le code. Encore merci à tous!

EDIT2:
En fait c'est le comportement "conseillé", mais cependant il ne fait actuellement pas partie de la norme. Le defect 45 est de statut DR, et non TC1. Par conséquent il n'a pas été intégré dans la norme, bien qu'il ait été discuté en 1998 (cf "ONLY RESOLUTIONS FOR ISSUES WITH TC1 STATUS ARE PART OF THE INTERNATIONAL STANDARD FOR C++").
12/11/2009, 09h43
3DArchi

Citation:

Envoyé par Arzar

??
Au contraire, cette page liste le comportement "Nested classes can access private members and types of the containing class." dans la catégorie "Non-bugs" car c'est le comportement préconisé par le comité dans le defect 45 !

En somme, il s'agissait d'une certaine ambiguïté résolue vers les classes contenues sont considérées comme des membres de la classe contenant et ont donc les mêmes accès qu'une méthode par exemple. D'où, les compilo qui accepte ce code.
Merci Arzar pour cette précision chirurgicale :mouarf: