Discussion :

[kiroukou]

Bonjour,
Voila je continue à lire des choses sur le C++ et je suis de plus en plus surpris par le nombre de possibilitées qu'il offre. Il y a de quoi s'y perdre lol

Le dernier truc qui me perturbe, ce sont les classes amies. Je pense en avoir compris le fonctionnement, mais pas vraiment leurs utilités !

Cela va à l'encontre du principe d'encapsulation non ? Cela revient a faire de la composition mais avec en plus l'accés aux variables de classes privées et protégées. Mais pourquoi ne pas passer par le l'héritage?

Je suppose que cela doit être très utile, mais j'aimerai avoir votre point de vue fort de votre expérience.

C'est décidé, ce week end , je m'achete un livre pour arreter de poser des questions toutes les 3 mins

Merci encore
++

[dok3]

http://c.developpez.com/faq/cpp/?page=friend

[Aurelien.Regat-Barrel]

Oui friend est la plupart du temps une mauvaise idée. J'ai entendu dire que c'est apparu à un stade où C++ n'était pas très développé côté héritage et tout ça et friend serait à se débrouiller faute de mieux.

[kiroukou]

MErci dok3 mais j'avais déja jeter un oeil sur cette page. Elle ne repondait pas completement à ma question

Merci Aurelien de me confirmer ce que je pensais Moi cela me dérange car j'ai l'impression qu'en utilisant les fonction amies je m'éloigne d'une architecture Orientée Objet. Cela n'est pas forcement juste certainement, mais ma vision est trop restreinte encore.

Auriez vous un autre exemple d'une bonne utilisation de friend en dehors de celle de la FAQ ?

En vous remerciant
++

[dok3]

dans les articles de loulou, la partie singleton utilise un friend
http://loulou.developpez.com/tutorie.../partie1/#L3.4

[Aurelien.Regat-Barrel]

Dans la STL avec les inner class (classes déclarées à l'intérieur d'autres classes) comme iterator, etc...
Je l'utilise de temps en temps pour écrire des programmes de test (tu peux aussi rendre une fonction amie). Le programme de test a ainsi accès à la structure interne de la classe pour vérifier des pre/post conditions, ou autre...

[kiroukou]

Merci dok3 pour ce lien Il risque d'ailleurs d'occasionner (encore!) une nouvelle question Il y a quelque chose qui m'échappe dans l' implémentation du Sigleton en C++.

Ha oui exact Aurelien , cela peut être très bien pour tester une classe en effet ! Pour les inner class je regarderai ça dans pas très longtemps, lorsque je vais devoir m'interesser à la std.

Merci encore à vous
++
kiroukou

[Luc Hermitte]

Dans le désordre.

Il n'y a pas une implémentation du singleton en C++. Celle de Loulou, si je comprends bien, se rapproche de celle de ACE où l'on hérite de façon "curieusement récurrente" d'une classe générique singleton<T> dont on se doit d'étre ami.
Perso j'aime assez peu cette façon de procéder qui est un viol délibéré de l'encapsulation pour la seule raison que "singleton" est voulu comme une contrainte. Qui plus est, c'est verbeux dans le sens où deux choses doivent être faites pour définir un singleton : dériver d'un type bien précis et s'en déclarer ami.

A la limite, je préfère l'approche plus pragmatique qu'Andrei Alexandrescu expose dans Modern C++ Design. "singleton" n'est plus une contrainte sur la classe, mais une facilité qui permet d'avoir un objet global (oui, oui "global"!) dont on peut gérer la durée de vie, les dépendances aux autres globaux, et voire même les accès concurrentiels. Si vous regardez le code de Loki (ou achetez le bouquin), vous verrez que l'on définit un type singletonisé à partir d'un type normal -- les deux peuvent alors cohabiter.


Pour l'amitié, je rejoins assez la prose de Marshall C. Cline. D'autant que le C++ n'est pas que "Orienté Objet". C'est s'imposer des oeillières bien contraignantes. Herb Sutter parle dans Exceptional C++ (une version pré-impression doit être dispo sur GOTW) des interfaces étendues des objets. Si on prend le problème dans le sens, non pas des données stockées (soit l'encapsulation), mais celui des services proposés (abstraction), l'amitié n'est alors rien de plus qu'une facilité qui permet de mettre en oeuvre les fonctions de l'interface étendue d'une classe qui ne sont pas des fonctions membres de cette classe.

Par exemple, des classes en rapport avec l'algèbre et plus particulièrement ce qui touche au calcul matriciel. Les opérations de multiplications entre vecteurs et matrices n'appartiennent à aucune des deux classes plus qu'à l'autre. Elles font parti des interfaces publiques étendues des deux.
L'amitié permet ici d'améliorer l'efficacité des calculs -- l'opérateur [] des matrices renvoyant par valeur un proxy de type vecteur.
Est-ce choquant ? Pas (plus) en ce qui me concerne. Ces opérations sont dans l'interface publique des deux. Et c'est ça qui compte pour moi. Pas les données qui sont cachées.

Parce que sinon, une classe C qui implémente deux rôles RA() à destination de la classe A et RB() à destination B, pourquoi est-ce que B pourrait appeler RA() et vice-versa ?

[Aurelien.Regat-Barrel]

J'ai quand même l'impression que souvent friend c'est dans un but de performance que c'est utilisé, et qu'on préfère casser l'encapsulation et augmenter le couplage pour gagner en perf, enfin, en théorie.

[JolyLoic]

Je ne vois pas en quoi ajouter une déclaration friend pour une fonction externe casserait plus l'encapsulation qu'ajouter une fonction publique à la classe.

Dans les deux cas, on indique bien au niveau de la classe la liste des fonctions appelables par l'utilisateur et ayant accès à l'interface privée de la classe.

A moins que tu considères qu'ajouter une fonction publique est aussi une brisure d'encapsulation, et que l'on drevrait implémenter l'essentiel de l'interface d'une classe par des fonctions libres faisant appel à un jeu ultra minimaliste de fonctions membre (c'est un peu le point de vue que défend Scott Meyer dans quelques articles).

[kiroukou]

SAlut,
Merci à tous pour ce petit débat qui m'aide grandement a comprendre l'utilité de friend au travers de vos differents points de vue. 8)

JolyLoic > Je ne pense pas que cela soit la même chose quand même. Une Méthode publique appartient à la definition de ta classe et à toute celle qui en dérivent. Une classe amie n'appartient pas aux classes filles de ta classe (il me semble hein!), et de ce fait l'interface n'est plus identique . Et le fait que la classe soit dependante d'une fonction externe, qui pourrai elle même être modifiée par d'autres programmeurs (dans un gros projet), met un peu en péril la stabilité et la fiabilité de l'appliquation (à mon avis toujours). Moi pour faire l'équivalent je prefererai utiliser l'héritage (et c'est pour ça que j'ai poser cette question)

Maintenant comme le dit Luc Hermitte avec son exemple de matrices, il peut apparaitre que cela soit interessant , même si j'ai quand même du mal à le comprendre pour le moment , va falloir programmer pour voir

Comme je le dis plus haut, je compte m'acheter un bon bouquin. Je recherche un livre où je pourrai toucher le genre de problème que l'on evoque ici, et qui explique efficacement le moyen de creer des appliquations en C++. SUr ce site jj'ai regarder : Le langage C++ Fr de Bjarne Stroustrup semble bien mais complexe , et C / c++ bible programmeur semble sympas aussi.

Lequel pourriez vous me conseiller? (d'autres suggestions sont les bienvenues)

Merci à vous
Kiroukou

[JolyLoic]

Entre les deux cités, le premier sans hésitation (uniquement la version relue par M. Michaud, les traductions précédentes ont trop d'erreurs).

Autrement, pour des livres plus orientés conseils d'utilisation, il y a les Meyers ([more]effective C++), qui ont je crois été traduits (je ne lis jamais les traduction, trop de mauvaises surprises). Ou encore les Sutters ([more] exceptionnal C++).

Les Meyers sont plus sur la POO classique en C++, est sont parfois légèrement démodés, mais sont toujours indispensables AMA. Les Sutters sont plus orientés C++ moderne (exceptions, template...). On peut trouver une version préléminaire de ces derniers sur http://www.gotw.ca/gotw/index.htm

Il y a plein d'autre livres, mais ces derniers me semblent assez "indispensables"

[kiroukou]

Merci beaucoup
Je pense que les Meyers peuvent être une bonne solution pour moi, car avant d'atteindre les outils modernes du C++ je vais devoir en comprendre la base Je vais devoir réaliser une assez grosse application (désolé pour les fautes ci dessus ) et avoir un livre me donnant une marche à suivre m'aidera à arriver au bout dans le delai imposé.

Le livre de Bjarne Stroustrup semble très complet, mais assez lourd à lire. Vous en pensez quoi ? (je vais fair eune petite recherche car cela à deja du etre abordé comme sujet)

Malheureusement je ne me sens pas de prendre un livre en anglais encore, j'ai un peut peur que bloquer sur des mots me rebute au bout d'un moment.

Je vais aller jeter un oeil demain en ville, et je vous dirai sur qui j'ai craqué

++

[JolyLoic]

JolyLoic > Je ne pense pas que cela soit la même chose quand même. Une Méthode publique appartient à la definition de ta classe et à toute celle qui en dérivent. Une classe amie n'appartient pas aux classes filles de ta classe (il me semble hein!), et de ce fait l'interface n'est plus identique

Je ne suis pas certain de ce que tu veux dire... Le code suivant compile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
class A
{
	friend void f(A &a);
	int i;
};
 
class B : public A
{
};
 
void f(A& a)
{
	a.i = 42;
}
 
int main()
{
	A a;
	f(a);
	B b;
	f(b);
}

Et le fait que la classe soit dependante d'une fonction externe, qui pourrai elle même être modifiée par d'autres programmeurs (dans un gros projet), met un peu en péril la stabilité et la fiabilité de l'appliquation (à mon avis toujours).

Si tel était le cas, effectivement, il y aurait problème. Mais pour parer ça, on défini en général la fonction friend dans le même fichier que le reste de la classe, comme ça, si un individu "mal intentionné" (*) veut forcer une classe dont il n'a pas le code source en écriture en redéfinissant la fonction, il a une double définition.

(*) De toute façon, les protection d'accès en C++ sont destinées à protèger contre les étourderies, pas contre une attaque en règle. Comme ils disent en anglais : protecting against Murphy vs. protecting against Machiavelli. Voir par exemple http://www.gotw.ca/gotw/076.htm pour plus d'info.

[kiroukou]

Oui une erreur de ma part Tu as raison.
En fait j'avais mal compris ceci (cf lien ci dessus vers faq) : "Je ne fais pas forcément confiance aux enfants de mes amis"
Bref je me suis mélangé , donc ma raison n'est pas valable

Et tu as aussi raison pour ce qui est du problème de modification de la fonction friend. Bref il m'apparais moins clairement maintenant le problème d'encapsulation.
Je commence à me faire à l'idée de cette possibilitée du C++

Merci encore pour ce "débat".
++