Guru Of the Week n° 46 : typedef

Des noms plus courts sont plus faciles à entrer au clavier.

Typedefs peut rendre les codes plus faciles à lire, en particulier les noms de types de templates particulièrement longs. Pour un exemple simple, considérez ce qui suit issu d'un message d'une messagerie publique demandant ce que ce code signifie :

    int ( *t(int) )( int* );

Si vous avez l'habitude de lire des déclarations C comme si c'était un roman victorien (une prose dense et verbeuse qui parfois semble donner pédaler dans la semoule), vous connaissez la réponse et c'est bien. Si ce n'est pas le cas, typedefs vous aidera, même avec un nom typedef aussi insignifiant que "Func" :

    typedef int (*Func)( int* );
    Func t( int );

à présent, il est clair que c'est une déclaration de fonction pour une fonction appelée "t" qui saisit un entier et retourne un pointeur sur une fonction qui saisit un entier* et retourne un entier (dites-le trois fois très vite). Dans ce cas, le typedef est plus facile à lire que le français.

Typedefs peut aussi ajouter une signification sémantique. Par exemple, "PhoneBook" est beaucoup plus facile à comprendre que "map< string, string>" (qui pourrait signifier n'importe quoi !)

Si vous utilisez des noms traités par typedefs pour des noms spécifiques d'une plateforme ou non portables autrement, il vous sera plus facile de passer à de nouvelles plateformes. Après tout, il est plus facile d'écrire ceci :

    #if defined USING_COMPILER_A
      typedef __int32 Int32;
      typedef __int64 Int64;
    #elif defined USING_COMPILER_B
      typedef int       Int32;
      typedef long long Int64;
    #endif

que de chercher et remplacer un des noms spécifiques du système dans tout votre code. Les noms typedef vous protègent des dépendances envers des plateformes uniques.

Changer un nom typedef à un endroit est plus facile que changer toutes ses utilisations dans tout le code. Par exemple, considérez le code suivant :

    void f( vector<Customer>& vc ) {
      vector<Customer>::iterator i = vc.begin();
      ...
    }

Que se passera-t-il si quelques mois plus tard, vous découvrez que le vecteur n'est pas le bon container ? Si vous conservez un grand nombre d'objets Clients, le fait que le stockage des vecteurs soit contigu[1] peut être un désavantage et peut-être préfèrerez-vous un deque à la place. Ou bien, si vous insérez/enlevez fréquemment des éléments au milieu, vous préfèrerez une liste.

Dans le code ci-dessus, vous auriez à opérer ce changement partout où apparaît "vector<Customer>". Ce serait tellement plus facile si vous aviez seulement écrit :

    typedef vector<Customer> Customers;

    ...

    void f( Customers& vc ) {
      Customers::iterator i = vc.begin();
      ...
    }

Vous n'auriez à changer que le typedef en list<Customer> ou deque<Customer> ! Ce n'est pas toujours aussi facile - par exemple, il se pourrait que votre code repose sur un Customers::iterator itérateur à accès libre, ce que n'est pas un list<Customer::iterator - mais cela vous protège d'un grand nombre de changements qui seraient ennuyeux autrement.

Les traits sont une façon efficace d'associer les informations à un type, et si vous voulez personnaliser des containers ou des algorithmes standards, il vous faudra souvent fournir des traits. Considérez l'exemple de chaîne sensible à la casse dans GotW n°29, où nous avions défini notre propre remplacement char_traits.

La plupart des utilisations de typedef entrent dans l'une de ces catégories.