Cinq mythes courants sur le C++

Il ne s'agit pas là d'un cas particulier isolé. Je le considère comme totalement typique. Pourquoi alors de nombreux enseignants persistent à utiliser l'approche « le C d'abord » ?

• Parce que c'est ce qu'ils ont toujours fait.
• Parce que c'est ce que le programme d'enseignement demande.
• Parce que c'est la manière avec laquelle ils ont eux-mêmes débuté dans leur jeunesse.
• Parce que la plus petite taille du C donne l'illusion qu'il est plus simple à utiliser que le C++.
• Parce que de toute façon, un jour ou l'autre, les étudiants auront aussi à apprendre le C (ou le sous-ensemble C du C++).

Néanmoins, le C n'est ni le sous-ensemble le plus simple ni le plus utile à apprendre en premier. De plus, une fois que vous comprenez raisonnablement le C++, le sous-ensemble C vient facilement. Enfin, commencer par le C implique de faire face à des erreurs qui seraient aisément évitées en C++, et à devoir apprendre des techniques pour en minimiser les effets.

Pour une approche moderne de l'apprentissage du C++, je vous invite à consulter mon livre, Programmation - Principes et pratique avec C++(1)[13]. Il contient même un chapitre vers la fin montrant comment utiliser le C. Il a été utilisé, avec un succès raisonnable, par des centaines de milliers d'étudiants débutants dans plusieurs universités. Sa seconde édition(2) utilise le C++11 et le C++14 pour faciliter l'apprentissage.

Avec le C++11[11-12], le C++ est devenu plus abordable pour les novices. Par exemple, voici un vector de la bibliothèque standard initialisé avec une séquence d'éléments :

vector<int> v = {1,2,3,5,8,13};

En C++98, il n'y avait que les tableaux que l'on pouvait initialiser à l'aide de liste. En C++11, on peut définir, dans tous les types où on le souhaite, un constructeur qui accepte une liste d'initialisation définie à l'aide de {}.

On peut alors parcourir ce vecteur à l'aide d'une boucle sur intervalle(3) :

for(int x : v) test(x);

Ce code appellera test() une fois par élément de v.

Une boucle sur intervalle peut parcourir toutes sortes d'intervalles. On aurait ainsi pu simplifier l'exemple en utilisant directement la liste d'initialisation :

for (int x : {1,2,3,5,8,13}) test(x);

L'un des objectifs du C++11 était de rendre simples les choses simples. Tout ça bien entendu, sans causer de dégradation des performances.

Souhaiteriez-vous rendre ce code plus générique ? Après tout, il ne fonctionne que pour des vectors de pointeurs sur Shape. Comment faire pour les listes et les tableaux de base du langage ? Et si les objets sont gérés par des « pointeurs intelligents » (des pointeurs qui aident à gérer les ressources), comme shared_ptr et unique_ptr ? Comment faire pour les objets qui ne s'appellent pas Shape, mais que l'on peut quand même dessiner (draw()) et tourner (rotate()) ?

template<typename Iter>
void rotate_and_draw(Iter first, Iter last, int r)
{
  for_each(first,last,[](auto p) { p->rotate(r); });  // tourne tous les éléments compris dans [first:last)
  for (auto p = first; p!=last; ++p) p->draw();       // dessine tous les éléments compris dans [first:last)
}

Ce code fonctionne pour n'importe quel intervalle que l'on peut parcourir de first à last. C'est le style utilisé par les algorithmes de la bibliothèque standard. J'ai utilisé auto pour ne pas avoir à nommer le type servant d'interface pour les « objets qui se comportent comme des Shapes». C'est une fonctionnalité du C++11 qui signifie « utilise le type de l'expression servant à initialiser la variable », donc le type de p dans la boucle est résolu vers le type de first, quel qu'il soit. L'utilisation de auto pour le type d'un argument d'une lambda est une fonctionnalité du C++14, mais déjà disponible de nos jours.

Regardons maintenant :

void user(list<unique_ptr<Shape>>& lus, Container<Blob>& vb)
{
  rotate_and_draw(lst.begin(),lst.end());
  rotate_and_draw(begin(vb),end(vb));
}

Ici, je suppose que Blob est un type graphique qui dispose des opérations draw() et rotate(), et que Container est un conteneur de données. Le type std::list (les listes chaînées de la bibliothèque standard) possède des fonctions membres begin() et end() pour permettre à l'utilisateur de parcourir ses éléments. C'est pratique, et classique en POO. Mais que faire si Container n'utilise pas la même notation que la bibliothèque standard pour parcourir un intervalle semi-ouvert [b,e) ? S'il n'a pas de fonctions begin() et end() ? Je n'ai jamais rencontré de conteneur que l'on ne puisse pas parcourir, on peut donc définir des fonctions libres begin() et end() avec la sémantique appropriée. Le standard fournit déjà ces fonctions pour les tableaux C, et donc si Container est un tableau C, le problème est déjà résolu ; et les tableaux C restent couramment utilisés.

Voyons maintenant un cas plus complexe : Que faire si Container contient des pointeurs sur des objets et possède un modèle d'accès et de parcours différent ? Par exemple, supposons que l'on soit censé parcourir un Container de la manière suivante :

for (auto p = c.first(); p!=nullptr; p=c.next()) 
{ /* on fait quelque chose avec *p */}

Ce style n'est pas rare. On peut le faire correspondre avec une séquence [b, e) comme suit :

template<typename T> struct Iter {
  T* current;
  Container<T>& c;
};
template<typename T> Iter<T> begin(Container<T>& c) { return Iter<T>{c.first(),c}; }
template<typename T> Iter<T> end(Container<T>& c)   { return Iter<T>{nullptr}; }
template<typename T> Iter<T> operator++(Iter<T> p)  { p.current = c.next(); return this; }
template<typename T> T*      operator*(Iter<T> p)   { return p.current; }

On peut remarquer que cette modification est non intrusive : on n'a pas eu à modifier le code de Container ni une éventuelle hiérarchie de classes autour de Container pour adapter un Container au modèle de parcours attendu par la bibliothèque standard du C++. Il s'agit d'une adaptation, pas d'une modification.

J'ai choisi cet exemple pour montrer que ces techniques de programmation génériques ne sont pas limitées à la bibliothèque standard (où elles sont omniprésentes). De plus, d'après les définitions les plus communes de « orienté objet », elles ne sont pas orientées objet.

Cette idée que le code C++ devrait être orienté objet (en utilisant des hiérarchies de classes et des fonctions virtuelles partout) peut grandement détériorer les performances. Cette vision de l'orienté objet est géniale si, à l'exécution, vous avez besoin de résoudre un type parmi un ensemble. Je l'utilise souvent à cet effet. En revanche, elle est assez rigide (tous les types reliés entre eux ne rentrent pas aisément dans une hiérarchie de classes) et les appels virtuels de fonctions empêchent les possibilités d'inlining (ce qui peut se traduire par un rapport de vitesse d'exécution de 50 dans des cas simples et importants).

Considérons déjà le problème de déplacement d'objets d'une portée à une autre. La question fondamentale est comment faire sortir une grande quantité d'informations sans passer par une copie coûteuse ou une dangereuse manipulation de pointeurs. L'approche historique consiste à utiliser un pointeur :

X* make_X()
{
  X* p = new X:
  // ... on remplit X ..
  return p;
}
void user()
{
  X* q = make_X();
  // ... on utilise *q ...
  delete q;
}

Qui est alors responsable de la destruction de l'objet ? Dans ce cas simpliste, c'est bien évidemment l'appelant de make_X(), mais dans le cas général, la solution n'est pas si triviale. Et si make_X() gardait un cache d'objets pour minimiser le coût des allocations mémoire ? Et si user() transférait le pointeur à un other_user() ? Il y a un risque important de confusion, et les fuites mémoire ne sont pas rares dans ce style de programmation.

Je pourrais utiliser un shared_ptr ou un unique_ptr pour être explicite sur la propriété de l'objet créé. Par exemple :

unique_ptr<X> make_X();

Mais pourquoi utiliser un pointeur (intelligent ou pas) à la base ? Je ne veux pas un pointeur et bien souvent, un pointeur apporterait des distractions par rapport à l'usage normal d'un objet. Par exemple, une fonction d'addition de matrice (Matrix) crée un nouvel objet (la somme) à partir de deux arguments, mais retourner un pointeur conduirait à devoir écrire du code vraiment étrange :

unique_ptr<Matrix> operator+(const Matrix& a, const Matrix& b);
Matrix res = *(a+b);

La présence de * est nécessaire pour obtenir la somme et non un pointeur sur elle. Ce que j'aurais voulu obtenir dans beaucoup de cas, c'est un objet et non un pointeur sur un objet. Dans de nombreux cas, je pourrais l'obtenir facilement. En particulier, la copie des petits objets est peu coûteuse et il ne me viendrait même pas à l'idée de passer par un pointeur :

double sqrt(double); // une fonction racine carrée
double s2 = sqrt(2); // récupérer la racine carrée de 2

D'un autre côté, les objets contenant une grande quantité de données ne sont en général que des indirections vers la plupart de ces données. Prenons istream, string, vector, list et thread. Ce ne sont que quelques octets qui permettent d'accéder à des quantités de données potentiellement importantes. Si on revient sur l'addition de matrice, ce que l'on aurait voulu, c'est :

Matrix operator+(const Matrix& a, const Matrix& b); // retourne la somme de a et b
Matrix r = x+y;

On peut aisément y parvenir :

Matrix operator+(const Matrix& a, const Matrix& b)
{
  Matrix res;
  // ... on remplit res avec la somme des éléments ...
  return res;
}

Par défaut, les éléments de res vont être copiés dans r. Mais comme res est sur le point d'être détruite, et donc la mémoire contenant ses éléments libérée, il n'y a pas besoin de copier : il est possible de « voler » les éléments. N'importe qui pouvait mettre ça en place dès les premiers jours du C++, et beaucoup l'ont fait, mais c'était un peu complexe à mettre en œuvre et la technique n'était pas comprise de tous. Le C++11 supporte directement de « vol de représentation » depuis une indirection sous la forme d'opérations de déplacement qui transfèrent la propriété. Regardons une Matrice 2D de doubles :

class Matrix {
  double* elem; // pointeur sur les éléments
  int nrow;     // nombre de lignes
  int ncol;     // nombre de colonnes
public:
  Matrix(int nr, int nc)                  // constructeur : alloue les éléments
    :elem{new double[nr*nc]}, nrow{nr}, ncol{nc}
  {
    for(int i=0; i<nr*nc; ++i) elem[i]=0; // initialise les éléments
  }
  Matrix(const Matrix&);                  // constructeur de copie
  Matrix operator=(const Matrix&);        // opérateur d'affectation
  Matrix(Matrix&&);                       // constructeur de déplacement
  Matrix operator=(Matrix&&);             // affectation par déplacement
  ~Matrix() { delete[] elem; }            // destructeur : libère les éléments
// …
};

Une opération de copie se reconnaît à son argument par référence (&). De même, une opération de déplacement se reconnaît à son argument par rvalue reference (&&). Une opération de déplacement est supposée « voler » la représentation et laisser un « objet vide » derrière elle. Pour Matrix, ça se traduit comme suit :

Matrix::Matrix(Matrix&& a)                   // constructeur de déplacement
  :nrow{a.nrow}, ncol{a.ncol}, elem{a.elem}  // « vole » la représentation
{
  a.elem = nullptr;                          // ne laisse « rien » derrière
}

Et voilà ! Quand le compilateur voit le return res , il se rend compte que res est sur le point d'être détruite. C'est-à-dire qu'elle ne sera pas utilisée au-delà du return. En conséquence, il utilisera le constructeur par déplacement plutôt que le constructeur de copie pour transférer la valeur de retour. En particulier pour :

Matrix r = a+b;

le res à l'intérieur de operator+() devient vide - ce qui rend la tâche du destructeur triviale - et les éléments de res sont désormais la propriété de r. Nous avons réussi à faire sortir les éléments du résultat - potentiellement des mégaoctets de mémoire - de la fonction operator+() pour les déplacer dans la variable du code appelant. On l'a fait en minimisant les coûts (probablement des affectations de quatre mots mémoire).

Des développeurs C++ experts ont fait remarquer qu'il existe des cas où un bon compilateur peut totalement éliminer la copie d'une valeur de retour (ce qui dans ce cas économiserait la copie de quatre mots et l'appel du destructeur). Néanmoins, ça dépend de l'implémentation, et je n'aime pas que les performances de mes techniques de programmation de base dépendent du niveau d'intelligence de tel ou tel compilateur. Qui plus est, un compilateur capable d'éliminer la copie est tout aussi capable d'éliminer le déplacement. Nous avons ici un moyen simple, fiable et général d'éliminer la complexité et le coût associé au déplacement de beaucoup d'informations d'une portée à l'autre.

De plus la sémantique de déplacement s'applique également aux affectations, ainsi pour r = a+b, nous profitons de l'optimisation de déplacement grâce à l'opérateur d'affectation par déplacement. Optimiser une affectation est bien plus complexe à réaliser pour un optimiseur (de compilateur), sans le support du langage ou du développeur, que des optimisations à l'initialisation.

Très souvent, on n'a même pas besoin de définir toutes ces opérations de copie et de déplacement. Si une classe est composée d'éléments qui se comportent comme l'on veut, on peut se reposer sur les fonctions générées par le compilateur. Ainsi :

class Matrix {
    vector<double> elem; // éléments
    int nrow;            // nombre de lignes
    int ncol;            // nombre de colonnes
public:
    Matrix(int nr, int nc)    // constructeur : alloue les éléments
      :elem(nr*nc), nrow{nr}, ncol{nc}
    { }
    // ...
};

Cette version de la classe Matrix se comporte comme la version précédente, excepté qu'elle gère un peu mieux les erreurs, et qu'elle prend un peu plus de place en mémoire (un vector est généralement représenté avec trois mots).

Et pour les objets qui ne sont pas de simples indirections ? S'ils sont petits, comme un int ou un complex<double>, pas la peine de s'inquiéter. Sinon, on peut construire une indirection par-dessus ou les retourner en utilisant des pointeurs « intelligents », tels que unique_ptr et shared_ptr. Ne vous salissez pas les mains avec des opérations new et delete manuelles.

Il n'y a, hélas, pas de classe de matrice telle que celle que j'ai utilisée dans les exemples dans la bibliothèque standard du C++, mais différentes variantes sont disponibles (en open source ou commercial). Par exemple, cherchez sur le Web : « Origin Matrix Sutton » ou consultez le chapitre 29 de mon livre The C++ Programming Language (Fourth Edition) [11] pour une discussion sur la conception d'une telle classe de matrice.

Dans les discussions sur les ramasse-miettes, on constate souvent que tous les objets n'ont pas forcément un possesseur unique. Ce qui signifie que l'objet doit être détruit/libéré quand la dernière référence le concernant disparaît. Dans notre modèle, ça signifie que l'on a besoin d'un mécanisme pour détruire l'objet quand son dernier possesseur est détruit. C'est-à-dire que l'on a besoin d'une notion de propriété partagée. Prenons l'exemple d'une queue synchronisée, sync_queue, utilisée pour communiquer entre tâches. On donne un pointeur sur sync_queue à un producteur et à un consommateur :

void startup()
{
  sync_queue* p  = new sync_queue{200};  // on va avoir des ennuis !
  thread t1 {task1,iqueue,p};  // task1 lit depuis *iqueue et écrit dans *p
  thread t2 {task2,p,oqueue};  // task2 lit depuis *p et écrit dans *oqueue
  t1.detach();
  t2.detach();
}

Je suppose que task1, task2, iqueue et oqueue ont tous été définis convenablement par ailleurs, et je m'excuse de laisser les threads vivre plus longtemps que la portée où ils sont définis, en utilisant detach(). On pourrait aussi imaginer des branchements plus complexes entre plus de tâches et plus de sync_queue. Cependant, une seule question m'intéresse ici : « Qui va détruire la sync_queue créée dans startup() ? ». Tel que le code est écrit, il n'y a qu'une seule bonne réponse : « la dernière personne à utiliser la sync_queue ». C'est un cas classique pour justifier l'utilisation d'un ramasse-miettes. La solution initiale pour mettre en œuvre un ramasse-miettes était des pointeurs avec comptage de références : on maintient un compteur d'utilisations pour l'objet, et au moment où ce compteur va passer à zéro, on détruit l'objet. Beaucoup de langages de nos jours utilisent une variante de cette stratégie, et la solution C++ pour le faire repose sur shared_ptr. Cet exemple devient :

void startup()
{
  auto p = make_shared<sync_queue>(200);  // crée une sync_queue et retourne un stared_ptr pointant dessus
  thread t1 {task1,iqueue,p};  // task1 lit depuis *iqueue et écrit dans *p
  thread t2 {task2,p,oqueue};  // task2 lit depuis *p et écrit dans *oqueue
  t1.detach();
  t2.detach();
}

Maintenant, les destructeurs de task1 et task2 peuvent détruire leurs shared_ptrs (de manière implicite dans la plupart des bonnes conceptions) et la dernière tâche à le faire détruira la sync_queue.

C'est simple, et raisonnablement efficace. Il n'y a pas besoin d'un système complexe de ramasse-miettes s'exécutant pendant que le programme tourne. Plus important : ça va plus loin que le fait de juste récupérer la mémoire associée avec une sync_queue. Ce mécanisme récupère aussi les objets de synchronisation (les mutex, les verrous ou n'importe quoi d'autre) contenus dans sync_queue pour gérer la synchronisation des threads exécutant les deux tâches. Encore une fois, nous avons affaire à un mécanisme non seulement de gestion de la mémoire, mais aussi de gestion de ressources au sens large. Cet objet de synchronisation « caché » est géré exactement comme les descripteurs de fichiers et les buffers des flux de l'exemple précédent.

On pourrait essayer d'éliminer l'utilisation d'un shared_ptr en introduisant un possesseur unique dans une portée qui englobe les deux tâches, mais ce n'est pas toujours très aisé à faire, et le C++11 fournit donc à la fois les unique_ptr (propriété unique) et les shared_ptr (propriété partagée).

Jusqu'à présent, j'ai uniquement discuté de ramasse-miettes en rapport avec l'aspect gestion des ressources. Il a aussi un rôle à jouer dans la sûreté par l'utilisation de types. Dès que l'on a une opération de destruction manuelle, elle peut être utilisée incorrectement. Par exemple :

X* p = new X;
X* q = p;
delete p;
// ...
q->do_something();  // la mémoire qui contenait *p a peut-être été réutilisée

Ne faites pas ça. Les delete utilisés directement sont dangereux - et inutiles dans du code classique/client. Laissez les delete à l'intérieur de classes de gestion des ressources, comme string, ostream, thread, unique_ptr et shared_ptr. Ces delete sont précautionneusement mis en correspondance avec des new, et sont alors sans danger.

Pour la gestion des ressources, je considère un ramasse-miettes comme le dernier choix souhaitable, et non pas comme « la solution » ni un idéal :

1. Utilisez des abstractions appropriées qui gèrent leurs propres ressources récursivement et implicitement. Ces objets seront, de préférence, des variables liées à une portée(4).
2. Si vous avez besoin d'une sémantique de pointeurs/références, utilisez des « pointeurs intelligents », comme unique_ptr et shared_ptr pour représenter la possession.
3. Si tout le reste échoue (par exemple parce que votre code est intégré dans un programme utilisant des pointeurs dans tous les sens sans utiliser de stratégie supportée par le langage pour la gestion des ressources ou des erreurs), essayez de gérer les ressources autres que la mémoire à la main, et branchez un ramasse-miettes conservatif pour gérer les presque inévitables fuites mémoire.

Cette stratégie est-elle parfaite ? Non, mais elle est générique et simple. Les stratégies traditionnelles à base de ramasse-miettes ne sont pas parfaites non plus, et elles ne gèrent pas directement les ressources autres que la mémoire.

Prenons un exemple simple : si vous vouliez trier un ensemble de flottants par ordre décroissant, vous pourriez écrire du code qui le fait. Néanmoins, à moins que vous ayez des particularités très spécifiques (par exemple, plus de nombres à trier qu'il n'y a de place en mémoire), faire ainsi serait très naïf. Depuis des décennies, on a à disposition des bibliothèques avec des algorithmes de tri fournissant des performances acceptables. Celle que j'aime le moins est la bibliothèque standard du C avec qsort() :

int greater(const void* p, const void* q)  // comparaison à 3 possibilités
{
  double x = *(double*)p;  // récupérer le double stocké à l'adresse p
  double y = *(double*)q;
  if (x>y) return 1;
  if (x<y) return -1;
  return 0;
}
void do_my_sort(double* p, unsigned int n)
{
  qsort(p,n,sizeof(*p),greater);
}
int main()
{
  double a[500000];
  // ... on remplit a ...
  do_my_sort(a,sizeof(a)/sizeof(*a));  // on passe le pointeur et le nombre d'éléments
  // ...
}

Si vous n'êtes pas un développeur C, ou si vous n'avez pas utilisé qsort() récemment, ça mérite quelques explications : qsort() prend quatre arguments :

• un pointeur sur une suite d'octets ;
• un nombre d'éléments ;
• la taille d'un élément présent dans ces octets ;
• une fonction comparant deux éléments, passés sous forme de pointeur sur leur premier octet.

On peut remarquer que cette interface jette de l'information. On ne trie pas vraiment des octets. On trie des double, mais qsort() ne le sait pas, et on doit lui fournir des détails sur comment comparer des double, ou le nombre d'octets pour stocker un double. Bien entendu, le compilateur connaît déjà ces informations, mais l'interface bas niveau de qsort() l'empêche de tirer parti de ces informations de types. Devoir indiquer explicitement de telles informations est aussi un risque d'erreur. N'aurais-je pas inversé les deux arguments entiers de qsort() ? Si tel était le cas, le compilateur ne s'en rendrait pas compte. Est-ce que ma fonction compare() respecte les conventions d'une comparaison à trois possibilités du C ?

Si vous regardez des implémentations de qualité industrielle de qsort() (faites-le, s'il vous plaît), vous verrez qu'elles travaillent dur pour compenser le manque d'informations. Par exemple, échanger deux éléments exprimés comme un nombre d'octets n'est pas aussi trivial à faire efficacement qu'échanger deux double. L'appel indirect à la fonction de comparaison peut uniquement être éliminé si le compilateur propage les constantes sur les pointeurs de fonctions.

Comparez qsort() à son équivalent en C++, sort() :

void do_my_sort(vector<double>& v)
{
  sort(v,[](double x, double y) { return x>y; });  // trie v par ordre décroissant
}
int main()
{
  vector<double> vd;
  // ... on remplit vd ...
  do_my_sort(vd);
  // ...
}

On a besoin de moins d'explications ici. Un vector connaît sa taille, on n'a donc pas besoin de passer explicitement le nombre d'éléments. On ne « perd » jamais le type d'un élément, donc pas besoin de s'occuper de la taille des éléments. Par défaut, sort() trie par ordre croissant, j'ai donc du préciser le critère de comparaison, comme avec qsort(). Ici, je l'ai passé sous forme d'expression lambda comparant deux doubles avec >. Il se trouve que cette lambda est trivialement mise en ligne(5) par tous les compilateurs C++ que je connais, donc la comparaison se réduit juste à un appel à l'opération machine plus-grand-que ; il n'y a pas de (coûteux) appels indirects de fonction.

J'ai utilisé une version de sort fonctionnant avec les conteneurs, pour ne pas avoir à gérer explicitement les itérateurs et devoir écrire :

std::sort(v.begin(),v.end(),[](double x, double y) { return x>y; });

Je pourrais aller plus loin, et utiliser un objet de comparaison du C++14 :

sort(v,greater<>()); // trie v par ordre décroissant

Quelle version est la plus rapide ? Vous pouvez compiler la version qsort() en C comme en C++ sans aucune différence de performances, il s'agit donc d'une comparaison de styles de programmation, plutôt que de langages. Les implémentations des bibliothèques semblent toujours utiliser les mêmes algorithmes pour sort() et qsort(), c'est donc une comparaison de styles de programmation, et non d'algorithmes. Des bibliothèques et des compilateurs différents donnent des résultats différents, bien entendu, mais pour chaque implémentation, on a une image assez raisonnable des effets des différents niveaux d'abstraction.

J'ai récemment exécuté les exemples, et j'ai trouvé la version avec sort() 2,5 fois plus rapide que la version avec qsort(). Votre mesure peut varier d'un compilateur à l'autre ou d'une machine à l'autre, mais jamais je n'ai vu qsort() battre sort(). J'ai déjà vu sort() aller 10 fois plus vite que qsort(). Pourquoi ? Le sort() de la bibliothèque standard du C++ est clairement de plus haut niveau que qsort(), tout en étant plus générique et plus flexible. Elle est sûre au niveau du typage, et paramétrée en fonction du type de stockage, du type des éléments et du critère de tri. Pas de pointeurs, de cast, de taille ou d'octets à l'horizon. La bibliothèque standard STL du C++, dont sort() fait partie, prend bien garde à ne pas jeter d'information. Ce qui permet une mise en ligne (inlining) excellente, et de bonnes optimisations.

La généricité et le code haut niveau peuvent battre le code bas niveau. Ce n'est pas toujours le cas, bien sûr, mais la comparaison sort()/qsort() n'est pas un exemple isolé. Commencez toujours par une solution haut niveau, précise et respectant le typage. N'optimisez que si nécessaire.

Quel que soit le langage, écrire un programme en utilisant uniquement les fonctionnalités de base (comme if, for, etc.) est très fastidieux. En revanche, avec les bibliothèques adaptées (comme des bibliothèques graphiques, de planification de trajets, de base de données) à peu près n'importe quelle tâche peut être réalisée avec une quantité d'efforts raisonnable.

La bibliothèque standard du C++ ISO est relativement petite (comparée à des bibliothèques commerciales), mais il y a pléthore de bibliothèques, open source ou commerciales, dans la nature. Par exemple, si on utilise des bibliothèques (libres ou propriétaires) comme Boost [3], POCO [2], AMP [4], TBB [5], Cinder [6], wxWidgets [7], et CGAL [8], beaucoup de tâches, classiques ou plus spécifiques, deviennent plus simples. Par exemple, modifions le programme précédent pour lire des URL depuis une page Web. Nous allons commencer par rendre get_addresses() plus générique pour trouver n'importe quelle chaîne correspondant à un motif :

set<string> get_strings(istream& is, regex pat)
{
  set<string> res;
  smatch m;
  for (string s; getline(is,s); )  // lit une ligne
  if (regex_search(s, m, pat))
    res.insert(m[0]);              // sauve le résultat dans set
  return res;
}

C'est juste une simplification. Ensuite, nous devons trouver un moyen d'aller sur le Web lire un fichier. Boost fournit une bibliothèque, asio, pour communiquer sur le Web :

#include "boost/asio.hpp" // récupère boost.asio

Parler à un serveur Web est un peu compliqué :

try {
  string server = "www.stroustrup.com";
  boost::asio::ip::tcp::iostream s {server,"http"};  // ouvre une connexion
  connect_to_file(s,server,"C++.html");    // vérifie et ouvre le fichier
  regex pat {R"((http://)?www([./#\+-]\w*)+)"}; // URL
  for (auto x : get_strings(s,pat))    // recherche les URL
    cout << x << '\n';
}
catch (std::exception& e) {
  std::cout << "Exception: " << e.what() << "\n";
  return 1;
}

Quand on lit le fichier C++.html sur www.stroustrup.com, on obtient :

http://www-h.eng.cam.ac.uk/help/tpl/languages/C++.html
http://www.accu.org
http://www.artima.co/cppsource
http://www.boost.org
...

J'ai utilisé un set, les URL apparaissent donc triées par ordre alphabétique.

J'ai sournoisement, mais de manière assez réaliste, « caché » la vérification et la connexion HTTP dans une fonction (connect_to_file()) :

void connect_to_file(iostream& s, const string& server, const string& file)
  // ouvre une connexion à un serveur, ouvre un fichier et l'attache à s
  // on saute les en-têtes
{
  if (!s)
    throw runtime_error{"can't connect\n"};
  // Demande à lire le fichier depuis le serveur:
  s << "GET " << "http://"+server+"/"+file << " HTTP/1.0\r\n";
  s << "Host: " << server << "\r\n";
  s << "Accept: */*\r\n";
  s << "Connection: close\r\n\r\n";
  // Vérifie que la réponse est OK:
  string http_version;
  unsigned int status_code;
  s >> http_version >> status_code;
  string status_message;
  getline(s,status_message);
  if (!s || http_version.substr(0, 5) != "HTTP/")
    throw runtime_error{ "Invalid response\n" };
  if (status_code!=200)
    throw runtime_error{ "Response returned with status code" };
  // Saute les en-têtes de la réponse, qui sont terminés par une ligne vide :
  string header;
  while (getline(s,header) && header!="\r")
    ;
}

Comme très souvent, je ne suis pas parti de zéro. La gestion d'une connexion HTTP a été largement reprise de la documentation d'asio par Christopher Kohlhoff's [9].

Le C++ est un langage compilé, conçu avec comme but principal de fournir du code propre et maintenable là où les performances et la fiabilité comptent (par exemple, les infrastructures[10]). Il n'a pas pour objectif d'entrer en compétition directe sur des petits programmes avec des langages « de script » interprétés ou compilés de manière minimaliste. En réalité, de tels langages (par exemple JavaScript), mais d'autres aussi (par exemple Java) sont souvent implémentés en C++. Néanmoins, il y a de nombreux programmes en C++ qui font d'une douzaine à quelques centaines de lignes.

Les auteurs de bibliothèques C++ pourraient donner un coup de main ici. Au lieu de se concentrer (uniquement) sur les parties intelligentes et avancées des bibliothèques, ils pourraient fournir des programmes « Hello, World! » faciles à essayer. En proposant une version triviale à installer de la bibliothèque et un exemple à la « Hello, World! » d'une page maximum démontrant ce que la bibliothèque peut faire. Nous sommes tous novices à un moment ou à un autre. Au fait, ma version du « Hello, World! » pour le C++ est :

#include<iostream>
int main()
{
  std::cout << "Hello, World\n";
}

Je trouve les versions plus longues et plus complexes très peu amusantes quand il s'agit d'illustrer le C++ ISO et sa bibliothèque standard.