Penser en C++

Dans toute relation il est important d'avoir des limites respectées par toutes les parties concernées. Quand vous créez une bibliothèque, vous établissez une relation avec le programmeur clientqui utilise la bibliothèque pour construire une application ou une autre bibliothèque.

Dans un structC, comme avec la plupart des choses en C, il n'y a pas de règles. Les programmeurs clients peuvent faire ce qu'ils veulent avec la structure, et il n'y a aucune façon de forcer un comportement particulier. Par exemple, bien que vous ayez vu dans le dernier chapitre l'importance des fonctions appelées initialize( )et cleanup( ), le programmeur client à la possibilité de ne pas appeler ces fonctions. (nous verrons une meilleure approche dans le prochain chapitre.) Et bien que vous préfèreriez vraiment que le programmeur client ne manipule pas directement certains membres de votre structure, en C il n'y aucun moyen de s'en prémunir. Tout est nu en ce monde.

Il y a deux raisons pour contrôler l'accès aux membres. La première est d'empêcher le programmeur client d'accéder à des outils auxquels il ne devrait pas toucher, des outils qui sont nécessaires pour les processus internes du type de données, mais pas de la partie de l'interface dont le programmeur client a besoin pour résoudre son problème particulier. C'est réellement un service rendu aux programmeurs clients parce qu'ils peuvent facilement voir ce qui est important pour eux et ce qu'ils peuvent ignorer.

La deuxième raison du contrôle d'accès est de permettre au concepteur de bibliothèque de changer les fonctionnements internes de la structure sans s'inquiéter de la façon dont cela affectera le programmeur client. Dans l'exemple de la Stackdu dernier chapitre, vous pourriez vouloir assigner le stockage dans de grandes sections, pour la vitesse, plutôt que de créer un nouveau stockage chaque fois qu'un élément est ajouté. Si l'interface et l'exécution sont clairement séparées et protégées, vous pouvez accomplir ceci et exiger seulement un relink par le programmeur client.

Le C++ introduit trois nouveaux mots-clefs pour fixer les limites d'une structure : public, privateet protected. Leur sens et leur usage sont remarquablement clairs. Ces spécificateurs d'accèssont utilisés seulement dans la déclaration d'une structure, et ils changent les limites pour toutes les déclarations qui viennent après eux. Quand vous utilisez un tel spécificateur, il doit être suivi par deux points.

publicsignifie que tous les membres qui suivent cette déclaration sont disponibles à tout le monde. Les membres publicsont comme les membres d'un struct. Par exemple, les déclarations de structures suivantes sont équivalentes :

//: C05:Public.cpp
// Public est exactement comme une structure (struct) en C

struct A {
  int i;
  char j;
  float f;
  void func();
};

void A::func() {}

struct B {
public:
  int i;
  char j;
  float f;
  void func();
};

void B::func() {}  

int main() {
  A a; B b;
  a.i = b.i = 1;
  a.j = b.j = 'c';
  a.f = b.f = 3.14159;
  a.func();
  b.func();
} ///:~

Le mot-clef private, à l'inverse, signifie que personne ne peut accéder à ce membre sauf vous, le créateur de ce type, dans les fonctions membres de ce type. privateest une brique dans le mur entre vous et le programmeur client ; si quelqu'un essaye d'accéder à un membre private, ils obtiennent une erreur de compilation (compile-time error). Dans struct Bdans l'exemple ci-dessus, vous pourriez vouloir rendre des morceaux de la représentation (c'est-à-dire, des données membres) cachés, accessibles uniquement par vous :

//: C05:Private.cpp
// Fixer les limites

struct B {
private:
  char j;
  float f;
public:
  int i;
  void func();
};

void B::func() {
  i = 0;
  j = '0';
  f = 0.0;
};

int main() {
  B b;
  b.i = 1;    // OK, public
//!  b.j = '1';  // Illégal, private
//!  b.f = 1.0;  // Illégal, private
} ///:~

Bien que func( )puisse accéder à n'importe quel membre de B(car func( )est un membre de B, ce qui lui garantit automatiquement la permission), une fonction globale ordinaire comme main( )ne le peut pas. Bien sûr, un membre d'une autre structure ne le peut pas non plus. Seules, les fonctions qui sont clairement écrites dans la déclaration de la structure (le "contrat") peuvent accéder aux membres private.

Il n'y a pas d'ordre requis pour les spécificateurs d'accès, et ils peuvent apparaître plus d'une fois. Ils affectent tous les membres déclarés après eux et avant le spécificateur d'accès suivant.

5-2-1. protected▲

Que faire si vous voulez donner accès à une fonction qui n'est pas membre de la structure courante ? Ceci est accompli en déclarant cette fonction friend(amie) dansla déclaration de la structure. Il est important que la déclaration friendait lieu à l'intérieur de la déclaration de la structure parce que vous (ainsi que le compilateur) devez être capables de lire la déclaration de la structure et d'y voir toutes les règles concernant la taille et le comportement de ce type de données. Et une règle très importante dans toute relation est "qui peut accéder à mon implémentation privée ?"

La classe contrôle le code qui a accès à ses membres. Il n'y a pas de moyen magique de "forcer le passage" depuis l'extérieur si vous n'êtes pas friend; vous ne pouvez pas déclarer une nouvelle classe et dire "Salut, je suis friend(un ami, ndt) de Bob.

Vous pouvez déclarer une fonction globale friend, et vous pouvez également déclarer une fonction membre d'une autre structure, ou même une structure entière, en tant que friend. Voici un exemple :

//: C05:Friend.cpp
// Friend permet des accès spéciaux

// Déclaration (spécification du type incomplète ) :
struct X;

struct Y {
  void f(X*);
};

struct X { // Définition
private:
  int i;
public:
  void initialize();
  friend void g(X*, int); // friend global 
  friend void Y::f(X*);  // friend membre d'une structure 
  friend struct Z; // Structure entière comme friend
  friend void h();
};

void X::initialize() { 
  i = 0; 
}

void g(X* x, int i) { 
  x->i = i; 
}

void Y::f(X* x) { 
  x->i = 47; 
}

struct Z {
private:
  int j;
public:
  void initialize();
  void g(X* x);
};

void Z::initialize() { 
  j = 99;
}

void Z::g(X* x) { 
  x->i += j; 
}

void h() {
  X x;
  x.i = 100; // Manipulation directe des données
}

int main() {
  X x;
  Z z;
  z.g(&x);
} ///:~

struct Ya une fonction membre f( )qui modifiera un objet de type X. Cela ressemble à un casse-tête car le compilateur C++ exige que vous déclariez tout avant de pouvoir y faire référence, donc struct Ydoit être déclaré avant que son membre Y::f(X*)puisse être déclaré comme frienddans struct X. Mais pour déclarer Y::f(X*), struct Xdoit d'abord être déclaré !

Voici la solution. Remarquez que Y::f(X*)prend l' adressed'un objet X. C'est critique parce que le compilateur sait toujours comment passer une adresse, qui est d'une taille fixe quelque soit le type d'objet passé, même s'il n'a pas toutes les informations à propos de la taille du type concerné. Toutefois, si vous essayez de passer l'objet complet le compilateur doit voir la déclaration de la structure Xen intégralité, pour connaître sa taille et savoir comment le passer, avant qu'il ne vous permette de déclarer une fonction comme Y::g(X).

En passant l'adresse d'un X, le compilateur vous permet de faire une spécification de type incomplètede Xavant de déclarer Y::f(X*). Ceci est accompli par la déclaration :

struct X;

Cette déclaration dit simplement au compilateur qu'il existe une structure portant ce nom, et donc que c'est OK pour y faire référence tant que vous n'avez pas besoin de plus de détails que le nom.

A présent, dans struct X, la fonction Y::f(X*)peut être déclarée comme friendsans problème. Si vous aviez essayé de la déclarer avant que le compilateur eût vu la définition complète de Y, cela aurait généré une erreur. C'est une sécurité pour assurer la cohérence et éliminer les bugs.

Notez les deux autres fonctions friend. La première déclaration concerne une fonction globale ordinaire g( ). Mais g( )n'a pas été déclarée précédemment dans la portée générale ! Il s'avère que friendpeut être utilisé de cette manière pour simultanément déclarer la fonction etlui donner le statut friend. Ce comportement s'applique aux structures en intégralité :

friend struct Z;

est une spécification de type incomplète pour Z, et donne à toute la structure le statut friend.

5-3-1. Amis emboîtés▲

//: C05:NestFriend.cpp
// friends emboîtés
#include <iostream>
#include <cstring> // memset()
using namespace std;
const int sz = 20;

struct Holder {
private:
  int a[sz];
public:
  void initialize();
  struct Pointer;
  friend struct Pointer;
  struct Pointer {
  private:
    Holder* h;
    int* p;
  public:
    void initialize(Holder* h);
    // Se déplace dans le tableau:
    void next();
    void previous();
    void top();
    void end();
    // Accession à des valeurs:
    int read();
    void set(int i);
  };
};

void Holder::initialize() {
  memset(a, 0, sz * sizeof(int));
}

void Holder::Pointer::initialize(Holder* rv) {
  h = rv;
  p = rv->a;
}

void Holder::Pointer::next() {
  if(p < &(h->a[sz - 1])) p++;
}

void Holder::Pointer::previous() {
  if(p > &(h->a[0])) p--;
}

void Holder::Pointer::top() {
  p = &(h->a[0]);
}

void Holder::Pointer::end() {
  p = &(h->a[sz - 1]);
}

int Holder::Pointer::read() {
  return *p;
}

void Holder::Pointer::set(int i) {
  *p = i;
}

int main() {
  Holder h;
  Holder::Pointer hp, hp2;
  int i;

  h.initialize();
  hp.initialize(&h);
  hp2.initialize(&h);
  for(i = 0; i < sz; i++) {
    hp.set(i);
    hp.next();
  }
  hp.top();
  hp2.end();
  for(i = 0; i < sz; i++) {
    cout << "hp = " << hp.read()
         << ", hp2 = " << hp2.read() << endl;
    hp.next();
    hp2.previous();
  }
} ///:~

friend struct Pointer;

5-3-2. Est-ce pur ?▲

Le chapitre 4 affirmait qu'un structécrit pour un compilateur C puis compilé avec C++ resterait inchangé. Cette affirmation faisait principalement référence à l'organisation physique d'un struct, c'est-à-dire à l'emplacement mémoire individuel des variables au sein de la mémoire allouée pour l'objet. Si le compilateur C++ modifiait l'organisation des structs conçus en C, alors tout code C que vous auriez écrit et qui serait basé sur la connaissance de l'emplacement précis des variables dans un structcesserait de fonctionner.

Cependant, quand vous commencez à utiliser des spécificateurs d'accès, vous entrez de plein pied dans le royaume du C++, et les choses changent un peu. Dans un "bloc d'accès" particulier (un groupe de déclarations délimité par des spécificateurs d'accès), on a la garantie que les variables seront positionnées de manière contigües en mémoire, comme en C. Toutefois, les blocs d'accès peuvent ne pas apparaître au sein de l'objet dans l'ordre dans lequel vous les avez déclarés. Bien que le compilateur dispose en généralles blocs exactement comme vous les voyez, il n'y a pas de règles à ce sujet, car l'architecture d'une machine particulière et/ou d'un système pourrait avoir un support explicite des mots-clefs privateet protectedqui imposerait à ces blocs de se trouver dans des emplacements mémoires particuliers. Les spécifications du langage ne veulent pas priver une implémentation de ce type d'avantage.

Les spécificateurs d'accès font partie de la structure et n'affectent pas les objets créés à partir de la structure. Toutes les informations relatives aux spécifications d'accès disparaissent avant que le programme ne soit exécuté ; en général, ceci se produit au moment de la compilation. Lors de l'exécution, les objets deviennent des "espaces de stockage" et rien de plus. Si vous le voulez vraiment, vous pouvez enfreindre toutes les règles et accéder directement à la mémoire, comme en C. C++ n'est pas conçu pour vous éviter de faire des choses imprudentes. Il vous fournit simplement une alternative bien plus simple, et autrement plus souhaitable.

En général, ce n'est pas une bonne idée de dépendre de quelque chose de spécifique à l'implémentation quand vous écrivez un programme. Quand vous devez avoir de telles dépendances, encapsulez-les dans une structure de façon à ce que les changements nécessaires au portage soient concentrés en un même endroit.

Le contrôle d'accès est souvent appelé le masquage de l'implémentation. Inclure les fonctions dans les structures (souvent désigné par le terme encapsulation (36))produisent un type de données avec des caractéristiques et des comportements, mais le contrôle d'accès impose des limites à ce type de données, pour deux motifs importants. La première est d'établir ce que le programmeur client peut et ne peut pas utiliser. Vous pouver construire vos mécanismes internes dans la structure sans vous soucier que des programmeurs clients pensent à ces mécanismes qui font partie de l'interface qu'ils devront employer.

Ceci amène directement la deuxième raison, qui est de séparer l'interface de l'implémentation. Si la structure est employée dans un ensemble de programmes, mais que les programmeurs clients ne peuvent faire rien d'autre qu'envoyer des messages à l'interface publique, alors vous pouvez changer tout ce qui est privé sans exiger des modifications à leur code.

L'encapsulation et le contrôle d'accès, pris ensemble, créent quelque chose de plus que la structC. Nous sommes maintenant dans le monde de la programmation orientée-objet, où une structure décrit une classe d'objets comme vous pouvez décrire une classe de poissons ou une classe d'oiseaux : Tout objet appartenant à cette classe partagera ces caractéristiques et comportements. C'est ce qu'est devenue la déclaration de structure, une description de la façon dont tous les objets de ce type agiront et à quoi ils ressembleront.

Dans le langage POO d'origine, Simula-67, le mot-clé classétait utilisé pour décrire un nouveau type de données. Ceci a apparamment inspiré à Stroustrup de choisir le même mot-clé pour le C++, pour souligner que c'était le point focal de tout le langage : la création de nouveaux types de données qui sont plus que des structs C avec des fonctions. Cela semble être une justification adéquate pour un nouveau mot-clé.

Cependant, classest proche d'être un mot-clé inutile en C++. Il est identique au mot-clé structà tous les points de vue sauf un : les membres d'une classsont privatepar défaut, tandis que ceux d'une structsont public. Nous avons ici deux structures qui produisent le même résultat :

//: C05:Class.cpp
// Similarité entre une structure et une classe

struct A {
private:
  int i, j, k;
public:
  int f();
  void g();
};

int A::f() { 
  return i + j + k; 
}

void A::g() { 
  i = j = k = 0; 
}

// On obtient des résultats identiques avec :

class B {
  int i, j, k;
public:
  int f();
  void g();
};

int B::f() { 
  return i + j + k; 
}

void B::g() { 
  i = j = k = 0; 
} 

int main() {
  A a;
  B b;
  a.f(); a.g();
  b.f(); b.g();
} ///:~

La classe est le concept fondamental de la POO en C++. C'est un des mots-clés qui ne sera pasmis en gras dans ce livre – ça deviendrait fatigant avec un mot répété aussi souvent que “class.” Le changement avec les classes est si important que je suspecte que Stroustrup aurait préféré mettre définitivement aux clous la structure, mais le besoin de compatibilité ascendante avec le C ne permettait pas cela.

Beaucoup de personnes préfèrent un style de création de classe plutôt façon structque façon classe parce que vous surchargez le comportement privé par défaut de la classe en commençant par les éléments publics :

class X {
public:
  void interface_function();
private:
  void private_function();
  int internal_representation;
};

La logique sous-jacente est qu'il est plus sensé pour le lecteur de voir les membres qui ont le plus d'intérêt pour lui, ainsi il peut ignorer tout ce qui est privé. En effet, la seule raison pour laquelle tous les autres membres doivent être déclarés dans la classe est qu'ainsi le compilateur sait de quelle taille est l'objet et peut les allouer correctement, et ainsi peut garantir l'uniformité.

Les exemples de ce livre, cependant, mettront les membres privés en premier, comme ceci :

class X {
  void private_function();
  int internal_representation;
public:
  void interface_function();
};

Certains se donnent même la peine de décorer leurs propres noms privés :

class Y {
public:
  void f();
private:
  int mX;  // nom "décoré"
};

Comme mXest déjà caché dans la portée de Y, le m(pour “membre”) n'est pas nécessaire. Cependant dans les projets avec beaucoup de variables globales (quelque chose que vous devriez essayer d'éviter, mais qui est parfois inévitable dans des projets existants), il est utile de pouvoir distinguer dans une définition de fonction membre une donnée globale d'une donnée membre.

5-5-1. Modifier Stash pour employer le contrôle d'accès▲

//: C05:Stash.h
// Converti pour utiliser le contrôle d'accès
#ifndef STASH_H
#define STASH_H

class Stash {
  int size;      // Taille de chaque espace
  int quantity;  // Nombre d'espaces de stockage
  int next;      // Prochain espace vide
  // Tableaux d'octets alloués dynamiquement :
  unsigned char* storage;
  void inflate(int increase);
public:
  void initialize(int size);
  void cleanup();
  int add(void* element);
  void* fetch(int index);
  int count();
};
#endif // STASH_H ///:~

5-5-2. Modifier Stack pour employer le contrôle d'accès▲

//: C05:Stack2.h
// Structure imbriquée via une liste chaînée
#ifndef STACK2_H
#define STACK2_H

class Stack {
  struct Link {
    void* data;
    Link* next;
    void initialize(void* dat, Link* nxt);
  }* head;
public:
  void initialize();
  void push(void* dat);
  void* peek();
  void* pop();
  void cleanup();
};
#endif // STACK2_H ///:~

Les contrôles d'accès du C++ vous permettent de séparer l'interface de l'implémentation, mais la dissimulation de l'implémentation n'est que partielle. Le compilateur doit toujours voir les déclarations de toutes les parties d'un objet afin de le créer et de le manipuler correctement. Vous pourriez imaginer un langage de programmation qui requiert seulement l'interface publique d'un objet et autorise l'implémentation privée à être cachée, mais C++ effectue autant que possible la vérification des types de façon statique (au moment de la compilation). Ceci signifie que vous apprendrez aussi tôt que possible s'il y a une erreur, et que votre programme est plus efficace. Toutefois, inclure l'implémentation privée a deux effets : l'implémentation est visible même si vous ne pouvez réellement y accéder, et elle peut causer des recompilations inutiles.

5-6-1. Dissimuler l'implémentation▲

5-6-2. Réduire la recompilation▲

//: C05:Handle.h
// Handle classes
#ifndef HANDLE_H
#define HANDLE_H

class Handle {
  struct Cheshire; // Déclaration de classe uniquement
  Cheshire* smile;
public:
  void initialize();
  void cleanup();
  int read();
  void change(int);
};
#endif // HANDLE_H ///:~

struct Cheshire;

//: C05:Handle.cpp {O}
// Handle implementation
#include "Handle.h"
#include "../require.h"

// Define Handle's implementation:
struct Handle::Cheshire {
  int i;
};

void Handle::initialize() {
  smile = new Cheshire;
  smile->i = 0;
}

void Handle::cleanup() {
  delete smile;
}

int Handle::read() {
  return smile->i;
}

void Handle::change(int x) {
  smile->i = x;
} ///:~

struct Handle::Cheshire {

//: C05:UseHandle.cpp
//{L} Handle
// Use the Handle class
#include "Handle.h"

int main() {
  Handle u;
  u.initialize();
  u.read();
  u.change(1);
  u.cleanup();
} ///:~

Le contrôle d'accès en C++ donne un bon contrôle au créateur de la classe. Les utilisateurs de la classe peuvent [clairement] voir exactement ce qu'ils peuvent utiliser et ce qui est à ignorer. Plus important, ceci-dit, c'est la possibilité de s'assurer qu'aucun programmeur client ne devienne dépendant d'une partie quelconque [partie] de l'implémentation interne d'une classe. Si vous faites cela en tant que créateur de la classe, vous pouvez changer l'implémentation interne tout en sachant qu'aucun programmeur client ne sera affecté par les changements parce qu'ils ne peuvent accéder à cette partie de la classe.

Quand vous avez la capacité de changer l'implémentation interne, vous pouvez non seulement améliorer votre conception ultérieurement, mais vous avez également la liberté de faire des erreurs. Peu importe le soin avec lequel vous planifiez et concevez, vous ferez des erreurs. Savoir que vous pouvez faire des erreurs avec une sécurité relative signifie que vous expérimenterez plus, vous apprendrez plus vite, et vous finirez votre projet plus tôt.

L'interface publique dans une classe est ce que le programmeur client peutvoir, donc c'est la partie la plus importante à rendre “correcte” pendant l'analyse et la conception. Mais même cela vous permet une certaine marge de sécurité pour le changement. Si vous n'obtenez pas la bonne d'interface la première fois, vous pouvez ajouterplus de fonctions, tant que vous n'en enlevez pas que les programmeurs clients ont déjà employés dans leur code.

Les solutions des exercices suivants peuvent être trouvées dans le document électronique The Thinking in C++ Annotated Solution Guide, disponible à petit prix sur www.BruceEckel.com.

1. Créez une classe avec des données et des fonctions membres public, private, et protected. Créez un objet de cette classe et regardez quel genre de message le compilateur vous donne quand vous essayez d'accéder à chacun des membres.
2. Ecrivez un structappelé Libqui contienne trois objets stringa, b,et c. Dans main( )créez un objet Libappelé xet assignez une valeur à x.a, x.b, et x.c. Affichez les valeurs à l'écran. A présent remplacez a, b,et cpar un tableau de string s[3]. Vérifiez que le code dans main( )ne compile plus suite à ce changement. Créez maintenant une classe appelée Libc, avec des objets stringprivatea, b,et c, et les fonctions membres seta( ), geta( ), setb( ), getb( ), setc( ), et getc( )pour assigner ( seten angais, ndt) et lire ( getsignifie obtenir en anglais, ndt) les valeurs. Ecrivez main( )comme précédemment. A présent, changez les objets stringprivatea, b,et cen un tableau de string s[3]private. Vérifiez que le code dans main( )n'est pasaffecté par ce changement.
3. Créez une classe et une fonction friendglobale qui manipule les données privatedans la classe.
4. Ecrivez deux classes, chacune ayant une fonction membre qui reçoit un pointeur vers un objet de l'autre classe. Créez une instance des deux objets dans main( )et appelez la fonction membre mentionnée ci-dessus dans chaque classe.
5. Créez trois classes. La première classe contient des données private, et accorde le status de friendà l'ensemble de la deuxième classe ainsi qu'à une fonction membre de la troisième. Dans main( ), vérifiez que tout marche correctement.
6. Créez une classe Hen. Dans celle-ci, imbriquez une classe Nest. Dans Nest, placez une classe Egg. Chaque classe devrait avoir une fonction membre display( ). Dans main( ), créez une instance de chaque classe et appelez la fonction display( )de chacune d'entre elles.
7. Modifiez l'exercice 6 afin que Nestet Eggcontiennent chacune des données private. Donnez accès à ces données privées aux classes englobantes au moyen du mot-clé friend.
8. Créez une classe avec des données membres réparties au sein de nombreuses sections public, private,et protected. Ajoutez une fonction membre showMap( )qui affiche à l'écran les noms de chacune des données membre ainsi que leurs addresses. Si possible, compilez et exécutez ce programme sur plusieurs compilateurs et/ou ordinateur et/ou système d'exploitation pour voir s'il y a des différences d'organisation dans l'objet.
9. Copiez l'implémentation et les fichiers de test pour Stashdu Chapitre 4 afin que vous puissiez compiler et tester Stash.hdans ce chapitre.
10. Placez des objets de la class Hende l'Exercice 6 dans un Stash. Développez les ensembles et affichez-les à l'écran (si vous ne l'avez pas déjà fait, vous aurez besoin d'ajouter Hen::print( )).
11. Copiez l'implémentation et les fichiers de test pour Stackdu Chapitre 4 afin que vous puissiez compiler et tester Stack2.hdans ce chapitre.
12. Placez des objets de la classe Hende l'Exercice 6 dans un Stack. Développez les ensemble et affichez-les à l'écran (si vous ne l'avez pas déjà fait, vous aurez besoin d'ajouter Hen::print( )).
13. Modifiez Cheshiredans Handle.cpp, et vérifiez que votre gestionnaire de projets recompile et refasse l'édition de liens uniquement pour ce fichier, mais ne recompile pas UseHandle.cpp.
14. Créez une classe StackOfInt(une pile qui contient des ints) en utilisant la technique du "chat du Cheshire" qui disimule les structures de données de bas niveau utilisées pour stocker les éléments dans une classe appelée StackImp. Implémentez deux versions de StackImp: une qui utilise un tableau de intde taille fixe, et une qui utilise un vector<int>. Assignez une taille maximum dans le premier cas pour la pile afin que vous n'ayiez pas à vous soucier de l'agrandissement du tableau dans la première version. Remarquez que la classe StackOfInt.hn'a pas besoin d'être modifiée quand StackImpchange.