C++ : classe imbriquees...

Recherche :

Dernière réponse

Sujet : C++ : classe imbriquees...

BENB

legreg a écrit a écrit :

bon en C++, tu n'as pas de classes
anonymes mais tu as des pointeurs
de fonctions (si c'est une consolation)

j'ai l'impression qu'un grand nombre de
details de C++ sont a la discretion
du compilateur ce qui fait
qu'il est difficile de sortir des sentiers
battus meme en s'en tenant a la norme
ex: interdiction d'avoir des declarations
des fonctions "normales" a l'interieur d'une autre fonction
mais s'il est possible de declarer une classe
a l'interieur d'une fonction rien n'interdit
a cette classe d'avoir des fonctions membres..

j'aimerai bien savoir si les compilateurs
gerent bien ce genre de cas..

A+
LEGREG

ben si tu peut mettre le proto d'une fonction dans une autre, mais pas sa definition.

Je suppose que c'est la meme chose pour une classe de fonction soit le definition des membres se font dans la definition de la classe, soit hors de la fonction, mais bon j'ai ai jamais utilise...

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

BENB

El_gringo

legreg a écrit a écrit :

bon en C++, tu n'as pas de classes
anonymes mais tu as des pointeurs
de fonctions (si c'est une consolation)

j'ai l'impression qu'un grand nombre de
details de C++ sont a la discretion
du compilateur ce qui fait
qu'il est difficile de sortir des sentiers
battus meme en s'en tenant a la norme
ex: interdiction d'avoir des declarations
des fonctions "normales"
a l'interieur d'une autre fonction
mais s'il est possible de declarer une classe
a l'interieur d'une fonction rien n'interdit
a cette classe d'avoir des fonctions membres..

j'aimerai bien savoir si les compilateurs
gerent bien ce genre de cas..

A+
LEGREG

en tout cas, selon la norme, ils devraient permettre l'utilisation de ces "classes de fonction"

[jfdsdjhfuetppo]--Message édité par El_Gringo--[/jfdsdjhfuetppo]

LeGreg

bon en C++, tu n'as pas de classes
anonymes mais tu as des pointeurs
de fonctions (si c'est une consolation)

j'ai l'impression qu'un grand nombre de
details de C++ sont a la discretion
du compilateur ce qui fait
qu'il est difficile de sortir des sentiers
battus meme en s'en tenant a la norme
ex: interdiction d'avoir des declarations
des fonctions "normales"
a l'interieur d'une autre fonction
mais s'il est possible de declarer une classe
a l'interieur d'une fonction rien n'interdit
a cette classe d'avoir des fonctions membres..

j'aimerai bien savoir si les compilateurs
gerent bien ce genre de cas..

A+
LEGREG

BENB

legreg a écrit a écrit :

ce que j'appelle classe anonyme
c'est le type particuler d'inner classe qui specialise
une classe existante mais sans nommage particulier

C'est particulierement utilise pour tout ce qui
est gestion des evenements dans la librairie Java.
(tu veux juste modifier le comportement d'un bouton,
et tu ne veux pas te taper toute la declaration
et surtout choisir un nom pour une classe qui ne
sera pas reutilise par ailleurs)

A+
LEGREG

C'est une classe qui est definie au moment de l'appel d'une fonction et a laquelle on ne donne pas de nom.

En C++ tu ne peut pas, mais tu peut definir une classe dans une fonction me semble-t-il...

LeGreg

ce que j'appelle classe anonyme
c'est le type particuler d'inner classe qui specialise
une classe existante mais sans nommage particulier

C'est particulierement utilise pour tout ce qui
est gestion des evenements dans la librairie Java.
(tu veux juste modifier le comportement d'un bouton,
et tu ne veux pas te taper toute la declaration
et surtout choisir un nom pour une classe qui ne
sera pas reutilise par ailleurs)

A+
LEGREG

El_gringo

legreg a écrit a écrit :

ben modifier le comportement d'une
instance particuliere d'un objet
comme en java pardi!

LEGREG

j'vois pas le rapport avec des instances anonymes !!

LeGreg

El_Gringo a écrit a écrit :

non, ça c claire ! ms à quoi ça pourrait bien te servir en plus !?

ben modifier le comportement d'une
instance particuliere d'un objet
comme en java pardi!

LEGREG

BENB

El_Gringo a écrit a écrit :

moi je trouve ça bisard cette histoire ! J'avais justement lu dans "programmez" qu'une classe interne peut accèder aux membres privés de la classe qui la contient. Ms apparement en fait, ça dépend du compilo !?

Ben en fait mon truc doit marcher sur quelques plates-formes...
sous linux, g++ no Pb
sous HP-UX aCC no Pb
sous Solaris Pb :D
Donc je voulais savoir quel etait la norme...
Or il semblerait que la norme soit que l'acces est interdit, ce qui ne me gene pas plus que ca, puisque la classe imbriquee peut etre friend...

Ma question etait plutot de savoir quelle etait la norme.

Par contre (a moins d'une erreur de ma part) en Java c'est clair l'acces est authorise...

El_gringo

moi je trouve ça bisard cette histoire ! J'avais justement lu dans "programmez" qu'une classe interne peut accèder aux membres privés de la classe qui la contient. Ms apparement en fait, ça dépend du compilo !?

El_gringo

legreg a écrit a écrit :

j'en apprends tous les jours :)
je connaissais le coup du typedef
dans la declaration de classe
mais pas les classes imbriquees en C++..
Et puisqu'on y est, on peut pas faire des instances de classes
anonymes par hasard :D?

A+
LEGREG

non, ça c claire ! ms à quoi ça pourrait bien te servir en plus !?

LeGreg

j'en apprends tous les jours :)
je connaissais le coup du typedef
dans la declaration de classe
mais pas les classes imbriquees en C++..
Et puisqu'on y est, on peut pas faire des instances de classes
anonymes par hasard :D?

A+
LEGREG

Da True Clouseau

Non les méthodes de B n'ont pas accès aux membres privés de A.
g++ a pas mal de pb avec les contrôles d'accès dès qu'on sort des sentiers battus.

Citation :

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 friend-
ship to an enclosing class; the usual access rules (_class.access_)
shall be obeyed. The members of an enclosing class have no special
access to members of a nested class; the usual access rules
(_class.access_) shall be obeyed. [Example:
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
}
};
--end example]

[jfdsdjhfuetppo]--Message édité par DA TRUE CLOUSEAU--[/jfdsdjhfuetppo]

BENB

deathsharp a écrit a écrit :

ben normalement non.
private c bien prive a la classe et personne d'autre.
maintenant faudrait trouver une copie de la norme C++.

si gcc l'accepte, Visual Studio.NET me le jette a la tete

B est membre de A...
le compilo solaris le refuse aussi... mais le HP accepte :D
mais il me semble que gcc est plus proche de la norme...

deathsharp

ben normalement non.
private c bien prive a la classe et personne d'autre.
maintenant faudrait trouver une copie de la norme C++.

si gcc l'accepte, Visual Studio.NET me le jette a la tete

BENB

la classe B est dans l'espace de nommage de A
si elle est public, on peu y acceder hors de A en faisant A::B
la classe B peut alors avoir un nom plus simple que si elle etait hors de A

c'est par exemple comme ca que peuvent etre propose les iterateurs de la STL...
il n'y a alors aucun probleme a ce que tous se nomment iterateurs...

ca existe ca ? a quoi ca sert ?

BENB

Une classe imbriquee est une classe qui est declaree dans une autre
class A
{
class B
....

Ma question : les elements prives de A sont-ils visible pour B ?

la question est theorique

pour gcc la reponse semble etre oui pour d'autres compilo elle semble etre non. Que dit la norme sur ce point...

[jfdsdjhfuetppo]--Message édité par BENB--[/jfdsdjhfuetppo]