La clef du problème des macros du préprocesseur est que vous pouvez être abusivement induits à penser que le comportement du préprocesseur est le même que celui du compilateur. Bien sûr, c'était voulu qu'une macro ressemble et agisse comme un appel de fonction, si bien qu'il est assez facile de tomber dans cette erreur. Les difficultés commencent quand les différences subtiles se manifestent.

Comme exemple simple, considérez le code suivant :

#define F (x) (x + 1)

A présent, si un appel est fait à F( ) de cette façon :

F(1)

le préprocesseur le développe, de façon quelque peu inattendue, comme ceci :

(x) (x + 1)(1)

Le problème se produit à cause de l'espace entre F et sa parenthèse d'ouverture dans la définition de la macro. Quand cet espace est supprimé, vous pouvez de fait appeler la macro avec l'espace

F (1)

et elle se développera toujours correctement ainsi :

(1 + 1)

L'exemple ci-dessus est relativement trivial et le problème sera tout de suite apparent. Les vraies difficultés ont lieu quand on utilise des expressions comme argument dans les appels aux macros.

Il y a deux problèmes. Le premier est que les expressions peuvent se développer dans la macro si bien que la priorité de leur évaluation n'est pas celle que vous attendriez. Par exemple :

#define FLOOR(x,b) x>=b?0:1

A présent, si des expressions sont utilisées en arguments:

if(FLOOR(a&0x0f,0x07)) // ...

la macro se développera en :

if(a&0x0f>=0x07?0:1)

La priorité de & est plus basse que celle de >=, si bien que l'évaluation de la macro vous réserve une surprise. Une fois le problème découvert, vous pouvez le résoudre en plaçant des parenthèses autour de tous les éléments dans la définition de la macro. (C'est une bonne habitude quand vous créez des macros de préprocesseur.) Ainsi,

#define FLOOR(x,b) ((x)>=(b)?0:1)

Découvrir le problème peut être difficile, toutefois, et vous pouvez ne pas le découvrir après avoir estimé que la macro se comporte comme il faut. Dans la version sans parenthèse de la macro précédente, la plupart des expressions se comporteront correctement parce que la priorité de >= est plus basse que celle de la plupart des autres opérateurs comme +, /, – –, et même les opérateurs de manipulation de bits. Ainsi, vous pouvez facilement penser que cela marche avec toutes les expressions, y compris celles qui utilisent des opérateurs logiques de bit.

Le problème précédent peut être résolu par des habitudes de programmation soigneuses : mettre tout entre parenthèses dans une macro. Toutefois, la deuxième difficulté est plus subtile. Contrairement à une fonction normale, à chaque fois que vous utilisez un argument dans une macro, cet argument est évalué. Tant que la macro est appelée seulement avec des variables ordinaires, cette évaluation est sans risque, mais si l'évaluation d'un argument a des effets secondaires, alors le résultat peut être surprenant et ne ressemblera certainement pas au comportement d'une fonction.

Par exemple, cette macro détermine si son argument est compris dans un certain intervalle :

#define BAND(x) (((x)>5 && (x)<10) ? (x) : 0)

Tant que vous utilisez un argument "ordinaire", la macro se comporte tout à fait comme une vraie fonction. Mais dès que vous vous laissez aller et commencez à croire que c'est une vraie fonction, les problèmes commencent. Ainsi :

//: C09:MacroSideEffects.cpp
#include "../require.h"
#include <fstream>
using namespace std;
 
#define BAND(x) (((x)>5 && (x)<10) ? (x) : 0)
 
int main() {
  ofstream out("macro.out");
  assure(out, "macro.out");
  for(int i = 4; i < 11; i++) {
    int a = i;
    out << "a = " << a << endl << '\t';
    out << "BAND(++a)=" << BAND(++a) << endl;
    out << "\t a = " << a << endl;
  }
} ///:~

Remarquez l'utilisation de majuscules dans le nom de la macro. C'est une pratique efficace parce qu'elle signale au lecteur que c'est une macro et pas une fonction, si bien que s'il y a des problèmes, elle agit comme un rappel.

Voici la sortie produite par le programme, qui n'est pas du tout ce à quoi vous vous seriez attendu dans le cas d'une vraie fonction :

a = 4
  BAND(++a)=0
   a = 5
a = 5
  BAND(++a)=8
   a = 8
a = 6
  BAND(++a)=9
   a = 9
a = 7
  BAND(++a)=10
   a = 10
a = 8
  BAND(++a)=0
   a = 10
a = 9
  BAND(++a)=0
   a = 11
a = 10
  BAND(++a)=0
   a = 12

Quand a vaut quatre, seule la première partie de l'expression conditionnelle a lieu, si bien que l'expression n'est évaluée qu'une fois, et l'effet secondaire de l'appel à la macro est que a passe à cinq, qui est ce que vous attendriez d'un appel à une fonction normale dans la même siutation. Toutefois, quand le nombre est dans l'intervalle, les deux conditions sont testées, ce qui résulte en deux incrémentations. Le résultat est produit en évaluant à nouveau l'argument, ce qui entraîne une troisième incrémentation. Une fois que le nombre sort de l'intervalle, les deux conditions sont toujours testées et vous vous retrouvez toujours avec deux incrémentations. Les effets secondaires diffèrent selon l'argument.

Ce n'est clairement pas le genre de comportement que vous voulez de la part d'une macro qui ressemble à un appel de fonction. Dans ce cas, la solution évidente est d'en faire une vraie fonction, ce qui, bien sûr, ajoute du temps système supplémentaire et peut réduire l'efficacité si vous appelez souvent cette fonction. Malheureusement, le problème peut n'être pas toujours aussi évident, et vous pouvez inconsciemment avoir une librairie qui contienne des fonctions et des macros mélangées ensemble, si bien qu'un problème comme celui-ci peut dissimuler des bugs très difficiles à découvrir. Par exemple, la macro putc( ) dans cstdio peut évaluer son deuxième argument deux fois. C'est une spécification du C Standard. Ainsi, des implémentations peu soigneuses de toupper( ) comme une macro peuvent évaluer l'argument plus d'une fois, ce qui génèrera des résultats inattendus avec toupper(*p++). (45)

9.1.1. Les macros et l'accès▲

class X {
  int i;
public:
#define VAL(X::i) // Erreur

En résolvant le problème en C++ d'une macro ayant accès aux membres private d'une classe, tous les problèmes associés aux macros du préprocesseur ont été éliminés. Ceci a été réalisé en transportant, comme il se doit, le concept de macro sous le contrôle du compilateur. Le C++ implémente la macro comme une fonction inline, qui est une vraie fonction dans tous les sens du terme. Une fonction inline observe tous les comportements que vous attendez d'une fonction ordinaire. La seule différence est qu'une fonction inline est développée sur place, comme une macro du préprocesseur, si bien que le temps système de l'appel à la fonction est éliminé. Ainsi vous ne devriez (presque) jamais utiliser de macros, mais uniquement des fonctions inline.

Toute fonction définie dans le corps d'une classe est automatiquement inline, mais vous pouvez aussi rendre inline une fonction qui n'appartient pas à une classe en la faisant précéder du mot-clef inline. Toutefois, pour qu'il ait un effet, vous devez inclure le corps de la fonction à la déclaration, autrement le compilateur la traitera comme une déclaration de fonction ordinaire. Ainsi,

inline int plusOne(int x);

n'a aucun autre effet que de déclarer la fonction (qui peut avoir ou ne pas avoir une définition inline plus loin). L'approche efficace fournit le corps de la fonction :

inline int plusOne(int x) { return ++x; }

Remarquez que le compilateur vérifiera (comme il le fait toujours) l'usage correct de la liste des arguments de la fonction et de la valeur de retour (réalisant toute conversion nécessaire), ce dont est incapable le préprocesseur. Egalement, si vous essayez d'écrire le code ci-dessus comme une macro du préprocesseur, vous obtenez un effet secondaire non désiré.

Vous aurez presque toujours intérêt à placer les définitions inline dans un fichier d'en-tête. Quand le compilateur voit une telle fonction, il place le type de la fonction (la signature combinée avec la valeur de retour) et le corps de la fonction dans sa table de symboles. Quand vous utilisez la fonction, le compilateur s'assure que l'appel est correct et que la valeur de retour est utilisée correctement, et substitue ensuite le corps de la fonction à l'appel, éliminant ainsi le temps système. Le code inline occupe réellement de la place, mais si la fonction est petite, il peut prendre moins de place que le code généré par un appel de fonction ordinaire (placer les arguments sur la pile et effectuer l'appel).

Une fonction inline dans un fichier d'en-tête a un statut spécial, puisque vous devez inclure le fichier d'en-tête contenant la fonction et sa définition dans tous les fichiers où la fonction est utilisée, mais vous ne vous retrouvez pas avec des erreurs de déclarations mutliples (toutefois, la déclaration doit être identique partout où la fonction inline est incluse).

9.2.1. Les inline dans les classes▲

//: C09:Inline.cpp
// Inlines inside classes
#include <iostream>
#include <string>
using namespace std;
 
class Point {
  int i, j, k;
public:
  Point(): i(0), j(0), k(0) {}
  Point(int ii, int jj, int kk)
    : i(ii), j(jj), k(kk) {}
  void print(const string& msg = "") const {
    if(msg.size() != 0) cout << msg << endl;
    cout << "i = " << i << ", "
         << "j = " << j << ", "
         << "k = " << k << endl;
  }
};
 
int main() {
  Point p, q(1,2,3);
  p.print("valeur de p");
  q.print("valeur de q");
} ///:~

9.2.2. Fonctions d'accès▲

//: C09:Access.cpp
// Fonctions d'accès inline
 
class Access {
  int i;
public:
  int read() const { return i; }
  void set(int ii) { i = ii; }
};
 
int main() {
  Access A;
  A.set(100);
  int x = A.read();
} ///:~

//: C09:Rectangle.cpp
// Accesseurs & muteurs
 
class Rectangle {
  int wide, high;
public:
  Rectangle(int w = 0, int h = 0)
    : wide(w), high(h) {}
  int width() const { return wide; } // lit
  void width(int w) { wide = w; } // assigne
  int height() const { return high; } // lit
  void height(int h) { high = h; } // assigne
};
 
int main() {
  Rectangle r(19, 47);
  // Modifie width & height:
  r.height(2 * r.width());
  r.width(2 * r.height());
} ///:~

//: C09:Rectangle2.cpp
// Accesseurs & muteurs avec "get" et "set"
 
class Rectangle {
  int width, height;
public:
  Rectangle(int w = 0, int h = 0)
    : width(w), height(h) {}
  int getWidth() const { return width; }
  void setWidth(int w) { width = w; }
  int getHeight() const { return height; }
  void setHeight(int h) { height = h; }
};
 
int main() {
  Rectangle r(19, 47);
  // Modifie width & height:
  r.setHeight(2 * r.getWidth());
  r.setWidth(2 * r.getHeight());
} ///:~

//: C09:Cpptime.h
// Une classe time simple 
#ifndef CPPTIME_H
#define CPPTIME_H
#include <ctime>
#include <cstring>
 
class Time {
  std::time_t t;
  std::tm local;
  char asciiRep[26];
  unsigned char lflag, aflag;
  void updateLocal() {
    if(!lflag) {
      local = *std::localtime(&t);
      lflag++;
    }
  }
  void updateAscii() {
    if(!aflag) {
      updateLocal();
      std::strcpy(asciiRep,std::asctime(&local));
      aflag++;
    }
  }
public:
  Time() { mark(); }
  void mark() {
    lflag = aflag = 0;
    std::time(&t);
  }
  const char* ascii() {
    updateAscii();
    return asciiRep;
  }
  // Différence en secondes:
  int delta(Time* dt) const {
    return int(std::difftime(t, dt->t));
  }
  int daylightSavings() {
    updateLocal();
    return local.tm_isdst;
  }
  int dayOfYear() { // Depuis le 1er janvier
    updateLocal();
    return local.tm_yday;
  }
  int dayOfWeek() { // Depuis dimanche
    updateLocal();
    return local.tm_wday;
  }
  int since1900() { // Année depuis 1900
    updateLocal();
    return local.tm_year;
  }
  int month() { // Depuis janvier
    updateLocal();
    return local.tm_mon;
  }
  int dayOfMonth() {
    updateLocal();
    return local.tm_mday;
  }
  int hour() { // Depuis minuit, 24 h pile
    updateLocal();
    return local.tm_hour;
  }
  int minute() {
    updateLocal();
    return local.tm_min;
  }
  int second() {
    updateLocal();
    return local.tm_sec;
  }
};
#endif // CPPTIME_H ///:~

//: C09:Cpptime.cpp
// Tester une classe time simple
#include "Cpptime.h"
#include <iostream>
using namespace std;
 
int main() {
  Time start;
  for(int i = 1; i < 1000; i++) {
    cout << i << ' ';
    if(i==0) cout << end1;
  }
 
  Time end;
  cout << endl;
  cout << "debut = " << start.ascii();
  cout << "fin = " << end.ascii();
  cout << "delta = " << end.delta(&start);
} ///:~

Armé des inlines, nous pouvons maintenant convertir les classes Stash et Stack pour être plus efficaces :

//: C09:Stash4.h
// Inline functions
#ifndef STASH4_H
#define STASH4_H
#include "../require.h"
 
class Stash {
  int size;      // Taille de chaque espace mémoire
  int quantity;  // Nombre d'espaces de stockage
  int next;      // Espace libre suivant
  // Tableau d'octets alloué dynamiquement:
  unsigned char* storage;
  void inflate(int increase);
public:
  Stash(int sz) : size(sz), quantity(0),
    next(0), storage(0) {}
  Stash(int sz, int initQuantity) : size(sz), 
    quantity(0), next(0), storage(0) { 
    inflate(initQuantity); 
  }
  Stash::~Stash() {
    if(storage != 0) 
      delete []storage;
  }
  int add(void* element);
  void* fetch(int index) const {
    require(0 <= index, "Stash::fetch (-)index");
    if(index >= next)
      return 0; // Pour indiquer la fin
    // Produit un pointeur vers l'élément désiré:
    return &(storage[index * size]);
  }
  int count() const { return next; }
};
#endif // STASH4_H ///:~

Les petites fonctions fonctionnent bien de toute évidence comme inline, mais remarquez que les deux plus grandes fonctions ne sont pas transformées en inline, étant donné que cela n'entraînerait probablement aucun gain de performance:

//: C09:Stash4.cpp {O}
#include "Stash4.h"
#include <iostream>
#include <cassert>
using namespace std;
const int increment = 100;
 
int Stash::add(void* element) {
  if(next >= quantity) // Assez d'espace libre ?
    inflate(increment);
  // Copie l'élément dans l'espace de stockage,
  // à partir du prochain espace libre:
  int startBytes = next * size;
  unsigned char* e = (unsigned char*)element;
  for(int i = 0; i < size; i++)
    storage[startBytes + i] = e[i];
  next++;
  return(next - 1); // Index
}
 
void Stash::inflate(int increase) {
  assert(increase >= 0);
  if(increase == 0) return;
  int newQuantity = quantity + increase;
  int newBytes = newQuantity * size;
  int oldBytes = quantity * size;
  unsigned char* b = new unsigned char[newBytes];
  for(int i = 0; i < oldBytes; i++)
    b[i] = storage[i]; // Copie l'ancien en nouveau
  delete [](storage); // Libère l'ancien espace de stockage
  storage = b; // Pointe vers la nouvelle mémoire
  quantity = newQuantity; // Ajuste la taille
} ///:~

Une fois de plus le programme de test vérifie que tout fonctionne correctement:

//: C09:Stash4Test.cpp
//{L} Stash4
#include "Stash4.h"
#include "../require.h"
#include <fstream>
#include <iostream>
#include <string>
using namespace std;
 
int main() {
  Stash intStash(sizeof(int));
  for(int i = 0; i < 100; i++)
    intStash.add(&i);
  for(int j = 0; j < intStash.count(); j++)
    cout << "intStash.fetch(" << j << ") = "
         << *(int*)intStash.fetch(j)
         << endl;
  const int bufsize = 80;
  Stash stringStash(sizeof(char) * bufsize, 100);
  ifstream in("Stash4Test.cpp");
  assure(in, "Stash4Test.cpp");
  string line;
  while(getline(in, line))
    stringStash.add((char*)line.c_str());
  int k = 0;
  char* cp;
  while((cp = (char*)stringStash.fetch(k++))!=0)
    cout << "stringStash.fetch(" << k << ") = "
         << cp << endl;
} ///:~

C'est le même programme de test que nous avons utilisé auparavant, donc la sortie devrait être fondamentalement la même.

La classe Stack fait même un meilleur usage des inline:

//: C09:Stack4.h
// With inlines
#ifndef STACK4_H
#define STACK4_H
#include "../require.h"
 
class Stack {
  struct Link {
    void* data;
    Link* next;
    Link(void* dat, Link* nxt): 
      data(dat), next(nxt) {}
  }* head;
public:
  Stack() : head(0) {}
  ~Stack() {
    require(head == 0, "Stack pas vide");
  }
  void push(void* dat) {
    head = new Link(dat, head);
  }
  void* peek() const { 
    return head ? head->data : 0;
  }
  void* pop() {
    if(head == 0) return 0;
    void* result = head->data;
    Link* oldHead = head;
    head = head->next;
    delete oldHead;
    return result;
  }
};
#endif // STACK4_H ///:~

Remarquez que le destructeur de Link qui était présent mais vide dans la version précédente de Stack a été supprimé. Dans pop( ), l'expression delete oldHead libère simplement la mémoire utilisée par Link(elle ne détruit pas l'objet data pointé par le Link).

La plupart des fonctions peuvent être rendues inline aisément, en particulier pour Link. Même pop( ) semble légitime, bien qu'à chaque fois que vous avez des variables conditionnelles ou locales il n'est pas évident que inline soit tellement profitable. Ici, la fonction est suffisamment petite pour que cela ne gêne probablement pas.

Si toutes vos fonctions sont inline, utiliser la librairie devient relativement simple parce qu'il n'y a pas besoin d'une édition de liens, comme vous pouvez le constater dans l'exemple test (remarquez qu'il n'y a pas de Stack4.cpp):

//: C09:Stack4Test.cpp
//{T} Stack4Test.cpp
#include "Stack4.h"
#include "../require.h"
#include <fstream>
#include <iostream>
#include <string>
using namespace std;
 
int main(int argc, char* argv[]) {
  requireArgs(argc, 1); // Le nom de fichier est l'argument
  ifstream in(argv[1]);
  assure(in, argv[1]);
  Stack textlines;
  string line;
  // Lire le fichier et stocker les lignes dans la pile :
  while(getline(in, line))
    textlines.push(new string(line));
  // Dépiler les lignes et les afficher:
  string* s;
  while((s = (string*)textlines.pop()) != 0) {
    cout << *s << endl;
    delete s; 
  }
} ///:~

Les gens écriront parfois des classes avec toutes les fonctions inline si bien que la classe sera entièrement dans le fichier d'en-tête (vous verrez dans ce livre que j'ai moi-même franchi cette limite). Pendant le développement c'est probablement sans conséquences, bien que cela puisse rendre la compilation plus longue. Une fois que le programme se stabilise un peu, vous aurez intérêt à revenir en arrière et rendre non inline les fonctions appropriées.

Pour comprendre quand la déclaration inline est efficace, il est utile de savoir ce que le compilateur fait quand il rencontre un inline. Comme avec n'importe quelle fonction, le compilateur détient le type de la fonction (c'est-à-dire, le prototype de la fonction incluant le nom et le type des arguments, combinés à la valeur de retour de la fontion) dans sa table des symboles. En outre, quand le compilateur voit que le type de la fonction inline et le corps de la fonction s'analysent sans erreur, le code du corps de la fonction est également amené dans la table des symboles. Que ce code soit stocké sous forme source, d'instructions assembleur compilées, ou tout aute représentation est du ressort du compilateur.

Quand vous faites un appel à une fonction inline, le compilateur s'assure tout d'abord que l'appel peut être correctement effectué. C'est-à-dire que soit les types des arguments passés doivent correspondre exactement aux types de la liste des arguments de la fonction, soit le compilateur doit être capable de faire une conversion vers le type correct, et la valeur de retour doit être du bon type (ou une conversion vers le bon type) dans l'expression de destination. Ce processus, bien sûr, est exactement ce que fait le compilateur pour n'importe quelle fonction et est nettement différent de ce que le préprocesseur réalise parce que le préprocesseur ne peut pas vérifier les types ou faire des conversions.

Si toutes les informations de type de la fonction s'adaptent bien au contexte de l'appel, alors le code inline est substitué directement à l'appel de la fonction, éliminant le surcoût de temps de l'appel et permettant davantage d'optimisations par le compilateur. Egalement, si le inline est une fonction membre, l'adresse de l'objet ( this) est placé aux endroit appropriés, ce qui constitue bien sûr une autre opération dont le préprocesseur est incapable.

9.4.1. Limitations▲

9.4.2. Déclarations aval▲

//: C09:EvaluationOrder.cpp
// Ordre d'évaluation de inline
 
class Forward {
  int i;
public:
  Forward() : i(0) {}
  // Appel à une fonction non déclarée:
  int f() const { return g() + 1; }
  int g() const { return i; }
};
 
int main() {
  Forward frwd;
  frwd.f();
} ///:~

9.4.3. Activités cachées dans les constructeurs et les destructeurs▲

//: C09:Hidden.cpp
// Activités cachées dans les inline
#include <iostream>
using namespace std;
 
class Member {
  int i, j, k;
public:
  Member(int x = 0) : i(x), j(x), k(x) {}
  ~Member() { cout << "~Member" << endl; }
};
 
class WithMembers {
  Member q, r, s; // Ont des constructeurs
  int i;
public:
  WithMembers(int ii) : i(ii) {} // Trivial?
  ~WithMembers() {
    cout << "~WithMembers" << endl;
  }
};
 
int main() {
  WithMembers wm(1);
} ///:~

Dans un livre comme celui-ci, la simplicité et la concision des définitions de fonctions inline dans les classes est très utile parce qu'on peut en mettre davantage sur une page ou un écran (pour un séminaire). Toutefois, Dan Saks (46)a souligné que dans un projet réel cela a l'effet de rendre l'interface de la classe inutilement fouillis et ainsi de la rendre plus difficile à utiliser. Il fait référence aux fonctions membres définies dans les classes par l'expression latine in situ(sur place) et affirme que toutes les définitions devraient être maintenues en dehors de la classe pour garder l'interface propre. Il soutient que l'optimisation est un problème séparé. Si vous voulez optimiser, utilisez le mot-clef inline. En appliquant cette approche, Rectangle.cpp vu précédemment devient:

//: C09:Noinsitu.cpp
// Supprimer les fonctions in situ
 
class Rectangle {
  int width, height;
public:
  Rectangle(int w = 0, int h = 0);
  int getWidth() const;
  void setWidth(int w);
  int getHeight() const;
  void setHeight(int h);
};
 
inline Rectangle::Rectangle(int w, int h)
  : width(w), height(h) {}
 
inline int Rectangle::getWidth() const {
  return width;
}
 
inline void Rectangle::setWidth(int w) {
  width = w;
}
 
inline int Rectangle::getHeight() const {
  return height;
}
 
inline void Rectangle::setHeight(int h) {
  height = h;
}
 
int main() {
  Rectangle r(19, 47);
  // Transpose width & height:
  int iHeight = r.getHeight();
  r.setHeight(r.getWidth());
  r.setWidth(iHeight);
} ///:~

A présent, si vous voulez comparer les effets des fonctions inline aux fonctions non inline, vous pouvez simplement supprimer le mot-clef inline. (Toutefois les fonctions inline devraient normalement être placées dans des fichiers d'en-tête tandis que les fonctions non inline devraient être situées dans leur propre unité de traduction.) Si vous voulez mettre les fonctions dans la documentation, une simple opération de couper-coller suffit. Les fonctions in situ requièrent plus de travail et présentent plus de risques d'erreurs. Un autre argument en faveur de cette approche est que vous pouvez toujours produire un style de formatage cohérent pour les définitions de fonctions, ce qui n'est pas toujours le cas avec les fonctions in situ.

Un peu plus tôt, j'ai dit que vous avez presque toujours intérêt à utiliser des fonctions inline à la place des macros du préprocesseur. Les exceptions à cette règle sont quand vous avez besoin de trois caractéristiques spéciales du préprocesseur C (qui est également le préprocesseur du C++) : le chaînage, la concaténation de chaîne et le collage de jetons. Le chaînage, déjà introduit dans ce livre, est réalisé avec la directive # et vous permet de prendre un identifiant et de le transformer en tableau de caractères. La concaténation de chaîne a lieu quand deux tableaux de caractères adjacents n'ont pas d'intervalle de ponctuation, auquel cas ils sont combinés. Ces deux caractéristiques sont particulièrement utiles quand on écrit du code pour débugger. Ainsi,

#define DEBUG(x) cout << #x " = " << x << endl

Ceci affiche la valeur de n'importe quelle variable. Vous pouvez aussi obtenir une trace qui imprime les instructions au fur et à mesure de leur exécution :

#define TRACE(s) cerr << #s << endl; s

Le #s transforme l'instruction en tableau de caractères pour la sortie, et le deuxième s réitère l'instruction afin qu'elle soit exécutée. Bien sûr, ce genre de chose peut poser des problèmes, particulièrement dans des boucles for d'une ligne:

for(int i = 0; i < 100; i++)
 TRACE(f(i));

Comme il y a en fait deux instructions dans la macro TRACE( ), la boucle for d'une ligne exécute seulement la première. La solution est de remplacer le point-virgule par une virgule dans la macro.

9.6.1. Collage de jeton▲

#define FIELD(a) char* a##_string; int a##_size
class Record {
  FIELD(one);
  FIELD(two);
  FIELD(three);
  // ...
};

Les fonctions de require.h ont été utilisées jusque là sans les définir (bien que assert( ) ait été également utilisée pour aider à la détection des erreurs du programmeur quand approprié). Il est temps, maintenant, de définir ce fichier d'en-tête. Les fonctions inlines sont commodes ici parce qu'elles permettent de tout mettre dans un fichier d'en-tête, ce qui simplifie l'utilisation du package. Vous incluez simplement le fichier d'en-tête et vous n'avez pas à vous en faire à propos de l'édition des liens et du fichier d'implémentation.

Vous devriez noter que les exceptions (présentées en détail dans le deuxième volume de cet ouvrage) procure une manière bien plus efficace de gérer beaucoup de types d'erreurs - spécialement celles dont vous voudriez pouvoir récupérer - plutôt que de simplement arrêter le programme. Les conditions que gère require.h, toutefois, empêchent le programme de se poursuivre, par exemple si l'utilisateur ne fournit pas pas suffisamment d'arguments dans la ligne de commande ou si un fichier ne peut pas être ouvert. Ainsi, il est raisonnable qu'elles appellent la fonction de la librairie C standard exit( ).

Le fichier d'en-tête suivant se trouve dans le répertoire racine du livre et on peut donc y accéder facilement depuis tous les chapitres.

//: :require.h
// Teste les conditions d'erreur dans les programmes
// "using namespace std" local pour les vieux compilateurs
#ifndef REQUIRE_H
#define REQUIRE_H
#include <cstdio>
#include <cstdlib>
#include <fstream>
#include <string>
 
inline void require(bool requirement, 
  const std::string& msg = "Requirement failed"){
  using namespace std;
  if (!requirement) {
    fputs(msg.c_str(), stderr);
    fputs("\n", stderr);
    exit(1);
  }
}
 
inline void requireArgs(int argc, int args, 
  const std::string& msg = 
    "Must use %d arguments") {
  using namespace std;
   if (argc != args + 1) {
     fprintf(stderr, msg.c_str(), args);
     fputs("\n", stderr);
     exit(1);
   }
}
 
inline void requireMinArgs(int argc, int minArgs,
  const std::string& msg =
    "Must use at least %d arguments") {
  using namespace std;
  if(argc < minArgs + 1) {
    fprintf(stderr, msg.c_str(), minArgs);
    fputs("\n", stderr);
    exit(1);
  }
}
 
inline void assure(std::ifstream& in, 
  const std::string& filename = "") {
  using namespace std;
  if(!in) {
    fprintf(stderr, "Could not open file %s\n",
      filename.c_str());
    exit(1);
  }
}
 
inline void assure(std::ofstream& out, 
  const std::string& filename = "") {
  using namespace std;
  if(!out) {
    fprintf(stderr, "Could not open file %s\n", 
      filename.c_str());
    exit(1);
  }
}
#endif // REQUIRE_H ///:~

Les valeurs par défaut fournissent des messages raisonnables, qui peuvent être modifiés si besoin est.

Vous remarquerez qu'au lieu d'utiliser des arguments char*, on utilise des arguments const string&. Ceci permet l'utilisation de char* et de string comme arguments de ces fonctions, et est donc utilisable plus largement (vous pouvez avoir intérêt à adopter cette forme dans votre propre code).

Dans les définitions de requireArgs( ) et requireMinArgs( ), le nombre d'arguments nécessaires sur la ligne de commande est augmenté de un parce que argc inclue toujours le nom du programme en cours d'exécution comme argument zéro, et a donc toujours une taille supérieure d'un argument au nombre d'arguments passés en ligne de commande.

Remarquez l'utilisation locale de “ using namespace std” dans chaque fonction. Ceci est dû au fait que certains compilateurs au moment de la rédaction de cet ouvrage n'incluaient pas - improprement - la bibliothèque de fonctions standards du C dans namespace std, si bien qu'une qualification explicite causerait une erreur à la compilation. Les déclarations locales permettent à require.h de travailler avec les deux types de biliothèques, correctes et incorrectes, sans ouvrir l'espace de nommage std à la place de quiconque incluant ce fichier en-tête.

Voici un programme simple pour tester require.h:

//: C09:ErrTest.cpp
//{T} ErrTest.cpp
// Teste require.h
#include "../require.h"
#include <fstream>
using namespace std;
 
int main(int argc, char* argv[]) {
  int i = 1;
  require(i, "value must be nonzero");
  requireArgs(argc, 1);
  requireMinArgs(argc, 1);
  ifstream in(argv[1]);
  assure(in, argv[1]); // Utilise le nom de fichier
  ifstream nofile("nofile.xxx");
  // Echoue :
//!  assure(nofile); // L'argument par défaut
  ofstream out("tmp.txt");
  assure(out);
} ///:~

Vous pourriez être tenté de faire un pas de plus pour l'ouverture de fichiers et d'ajouter une macro à require.h:

#define IFOPEN(VAR, NAME) \
  ifstream VAR(NAME); \
  assure(VAR, NAME);

Qui pourrait alors être utilisée comme ceci :

IFOPEN(in, argv[1])

Au premier abord, cela peut paraître intéressant puisque cela signifie qu'il y a moins de choses à taper. Ce n'est pas trop dangereux, mais c'est un chemin sur lequel il vaut mieux éviter de s'engager. Remarquez que, encore une fois, une macro ressemble à une fonction mais se comporte différemment ; elle crée en fait un objet ( in) dont la portée persiste au-delà de la macro. Peut-être comprenez-vous la situation, mais pour de nouveaux programmeurs et pour ceux qui maintiennent le code, cela constitue une énigme supplémentaire à résoudre. Le C++ est suffisamment compliqué pour qu'il n'y ait pas besoin d'ajouter à la confusion. Essayez donc de vous convaincre vous-même de ne pas utiliser les macros du préprocesseur si elles ne sont pas indispensables.

Il est critique que vous soyez capables de cacher l'implémentation sous-jacente d'une classe parce que vous pourriez vouloir modifier cette implémentation ultérieurement. Vous effectuerez ces changements pour des raisons d'efficacité, ou parce que vous aurez une meilleure compréhension du problème, ou parce qu'une nouvelle classe est devenue disponible et que vous voulez l'utiliser dans l'implémentation. Tout élément qui porte atteinte au caractère privé de l'implémentation sous-jacente réduit la flexibilité du langage. Ainsi, la fonction inline et très importante parce qu'elle élimine virtuellement le besoin de macros du préprocesseur et les problèmes qui y sont liés. Avec les inlines, les fonctions membres peuvent être aussi efficaces que les macros du préprocesseur.

On peut abuser de la fonction inline dans les définitions de classes, bien sûr. Le programmeur est tenté de le faire parce que c'est plus facile, et donc cela se produira. Toutefois, ce n'est pas un si gros problème par la suite, quand vous cherchez à réduire la taille, car vous pouvez toujours rendre les fonctions non inline sans effet sur leur fonctionnalité. La ligne conductrice de la programmation devrait être : “faites le fonctionner d'abord, optimisez-le ensuite”.

Les solutions à certains exercices peuvent être trouvées dans le document électronique The Thinking in C++ Annotated Solution Guide, disponible pour une somme modique sur www.BruceEckel.com.

1. Ecrivez un programme qui utilise la macro F( ) montrée au début du chapitre et montrez qu'il ne se développe pas proprement, comme décrit dans le texte. Réparez la macro et montrez qu'elle fonctionne correctement.
2. Ecrivez un programme qui utilise la macro FLOOR( ) montrée au début du chapitre. Montrez les conditions sous lesquelles il ne fonctionne pas proprement.
3. Modifiez MacroSideEffects.cpp afin que BAND( ) fonctionne bien.
4. Créez deux fonctions identiques, f1( ) et f2( ). Rendez f1( ) inline, mais pas f2( ). Utilisez la fonction clock( ) de la bibliothèque standard du C qui se trouve dans <ctime> pour noter les moments de début et de fin et comparez les deux fonctions pour voir laquelle est la plus rapide. Vous pourriez avoir besoin de faire plusieurs appels aux fonctions au sein de vos boucles de chronométrage pour obtenir des valeurs significatives.
5. Faites varier la complexité du code dans les fonctions de l'exercice 4 pour voir si vous pouvez trouver le point d'équilibre où les deux fonctions prennent le même temps. Si vous en disposez, essayez de le faire avec différents compilateurs et notez les différences.
6. Montrez quelles fonctions inline font appel par défaut à la liaison interne.
7. Créez une classe qui contienne un tableau de char. Ajoutez un constructeur inline qui utilise la fonction memset( ) de la bibliothèque standard du C pour initialiser le tableau à l'argument du constructeur (par défaut, faites en sorte que ce soit ‘ '), ajoutez une fonction membre inline appelée print( ) pour afficher tous les caractères du tableau.
8. Prenez l'exemple NestFriend.cpp du chapitre 5 et remplacez toutes les fonctions membres avec des inline. Faites des fonctions inline qui ne soient pas in-situ. Convertissez également les fonctions initialize( ) en constructeurs.
9. Modifiez StringStack.cpp du Chapitre 8 pour utiliser des fonctions inline.
10. Créez un enum appelé Hue contenant red, blue, et yellow. A présent, créez une classe appelée Color contenant une donnée membre de type Hue et un constructeur qui affecte le Hue à la valeur de son argument. Ajoutez des fonctions d'accès “get” et “set” pour lire et fixer le Hue. Rendez toutes ces fonctions inline.
11. Modifiez l'exercice 10 pour utiliser l'approche “accesseur” et “muteur”.
12. Modifiez Cpptime.cpp de façon à ce qu'il mesure le temps qui sépare le démarrage du programme de l'instant où l'utilisateur tape la touche “Entrée”.
13. Créez une classe avec deux fonctions inline, de façon à ce que la première fonction qui est définie dans la classe appelle la deuxième, sans qu'il y ait besoin d'une déclaration anticipée. Ecrivez un main qui crée un objet de la classe et appelle la première fonction.
14. Créez une classe A avec un constructeur par défaut inline qui s'annonce lui-même. Puis créez une nouvelle classe, B et placez un objet A comme membre de B, et donnez à B un constructeur inline. Créez un tableau d'objets B et voyez ce qu'il se produit.
15. Créez un grand nombre d'objets de l'exercice précédent et utilisez la classe Time pour chronométrer la différence entre constructeurs inline ou non. (Si vous disposez d'un profiler, essayez de l'utiliser également.)
16. Ecrivez un programme qui prend une string comme argument en ligne de commande. Ecrivez une boucle for qui supprime un caractère de la string à chaque passage, et utilisez la macro DEBUG( ) de ce chapitre pour imprimer la string à chaque fois.
17. Corrigez la macro TRACE( ) comme spécifié dans ce chapitre, et prouvez qu'elle focntionne correctement.
18. Modifiez la macro FIELD( ) afin qu'elle contienne également un nombre index. Créez une classe dont les membres sont composés d'appels à la macro FIELD( ). Ajoutez une fonction membre qui vous permette de consulter un champ en utilisant son numéro d'index. Ecrivez un main( ) pour tester la classe.
19. Modifiez la macro FIELD( ) afin qu'elle génère automatiquement des fonctions d'accès pour chaque champ (les données devraient toutefois toujours être privées). Créez une classe dont les fonctions membres sont composées d'appels à la macro FIELD( ). Ecrivez un main( ) pour tester la classe.
20. Ecrivez un programme qui prenne deux arguments en ligne de commande : le premier est un int et le second un nom de fichier. Utilisez require.h pour garantir que vous avez le bon nombre d'arguments, que le int est compris entre 5 et 10, et que le fichier peut être ouvert avec succès.
21. Ecrivez un programme qui utilise la macro IFOPEN( ) pour ouvrir un fichier comme input stream. Notez la création de l'objet ifstream et sa portée.
22. (Difficile) Trouvez comment faire générer du code assembleur par votre compilateur. Créez un fichier contenant une très petite fonction et un main( ) qui appelle la fonction. Générez le code assembleur quand la fonction est inline ou ne l'est pas, et montrez que la version inline n'a pas le surcoût de temps associé à l'appel.