Erreurs, bugs, questions - page 1056

[Koldun Zloy]

MetaDriver:

1. L'ajout d'une partie privée ne changera rien dans le cas de

Dans le cas de l'héritage, ce sera le cas, c'est clair.

2. Quelques éléments seront nécessaires... Les motifs ne sont disponibles que dans le cas de l'accès à sa propre copie.

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

4. C'est là toute la question : qu'est-ce qui est considéré comme un "fonctionnement correct" ?

1. Si vous voulez vraiment cacher votre portefeuille, pourquoi faire gch() ?

2. et lors de la copie des instances, y en a-t-il ?

[Vladimir Gomonov]

Zloy_Koldun:

1. Si vous voulez vraiment cacher votre portefeuille, pourquoi utiliser la fonction gh() ?

2. et quand les instances de copie sont-elles disponibles ?

Lisez mon post précédent. Toutes les réponses sont là.

Il fut un temps où c'était une "décision politique" de considérer les autres objets (instances) de votre propre classe comme des amis par "défaut" - purement pour économiser le bukaf. Et maintenant, vous considérez cette exception comme une norme de vie et vous voulez grimper sans entrave dans les poches privées de tous les parents éloignés.

Huh...

[Mykola Demko]

MetaDriver:

1. L'ajout d'une partie privée ne changera rien dans le cas de

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

Dans le cas de l'héritage, ce sera le cas, c'est clair.

2. Quelques éléments seront nécessaires... uniquement dans le cas de l'accès à sa propre copie.

3. Qu'il en soit décidé ainsi. correct. ;)

4. C'est là toute la question : qu'est-ce qui doit être considéré comme un "travail correct" ?

Oui, ça marche, mais ça ne devrait pas. D'ailleurs, lors de l'autocomplétion dans ME (lors de l'écriture d'un ch), on ne vous donne pas la variable "wallet" car elle est en privé, donc cette fonctionnalité est probablement passée inaperçue pendant si longtemps.

[Koldun Zloy]

class Человек
{
private:
   int кошелёк; 
public:
   void Человек() {  кошелёк=3; }
   void gч( Человек& ч )  
   { 
    ч.кошелёк--;   // Работает и должно работать!
   }
   void gcч( const Человек& ч )  
   { 
    ч.кошелёк--;   // Не работает, как и должно.
   }
};

[Vladimir Gomonov]

Zloy_Koldun:

Ok. Alors dis-moi. Comment définir un tel champ dans une classe, qu'il puisse être modifié uniquement et exclusivement par les méthodes de l'instance "master" et personne d'autre.

Si c'est impossible, alors le sujet des seins d' encapsulation n'a probablement pas été abordé dans la langue, non ?

[Koldun Zloy]

MetaDriver:

Ok. Alors dis-moi. Comment définir un tel champ dans une classe, qu'il puisse être modifié uniquement et exclusivement par les méthodes de l'instance "master" et personne d'autre.

Si c'est impossible, alors le sujet des nichons d' encapsulation n'est pas couvert par la langue, n'est-ce pas ?

C'est impossible. Et ça n'a pas besoin de l'être. Si vous n'êtes pas d'accord, donnez un exemple concret.

[Server Muradasilov]

Que signifie cette erreur, l'ordre en attente n'a pas été déclenché : "HistoryBase : 114 erreurs dans 'GBPUSD60'.

[Vasiliy Sokolov]

MetaDriver:

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

Cette caractéristique a été désagréablement surprenante. C'est définitivement une connerie si le compilateur permet de changer le champ privé de l'instance d'un autre. Il devrait être posté sur Servicedesk.

[Koldun Zloy]

C-4:
Cette caractéristique est désagréablement surprenante. C'est évidemment une connerie si votre compilateur vous permet de changer le champ privé de l'instance de quelqu'un d'autre. Il devrait être posté sur Servicedesk.

Je ne comprends pas : pourquoi voulez-vous vous limiter à ce point ?

Pensez-vous que cela rendra automatiquement votre programme plus sûr ?

Il ne le fera pas ! Au contraire.

Ce sont des restrictions inutiles qui vous pousseront à l'écrire de cette façon un jour :

static int Мой_Кошелёк; // Бери, все, кто хочет.

[Vasiliy Sokolov]

Zloy_Koldun:

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.

Justement, si ce cas très différent se présente à vous, cela signifie que votre architecture est conceptuellement erronée et potentiellement dangereuse.

En C++, le concept de classes dites amicales a été introduit à un moment donné de manière malencontreuse. C'est comme si une classe savait comment une autre classe est organisée, elle peut travailler en toute sécurité avec ses données internes. La pratique de son utilisation par des milliers de programmeurs dans le monde a montré qu'il s'agit d'une chose dangereuse, qui crée plus de problèmes qu'elle n'en résout, aussi est-il abandonné dans les langages modernes comme Java et C#.