Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Alexandre
bonjour,
"giova" a écrit dans le message de news:40af0d30$0$21568$
désolé ma question est tres certainement stupide, en tout cas c'est sur, elle vient d'un debutant :)
Pour une classe dont on nous a fourni que le header et le module objet.
Qu'est ce qui nous empeche dans le header, de rajouter un "friend class maclasse" histoire de faire sauter l'encapsulation des données?
rien. Enfin AMA on ne peut pas s'en prémunir, si on fournit le .h C'est un (gros) défaut, certes. D'un autre coté, le code de la classe étant déjà compilé, pas sur que ça change qq chose. La classe risque d'être différente et le lieur raler. Je n'ai jamais fait l'essai. ça serait interessant.
bonjour,
"giova" <pas@de.mail> a écrit dans le message de
news:40af0d30$0$21568$626a14ce@news.free.fr...
désolé ma question est tres certainement stupide, en tout cas c'est sur,
elle vient d'un debutant :)
Pour une classe dont on nous a fourni que le header et le module objet.
Qu'est ce qui nous empeche dans le header, de rajouter un "friend class
maclasse"
histoire de faire sauter l'encapsulation des données?
rien. Enfin AMA on ne peut pas s'en prémunir, si on fournit le .h
C'est un (gros) défaut, certes. D'un autre coté, le code de la classe étant
déjà compilé, pas sur que ça change qq chose. La classe risque d'être
différente et le lieur raler. Je n'ai jamais fait l'essai. ça serait
interessant.
"giova" a écrit dans le message de news:40af0d30$0$21568$
désolé ma question est tres certainement stupide, en tout cas c'est sur, elle vient d'un debutant :)
Pour une classe dont on nous a fourni que le header et le module objet.
Qu'est ce qui nous empeche dans le header, de rajouter un "friend class maclasse" histoire de faire sauter l'encapsulation des données?
rien. Enfin AMA on ne peut pas s'en prémunir, si on fournit le .h C'est un (gros) défaut, certes. D'un autre coté, le code de la classe étant déjà compilé, pas sur que ça change qq chose. La classe risque d'être différente et le lieur raler. Je n'ai jamais fait l'essai. ça serait interessant.
Loïc Joly
giova wrote:
désolé ma question est tres certainement stupide, en tout cas c'est sur, elle vient d'un debutant :)
Pour une classe dont on nous a fourni que le header et le module objet.
Qu'est ce qui nous empeche dans le header, de rajouter un "friend class maclasse" histoire de faire sauter l'encapsulation des données?
Rien.
En thérorie, le compilateur a le droit de crasher. En pratique, ce genre de manip opourrait passer sans problèmes avec pas mal de compilo.
Il est souvent dit en C++ que le but des déclarations privées.... est de protèger contre l'innocent faisant une étourderie, pas contre Machiavel.
Si tu veux un peu plus de protection, tu as toujours la possibilité de faire :
// .h
class MaClasseImpl;
class MaClasse { public: MaClasse() int maFonctionPublique; private: MaClasseImpl *impl; };
// .cpp
class MaClasseImpl { public: int i; int j; int maFonctionPrivée(); };
-- Loïc
giova wrote:
désolé ma question est tres certainement stupide, en tout cas c'est sur,
elle vient d'un debutant :)
Pour une classe dont on nous a fourni que le header et le module objet.
Qu'est ce qui nous empeche dans le header, de rajouter un "friend class
maclasse"
histoire de faire sauter l'encapsulation des données?
Rien.
En thérorie, le compilateur a le droit de crasher. En pratique, ce genre
de manip opourrait passer sans problèmes avec pas mal de compilo.
Il est souvent dit en C++ que le but des déclarations privées.... est de
protèger contre l'innocent faisant une étourderie, pas contre Machiavel.
Si tu veux un peu plus de protection, tu as toujours la possibilité de
faire :
// .h
class MaClasseImpl;
class MaClasse
{
public:
MaClasse()
int maFonctionPublique;
private:
MaClasseImpl *impl;
};
// .cpp
class MaClasseImpl
{
public:
int i;
int j;
int maFonctionPrivée();
};
désolé ma question est tres certainement stupide, en tout cas c'est sur, elle vient d'un debutant :)
Pour une classe dont on nous a fourni que le header et le module objet.
Qu'est ce qui nous empeche dans le header, de rajouter un "friend class maclasse" histoire de faire sauter l'encapsulation des données?
Rien.
En thérorie, le compilateur a le droit de crasher. En pratique, ce genre de manip opourrait passer sans problèmes avec pas mal de compilo.
Il est souvent dit en C++ que le but des déclarations privées.... est de protèger contre l'innocent faisant une étourderie, pas contre Machiavel.
Si tu veux un peu plus de protection, tu as toujours la possibilité de faire :
// .h
class MaClasseImpl;
class MaClasse { public: MaClasse() int maFonctionPublique; private: MaClasseImpl *impl; };
// .cpp
class MaClasseImpl { public: int i; int j; int maFonctionPrivée(); };
-- Loïc
kanze
giova wrote in message news:<40af0d30$0$21568$...
désolé ma question est tres certainement stupide, en tout cas c'est sur, elle vient d'un debutant :)
Pour une classe dont on nous a fourni que le header et le module objet.
Qu'est ce qui nous empeche dans le header, de rajouter un "friend class maclasse" histoire de faire sauter l'encapsulation des données?
Officiellement, si tu fais ça, tu as une violation de la ODR (qui dit que toutes les définitions doivent être identiques), et donc un comportement indéfini.
En principe, si tu avais un bon compilateur, il réfusera le code au moment de l'édition de liens, parce que les violations de la ODR sont assez facile à détecter (à condition d'accepter qu'il y aurait certaines qui passent à travers).
Dans la pratique, de bons compilateurs sont rares, et c'est probable que rien ne l'empêche. Et alors... Les protections du C++ sont conçues pour protéger contre Murphy, et non contre Machiavelli. Quelque chose du genre :
#define class struct #define private public
avant l'inclusion de l'en-tête marcherait probablement aussi. Même si tu n'as pas accès en écriture à l'en-tête. (Là aussi, formellement, tu as introduit un comportement indéfini. Mais dans la pratique, ça marche avec tous les compilateurs que je connais.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
giova <pas@de.mail> wrote in message
news:<40af0d30$0$21568$626a14ce@news.free.fr>...
désolé ma question est tres certainement stupide, en tout cas c'est
sur, elle vient d'un debutant :)
Pour une classe dont on nous a fourni que le header et le module
objet.
Qu'est ce qui nous empeche dans le header, de rajouter un "friend
class maclasse" histoire de faire sauter l'encapsulation des données?
Officiellement, si tu fais ça, tu as une violation de la ODR (qui dit
que toutes les définitions doivent être identiques), et donc un
comportement indéfini.
En principe, si tu avais un bon compilateur, il réfusera le code au
moment de l'édition de liens, parce que les violations de la ODR sont
assez facile à détecter (à condition d'accepter qu'il y aurait certaines
qui passent à travers).
Dans la pratique, de bons compilateurs sont rares, et c'est probable que
rien ne l'empêche. Et alors... Les protections du C++ sont conçues pour
protéger contre Murphy, et non contre Machiavelli. Quelque chose du
genre :
#define class struct
#define private public
avant l'inclusion de l'en-tête marcherait probablement aussi. Même si tu
n'as pas accès en écriture à l'en-tête. (Là aussi, formellement, tu as
introduit un comportement indéfini. Mais dans la pratique, ça marche
avec tous les compilateurs que je connais.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
désolé ma question est tres certainement stupide, en tout cas c'est sur, elle vient d'un debutant :)
Pour une classe dont on nous a fourni que le header et le module objet.
Qu'est ce qui nous empeche dans le header, de rajouter un "friend class maclasse" histoire de faire sauter l'encapsulation des données?
Officiellement, si tu fais ça, tu as une violation de la ODR (qui dit que toutes les définitions doivent être identiques), et donc un comportement indéfini.
En principe, si tu avais un bon compilateur, il réfusera le code au moment de l'édition de liens, parce que les violations de la ODR sont assez facile à détecter (à condition d'accepter qu'il y aurait certaines qui passent à travers).
Dans la pratique, de bons compilateurs sont rares, et c'est probable que rien ne l'empêche. Et alors... Les protections du C++ sont conçues pour protéger contre Murphy, et non contre Machiavelli. Quelque chose du genre :
#define class struct #define private public
avant l'inclusion de l'en-tête marcherait probablement aussi. Même si tu n'as pas accès en écriture à l'en-tête. (Là aussi, formellement, tu as introduit un comportement indéfini. Mais dans la pratique, ça marche avec tous les compilateurs que je connais.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
