Discussion :

[bxdfr]

Bonjour, je dois créer des tests moodle avec le module code runner.

Je veux que la personne code la déclaration d'une classe mère et afin de vérifier la validité de sa déclaration, j'aimerais savoir si les attributs de la classe mère ont bien été déclarés protected et non public (s'il les déclare private, le compilateur lui indique le problème).

Est-ce possible en C++ de tester la visibilité d'un attribut ?

Merci d'avance pour vos réponses.

[Corluk]

Est-ce possible en C++ de tester la visibilité d'un attribut ?

Le mot clé est réflexion. C++ ne fournit aucune méthode pour accéder à la visibilité des membres parce que, à l'exécution, cette information n'existe plus (et le langage ne l'offre simplement pas).
Donc, il faut agir à un niveau supérieur pour obtenir ces informations. Il y a des bibliothèques faites pour cela lesquelles tu peux trouver sur Internet.

[koala01]

Salut,

j'aimerais savoir si les attributs de la classe mère ont bien été déclarés protected et non public (s'il les déclare private, le compilateur lui indique le problème).

Justement, les attributs, les données, devraient, idéalement, TOUJOURS être en accessibilité private, avec une (ou plusieurs) fonction(s) -- qui pourra (pourront) être publique(s), protégée(s) ou privée(s) selon les besoins, qui permettront de manipuler ces données.

Parce qu'il faut bien te dire que les données ne sont que des détails d'implémentation, des éléments qui sont là pour aider les fonctions de ta classe à fournir le comportement que l'on attend de leur part, et que tu peux décider, à n'importe quel moment, de modifier l'organisation de tes données pour obtenir de meilleures performances, par exemple.

Il est donc particulièrement important de faire en sorte qu'il n'y ai que les fonctions membres de la classe qui contient les données qui doivent être modifiées si tu décides de modifier l'organisation de tes données. La raison de ce conseil est "toute simple": Tu n'as aucun moyen de savoir combien de classes héritent de la classe qui contient les données et, si tu dois modifier des fonctions au niveau des classes dérivées, tu risques très fort d'en oublier lorsque tu le feras.

Dans le meilleur des cas, parce que la donnée aura été renommée, tu te retrouverais alors avec une erreur à la compilation, et ce serait donc "assez simple" de corriger les fonctions fautives.

Dans le pire des cas, si la donnée a gardé son nom d'origine mais qu'elle nécessite un traitement différent à cause d'une organisation différente, tu introduit purement et simplement des bugs, car le compilateur ne verra aucune objection à ce que la fonction manipule la donnée de sa "manière d'origine". Et ces bugs t'amèneront à t'arracher les cheveux à te demander "mais pourquoi cela fonctionnait avant et que cela ne le fait plus maintenant", parce que, évidemment, tu ne te rendra compte de l'incohérence du comportement que bien après avoir eu le temps d'oublier que tu as réorganisé la donnée.

Donc, au final, tu dois avoir, dans la classe A (pour savoir de laquelle on parle) une ou plusieurs fonction(s) qui manipulent et qui permettent de récupérer des informations de la part des données. Ces fonctions peuvent être privées, si c'est un comportement "strictement interne", protégée si c'est un comportement qui est accessible aux classes qui héritent de A (comme la classe B, par exemple) ou publique si n'importe qui ayant accès à une instance de A peut faire appel à la fonction; et les classes B, C, D et E qui héritent (de manière directe ou indirecte) de la classe A ne pourront accéder à cette donnée qu'au travers des fonctions que tu auras fournies (et qui sont dans une accessibilité autorisée)

[bxdfr]

Ok, merci pour vos réponses très détaillés.
Donc la réponse est juste NON, on ne peut pas, par programmation, connaître la visibilité d'un attribut ou d'une méthode.

Encore merci a vous

[dalfab]

Bonjour,

Les réponses sont en effet détaillées, mais je ne pense pas avoir lu que c'était impossible.

En résumant Corluk a dit que ne pouvait se faire qu'à la compilation et que ça nécessitait d'utiliser la 'reflexion', et Koala01 a expliqué et démontré que les attributs ne doivent jamais jamais être déclaré protected. D'ailleurs selon moi, il aurait oublié le cas des données ayant sémantique de valeur pour lesquelles on peut avoir des membres public, mais une chose sure : des attributs membres protected ça n'a pas de sens.

On peut donc au moment de la compilation s'intéresser à l'accessibilité des membres d'une classe. En attendant une gestion simple simple de la 'reflexion', on peut écrire quelque chose comme :

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
31
32
33
34
35
36
37
class Inconnue {
public:
	int mbr1;
protected:
	int mbr2;
private:
	int mbr3;
};
 
#define TEST(mbr) \
template<class TEST> struct check_parameter_##mbr {\
	template<typename T> static auto fctpub(int)    \
		-> decltype(std::declval<T>().mbr)*;         \
	template<typename T> static char fctpub(...);   \
	struct Herit : public TEST {                    \
		using TEST::TEST;                            \
		template<typename T>static auto fctpro(int)  \
			-> decltype(this->mbr)*;                  \
		template<typename T>static char fctpro(...); \
	};                                              \
	                                                \
	enum E {UnknownOrPrivate=0, Protected, Public}; \
	static const E access = static_cast<E>(         \
			  (sizeof( fctpub<TEST>( 0 ) ) > 1)       \
			+ (sizeof( Herit::fctpro<TEST>(0) )>1)    \
		);                                           \
}
TEST( mbr1 );   // test du membre Inconnue::mbr1
constexpr int  b1acc = check_parameter_mbr1<Inconnue>::access;  // => 2
TEST( mbr2 );   // test du membre Inconnue::mbr2
constexpr int  b2acc = check_parameter_mbr2<Inconnue>::access;  // => 1
TEST( mbr3 );   // test du membre Inconnue::mbr3
constexpr int  b3acc = check_parameter_mbr3<Inconnue>::access;  // => 0
 
// et on décide de ne pas compiler si l'accès n'est pas conforme
static_assert( b1acc!=1 && b2acc!=1 && b3acc!=1,
	"idiotisme : au moins un des 3 membres de 'Inconnue' est 'protected'");

[bxdfr]

Merci pour votre réponse que je vais l’empressé de tester.
Vous dites:

mais une chose sure : des attributs membres protected ça n'a pas de sens.

Alors une question me turlupine, pourquoi tous les cours que j'ai suivis et que je vois actuellement en ligne, provenant d'université ou d'institut de recherche, mettent toujours les membres des classes mères en protected pour parler de l'héritage ?
Après, dans la pratique, quand on regarde le code source de bibliothèque C++, comme Qt par exemple, ils appliquent effectivement le principe énoncé, à savoir les attributs sont "private" et les méthodes "protected"

[Bousk]

Donc la réponse est juste NON, on ne peut pas, par programmation, connaître la visibilité d'un attribut ou d'une méthode.

Bah tu essayes d'accéder à ton truc, et si c'est impossible, la compilation va échouer.

Si c'est pour de la métaprog, il y a des astuces pour savoir si un membre existe ou non.