Erreurs, bugs, questions - page 1055

[Koldun Zloy]

A100:
Il n'y a pas de contradiction ici, sinon B aurait accès à C.t comme indiqué ci-dessous, alors que B n'est pas dérivé de C

Dans votre exemple, B devrait avoir accès à C.t et je ne vois aucune raison de l'interdire.

[Vladimir Gomonov]

Zloy_Koldun:
Dans votre exemple, B devrait avoir accès à C.t et je ne vois aucune raison de l'interdire.

Vous êtes tous les deux bizarres. Vous confondez classes et instances. Je ne pense pas qu'une autre instance de la même classe B devrait avoir accès à t non plus.

Les champs protégés ne doivent être accessibles que par sa propre instance (de la même instance B, c'est-à-dire celle-ci), et les autres instances (même de la même classe B) doivent être fermées... Permettez-moi de le renommer pour plus de clarté :

class Человек
{
protected:
   int кошелёк;
};
class Мужчина : public Человек
{
   int fч( Человек& ч );
   int fм( Мужчина& м );
};
int Мужчина::fч( Человек& ч )  // 1
{
   кошелёк = 100;       // Всё в порядке.  моё.
   int s =  ч.кошелёк;   // protected member access error  вполне справедливо
   return s;
}
int Мужчина::fм( Мужчина& м )  // 2
{
   кошелёк = 100;       // Всё в порядке, кошелёк мой собственный
   int s = м.кошелёк;   // это компилируется.  и это НЕПРАВИЛЬНО! кошелёк ЧУЖОЙ !!
// С фига ли я должен иметь доступ к твоему кошельку, только на основании того что мы с тобой оба "Мужчины" ?? 
   return s;
}

Pour moi, les deux fonctions ne devraient pas compiler, pas seulement la première. Si en C++ la seconde compile et fonctionne, alors c'est une perforation du C++, pas une vertu.

En bref :

class Человек
{
protected:
   int кошелёк;
public:
   void Человек() {  a=3; }
   void gч( Человек& ч )
   {
    ч.кошелёк--;  // Даже это не должно компилироваться.  не следует лазить в чужой кошелёк!
    кошелёк++;    // в свой можно
   }   
};

[Koldun Zloy]

Votre comparaison avec le portefeuille est incorrecte.

Je peux vous donner un exemple où vous avez besoin d'accéder à des membres protégés, mais il ne s'agit pas de mes ou de vos préférences.

Si le programmeur veut interdire quelque chose, il peut le faire lui-même et le compilateur doit l'interdire,

s'il est susceptible d'interférer avec le programme.

Dans l'exemple ci-dessus, la classe B connaît la classe A, et ne risque donc pas d'y faire des dégâts.

Et si vous voulez l'interdire, mettez-le dans la section Privé, ou n'héritez pas d'une classe, ou pensez à un millier d'autres façons.

[A100]

MetaDriver:

Si, en C++, la deuxième fonction compile et fonctionne, c'est un défaut du C++, pas une vertu.

Alors votre portefeuille ne serait pas accessible non plus.

Человек ч;
ч.gч( ч );

[Vladimir Gomonov]

A100:
Alors son portefeuille ne serait pas accessible non plus

Encore une fois : distinguer soigneusement les classes (types) et les instances (variables). Les champs propres (ce) surveillés sont librement accessibles, également par héritage (contrairement à private), les autres (autres variables de la même classe) ne doivent pas être accessibles. (devrait être inaccessible)

Zloy_Koldun:
.....

Dans l'exemple ci-dessus, la classe B connaît la classe A, et ne risque donc pas d'y faire des dégâts.

...............

Le simple fait que je sache que vous avez un portefeuille n'est pas une raison pour y accéder. Au vôtre, s'il vous plaît, uniquement par le biais de get() et set() - si vous l'autorisez (public : int get() ; int set() ;).

[A100]

MetaDriver:

protected ne restreint pas l'accès au niveau de l'objet, mais au niveau de la classe, car il ne dispose pas d'informations sur l'objet au moment de la compilation. J'ai donné un exemple de contradiction

Человек ч;
ч.gч( ч );

l'objet est le même

[Koldun Zloy]

MetaDriver:

Ce n'est pas parce que je sais que vous avez un portefeuille que je peux y accéder. Au vôtre - s'il vous plaît. Au vôtre - seulement par le biais de get() et set() - si vous le permettez (public : int get() ; int set() ;).

Le portefeuille n'est qu'un cas particulier. Et personne n'empêche qu'il soit placé dans la partie privée.

Dans un autre cas, vous pouvez avoir besoin d'accéder à la variable de la classe parente de l'objet d'une autre personne.

Et c'est au programmeur de décider de l'autoriser ou non. Et le compilateur doit s'assurer que le programme fonctionne correctement.

[Vladimir Gomonov]

A100:
J'ai donné un exemple de contradiction ... l'objet est le même.

Il n'y a pas de contradiction. Si vous vous référez à vous-même par le biais d'une "interface externe", préparez-vous à être frappé au visage par vous-même ;)

..........., car au moment de la compilation, il ne dispose d'aucune information sur les objets.

[Vladimir Gomonov]

Zloy_Koldun:

1. Le portefeuille n'est qu'un cas particulier. Et personne n'empêche qu'il soit placé dans la partie privée.

2. Dans un autre cas, vous pouvez avoir besoin d'accéder à la variable de la classe parente de l'objet d'une autre personne.

3 Et c'est au programmeur de décider de l'autoriser ou non.

4. et c'est au compilateur de s'assurer que le programme fonctionne correctement.

1. Le mettre dans la partie privée ne changera rien en cas de

class Человек
{
private:
   int кошелёк; 
public:
   void Человек() {  кошелёк=3; }
   void gч( Человек& ч )  
   { 
    ч.кошелёк--;   // сейчас работает.  а не должно ;)
   }
};

Il héritera, c'est évident.

2. Il y a très peu de choses qui devront être faites. Les motifs ne sont disponibles que lorsque vous accédez à votre propre copie.

3. alors laissez-le décider. correct. ;)

4. C'est toute la question : qu'est-ce qui compte exactement comme "travail correct".

[Vladimir Gomonov]

Je peux moi-même trouver une justification à la situation actuelle : la séparation stricte de la "propriété" entre les instances d'une même classe pourrait conduire à une syntaxe encombrée lors de la description de toutes sortes d'opérations binaires (même au même niveau hiérarchique). Toutefois, en cas d'héritage, il faut certainement rogner sur l'"accès direct".

Parce qu'il n'y a aucun intérêt à le faire... ;)