Erreurs, bugs, questions - page 1055
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
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.
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é :
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 :
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.
Si, en C++, la deuxième fonction compile et fonctionne, c'est un défaut du C++, pas une vertu.
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)
.....
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() ;).
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.
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.
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
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".
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... ;)