Salut,
Quelle est la manière la plus élégante pour permettre l'accès aux donnés membres privée de la mère à une classe dérivée fille ? Pour l'instant j'utilise le fait que j'ai défini la fille comme amie de la mère, peut être y a-t-il un meilleur moyen ?
 
sinon, le constructeur de la fille est le même que celui de la mère, donc dans le constructeur de la fille je me contente d'un simple appel au constructeur de la mère. c nul ? y a mieux ?
 
merci
   ANT

Soit tu passes tes donnees en protected, soit tu laisses en private et tu fais des accesseurs protected

 
ça searit mieux que
friend class fille ?

 
Ben, c'est un peu a ca que ca sert, protected

ok merci je vais voir donc du côté de protected :-)

simple petite question :
 
qu'est ce qu'un accesseur ?
 

 
ca ?

oui.
 
perso, j'aime mieu la notion d'attribut qu'on a en C#, mais je sais pas si elle s'implémente de la même façon en C++.
 

 
Comme ça, c'est visible comme un attribut, (monObj.myVal = 3 et tu peux associer du code à l'affectation et à la lecture de la valeur. Ainsi que bloquer la lecture ou écriture en te contenant de ne pas l'indiquer.

oui, je connaissais la notation c#, il me semble pas qu'elle s'applique en c++ (d'ailleurs en c++ managé on ecrit get_myVal et set_myVal je crois), mais j'ignorais qu'on appelait ca un accesseur
 
sinon, je vois comme interet de cette méthode une plus grande sécurité d'accès au données possible, existe-t-il d'autres avantages/inconvénients ?

Bah y'a aussi la validation des données lors de la lecture/écriture.
 
Mettons que tu stockes dans ton objet un mot de pass.
Pour des raisons de performances, le mot de pass doit être stocké dans l'objet en clair, mais pour des raisons de sécurité, il doit être en crypté dans le code du programme principal.
 
A ce moment, tu vas pouvoir mettre dans tes accesseurs l'envryption et la décryption du mot de pass.
 
De la même façon, mettons que tu veuilles respecter un standard de complexité du mot de passe. Par exemple, il faut qu'il fasse plus de 13 caractères, et qu'il contienne au moins 10% de caractères ascii étendus, et à la fois des caractères alpha et numéririques pour le reste. dans ton accesseur "set", tu pourras effectuer la validation, et lever une exception si le mot de pass n'est pas assez complexe.
 
Ou alors, tu as un objet "division".
 
Avec dividante et diviseur comme attributs.
 
Ton accesseur du diviseur devra contrôler que l'ont ne met jamais 0 dedans.
 
En fait, ça garantis la sécurité d'accès aux données, mais aussi l'intégrité.

bien, merci

Après avoir bossé sur un gros projet en Delphi, je ne suis pas un gros fan de ces trucs. Mais peut-être que C# fait ça mieux que Delphi aussi
 
Par exemple, est-ce qu'une propriété en lecture-ecriture peut-être considérée comme une lvalue ?
 
Si ce n'est pas le cas, l'interet principal de ce mecanisme tombe à l'eau ( pouvoir mettre de la validation sur les accès à un attibut sans avoir à changer le code client ). À ce compte là, autant forcer l'utilisation d'accesseurs dès le debut car au moins le client sait exactement à quoi s'en tenir.

 
absolument
(j'ai peur de pas bien comprendre quand meme, ca me parait evident (ceci dit je connais pas delphi donc bon)

 
Il y a une difference entre affectable et lvalue en fait. Peut-être que le terme lvalue n'est pas le bon. Peut on passer un attribut en paramètre à une fonction qui attend une reference ? Peut on prendre l'addresse d'un attribut ?

 
c'est la ma foi une excellent question (sauf pour l'histoire d'adresse qui n'a pas de sens en c#), j'essayerais a l'occas
 
edit : a la reflexion, je pense que c'est pas la peine d'essayer, quand tu va donner la proprio a ta fonction ca va faire un get et schluss

la différence va au delà de la l-value et de l'affectation. en C les tableaux ne sont pas des l-value, ce qui implique l'impossibilité de réaliser une affectation. en C++, outre cette contrainte, on ne peut pas construire un tableau à partir d'un autre (constructeur de recopie)