L’allocation dynamique c’est facile: pour un new, un delete

Le quidam du coin.

Pour 12 opérateurs new, 14 opérateurs delete.

La norme de C++11.

Mmmh, va pour 16 opérateurs delete.

C++14.

Finalement 22 opérateurs new et 26 opérateurs delete.

L’apparition de C++17.

Allez, 30 opérateurs delete.

Toujours plus loin avec C++20.

Cet article va parler des opérateurs new et delete. Pas les mots clefs new et delete tout seuls, mais bien de operator new et operator delete de l’en-tête <new>, car derrière les mots clefs usuels se cachent en réalité beaucoup de fonctions surchargées. Soit appelées implicitement par le compilateur, soit explicitement par le développeur en donnant des paramètres à new.

Bien sûr, ce sont des techniques très bas niveau liées à l’allocation dynamique, à moins de vouloir écrire un allocateur global, il est probable que vous n’en ayez jamais besoin. Je vais néanmoins présenter ici les différents opérateurs existant dans le standard et à quel moment ils sont utilisés.

La première chose à faire est de distinguer le mot clef new traditionnellement utilisé de la fonction operator new() se trouvant dans l’en-tête <new>. L’expression new T fait en réalité 2 choses:

• Allouer une zone mémoire en utilisant operator new().
• Construire le type T dans la zone mémoire préalablement allouée (appel du constructeur).

Ces 2 étapes peuvent se faire manuellement en utilisant explicitement un opérateur new suivi d’un placement-new qui appelle un opérateur new spécifique.

new utilise new et 2 operator new, il y a de quoi s’y perdre :).

void* mem = operator new(sizeof(T)); // on alloue une mémoire pouvant contenir un T
T* p = new(mem) T(); // on construit un T dans la zone allouée
                     // ceci n'effectue aucune allocation dynamique

Il existe la même symétrie avec l’expression delete qui utilise le destructeur suivi d’une libération de la mémoire.

p->~T(); // appel explicite du destructeur
operator delete(p); // libération de la mémoire

Ceci représente le cas de base pour une gestion plus fine de la mémoire. Pour information, c’est une partie de ce qu’utilisent les containers de la STL tel que std::vector à travers les allocateurs (std::allocator). Une partie seulement, car C++17 ajoute un paramètre d’alignement.

Tous les opérateurs new et presque tous les opérateurs delete sont séparés en 2 catégories: une version tableau et une version sans.

Par exemple void* operator new(std::size_t) et void *operator new[](std::size_t). À part les 4 nouveaux opérateurs delete de C++20, il n’y a pas d’exception.

Il y a néanmoins une différence de comportement avec les operator new[]: La taille nécessaire à leur allocation peut être supérieure à sizeof(T) * len. Il y a un surplus permettant de stocker la taille du tableau et ainsi appeler le bon nombre de destructeurs au moment du delete[]. Cet ajout est automatiquement fait par le compilateur et dépend de son implémentation.

Toute la suite de l’article ne présentera plus les versions tableaux, car le principe derrière est exactement le même que les versions sans tableau.

Plus que 11 opérateurs new et 17 delete :)

Parmi les opérateurs disponibles, il existe 16 fonctions candidates au remplacement de la fonction d’allocation. C’est-à-dire qu’utiliser new T/new T[n] ou delete p/delete[] p va implicitement faire appel à l’une de ces fonctions que l’utilisateur peut lui-même définir pour changer le comportement par défaut.

La version operator new, en plus du paramètre std::size_t count représentant le nombre d’octets à allouer, prend 2 paramètres optionnels:

• std::nothrow_t qui représente l’absence d’exception et
• std::align_val_t qui indique l’alignement de l’allocation.

void* operator new(std::size_t count);
void* operator new(std::size_t count, std::align_val_t al);
void* operator new(std::size_t count, const std::nothrow_t&) noexcept;
void* operator new(std::size_t count, std::align_val_t al, const std::nothrow_t&) noexcept;
// plus version new[]

Le paramètre std::nothrow_t s’utilise pour un new de la forme new(std::nothrow) T. Cela ne veut pas dire qu’il n’y aura jamais d’exception (le constructeur de T peut le faire), mais que l’allocation de l’espace mémoire nécessaire ne le fera pas. Si l’allocation échoue, un pointeur nul est retourné.

std::align_val_t fait référence aux types dont l’alignement est supérieur à __STDCPP_DEFAULT_NEW_ALIGNMENT__ et sera alors automatiquement ajouté par le compilateur. Cela dépend des implémentations, mais cette valeur devrait être au moins de la taille du plus grand type disponible, à priori long double.

En supposant que __STDCPP_DEFAULT_NEW_ALIGNMENT__ fait 16, pour utiliser la version new avec alignement, il faudrait un type tel que struct alignas(32) A {};.

Ensuite vient operator delete qui, à la place d’une taille, prend le pointeur à libérer.

void operator delete(void* ptr) noexcept;
void operator delete(void* ptr, std::align_val_t al) noexcept;
void operator delete(void* ptr, const std::nothrow_t&) noexcept;
void operator delete(void* ptr, std::align_val_t al, const std::nothrow_t&) noexcept;
void operator delete(void* ptr, std::size_t sz) noexcept;
void operator delete(void* ptr, std::size_t sz, std::align_val_t al) noexcept;
// plus version delete[]

Et les ennuis commencent. Il y a bien une correspondance 1-1, mais 2 fonctions prenant un std::size_t sz se sont subtilement ajoutées.

Le paramètre sz ajouté en C++14 correspond à la taille de l’objet libéré. Néanmoins, les 2 fonctions avec ce paramètre peuvent ne pas être utilisées pour les types trivialement destructibles ou incomplets. Dans ce cas, ce sont les versions sans ce paramètre qui seront utilisées. Actuellement, gcc utilise bien les fonctions avec le paramètre sz à partir de C++14, mais il faut le forcer avec -fsized-deallocation pour les standards inférieurs. Pour clang, ce flag est requis quel que soit le standard utilisé.

Les versions avec std::nothrow_t sont utilisées lorsque le constructeur de T dans l’expression new(std::nothrow) T jette une exception. Dans ce cas, l’exception est relancée après libération de la mémoire.

Peut-on faire une quelconque différence d’implémentation entre les delete qui prennent des std::nothrow_t et ceux qui ne les prennent pas ? Je ne pense pas, je n’arrive pas à imaginer un tel scénario.

Étrangement, il n’y a pas de prototype qui utilise en même temps sz et std::nothrow_t, alors que l’information de taille pourrait être utilisée pour accélérer certaines désallocations.

Encore 7 opérateurs new et 11 delete.

Le placement-new est ce qui permet de construire un objet depuis une zone mémoire préalablement réservée. Soit via un tableau statique, soit à travers une allocation dynamique.

alignas(T) char buffer[sizeof(T)];
T* p = new(buffer) T; // construction de T

La destruction de cet objet se fait manuellement via un appel direct du destructeur (p->~T()) puis en libérant le buffer si nécessaire.

Cet appel à new correspond au prototype ci-dessous dont l’implémentation est prédéfinie par la bibliothèque standard:

void* operator new(std::size_t count, void* ptr) noexcept;
// + version new[]

Néanmoins, il est possible de surcharger cette fonction pour y introduire n’importe quel paramètre:

void* operator new(std::size_t count, user-defined-args...);
void* operator new(std::size_t count, std::align_val_t al, user-defined-args...);
// + version new[]

count correspond au sizeof de T et la version avec alignement sera automatiquement utilisée si définie et que l’alignement de T dépasse __STDCPP_DEFAULT_NEW_ALIGNMENT__. Dans le cas contraire, le compilateur se rabat sur celle sans alignement.

T* p = new(storage, opt) T; // pourrait correspondre à operator new(std::size_t count, Storage&, StorageOptions)
                            // et operator new(std::size_t count, std::align_val_t al, Storage&, StorageOptions)

Chacun de ses new a son équivalent delete dans le cas où le constructeur lance une exception.

La version de la bibliothèque standard qui ne fait normalement rien:

void operator delete(void* ptr, void* place) noexcept;
// + version delete[]

Et les surcharges utilisateur:

void operator delete(void* ptr, user-defined-args...);
void operator delete(void* ptr, std::align_val_t al, user-defined-args...);

cppreference.com ne fait pas explicitement mention de la version avec std::align_val_t, mais je l’ajoute pour une meilleure correspondance avec les prototypes de new.

On peut sérieusement se demander à quoi peut servir ces opérateurs prenant n’importe quel type, alors qu’ils pourraient très bien être remplacés par une fonction classique. Une fonction est beaucoup moins tordue que new(a,b,c) T.

Plus que 4 opérateurs new et 9 delete.

Jusqu’ici, tous les opérateurs étaient des fonctions libres qui ne peuvent avoir connaissance du type réellement alloué. Il est possible d’avoir cette information en déclarant les opérateurs new et delete en membre statique d’une classe. Les versions membres seront prioritaires à celles libres.

void* T::operator new(std::size_t count);
void* T::operator new(std::size_t count, std::align_val_t al);
void* T::operator new(std::size_t count, user-defined-args...);
void* T::operator new(std::size_t count, std::align_val_t al, user-defined-args...);
// + version new[]

void T::operator delete(void* ptr) noexcept;
void T::operator delete(void* ptr, std::align_val_t al) noexcept;
void T::operator delete(void* ptr, std::size_t sz) noexcept;
void T::operator delete(void* ptr, std::size_t sz, std::align_val_t al) noexcept;
void T::operator delete(void* ptr, args...) noexcept;
// + version delete[]

Le nombre de prototypes est inférieur au nombre de fonctions libres, mais il est tout à fait possible de les réintroduire via les types utilisateurs.

Petite particularité des opérateurs membres: il est possible d’interdire les allocations dynamiques en supprimant la fonction avec void* operator new(std::size_t count) = delete. On peut cependant outrepasser cette restriction en utilisant l’opérateur global avec ::new T.

Bientôt la fin, il ne reste que 4 opérateurs delete.

En début d’article, j’indique que la construction d’un objet se fait en 4 étapes représentées par 4 appels de fonctions consécutives:

• Allocation de la mémoire
• Construction de l’objet dans la mémoire allouée
• Appel du destructeur
• Libération de la mémoire

C++20 introduit 4 opérateurs delete qui doivent eux-mêmes faire l’appel du destructeur en plus de la libération.

void T::operator delete(T* ptr, std::destroying_delete_t);
void T::operator delete(T* ptr, std::destroying_delete_t, std::align_val_t al);
void T::operator delete(T* ptr, std::destroying_delete_t, std::size_t sz);
void T::operator delete(T* ptr, std::destroying_delete_t, std::size_t sz, std::align_val_t al);
// pas de version delete[] à cause de l'overhead ajouté par le compilateur pour new[]

On y retrouve al et sz qui suivent les mêmes règles que d’habitude et un type std::destroying_delete_t qui permet une différenciation avec les autres fonctions.

Les raisons de cet ajout sont expliquées dans la proposition P0722 qui corrige les sized-delete avec des classes à taille variable (entre autres).

Pour expliquer le fonctionnement, une classe à taille variable n’est constructible qu’à travers une allocation dynamique de la mémoire ; son allocation contient un surplus de taille contenant la partie variable. Par exemple, une string peut être un segment contenant la taille suivie des chars. Tout cela dans le même segment de donnée. Comme la partie variable n’est pas dans l’objet lui-même, un sizeof de ce type de chaîne correspond à la taille de son seul membre: std::size_t length (par exemple). Les données variables sont ensuite accessibles via reinterpret_cast<char*>(this + 1). On peut retrouver la même chose avec des données variables insérées avant le pointeur de l’objet.

Le problème de ce type de classe apparaît au moment de la libération: comment utiliser l’opérateur delete prenant une taille ou un alignement quand ces 2 informations ne font pas partie du type ? Celui introduit par le compilateur sera erroné. Ou encore, comment récupérer le pointeur d’origine lorsque les données sont insérées avant le type utlisé ?

Dans le premier scénario, une solution (fausse) est de récupérer cette information depuis la fonction void T::operator delete(void* ptr) en castant ptr en type T pour y extraire les informations nécessaires. Malheureusement, ptr représente un T détruit (destructeur utilisé): lire ses membres est invalide.

Pour pallier à tous ces problèmes, les opérateurs delete introduits en C++20 prennent non plus un void* ptr, mais un T* ptr encore valide. C’est pour cette raison que cette fonction doit elle-même appeler le destructeur.

Quant au pointeur alloué, il peut vivre sa vie comme n’importe quel pointeur et être utilisé dans – par exemple – un std::unique_ptr.

L’allocateur global est plutôt facile à remplacer, mais seuls les opérateurs considérés comment remplaçables pourront être utilisés de manière transparente. Cela exclut les new/delete avec des variables utilisateurs dont les prototypes doivent être connus par le programme qui les utilise.

Pour ce faire, il suffit de compiler un .cpp qui contient les opérateurs pour en faire soit un .o, soit une bibliothèque. Dans les 2 cas, le bout de code sera compilé dans l’exécutable final.

Dans le cas d’une bibliothèque externe, il est possible de la charger « plus tard » via les méthodes propres à chaque système d’exploitation. Par exemple, les variables d’environnement LD_PRELOAD et LD_LIBRARY_PATH pour Linux.

L’objectif derrière la sémantique de déplacement est de transférer les données d’un objet A à un objet B. Si les 2 objets sont du même type, on parle de constructeur de déplacement ou affectation par déplacement. Cela permet 2 choses:

• Garantir l’unicité d’une ressource. La responsabilité étant passée à quelqu’un d’autre, il n’y a toujours qu’un seul propriétaire en charge de la durée de vie de celle-ci.
• Éviter des copies profondes (deep copies) en les remplaçant par des copies superficielles (shallow copies) plus performantes.

Toute autre raison est une erreur.

Prenons un petit animal sauvage et nommons-le Pikachu. Ce Pikachu est unique, il n’en existe qu’un seul dans tout l’univers. Si on compare notre Pikachu à un autre Pikachu, ils sont différents, il n’y en a pas 2 pareils, même s’ils ont le même nom.

Rangeons-le dans sa pokéball.

std::vector<Pokemon> my_bag;
my_bag.emplace_back("Pikachu");

Un soir, au coin du feu, un brigand passe par là et prend notre sac.

brigand.bag = my_bag;

Et tout l’univers est sans dessus-dessous, notre Pikachu existe en double, le principe d’unicité est brisé !

Heureusement, Pokemon n’étant pas copiable, le code ne compile pas. Ouf, l’univers est sauf !

Du coup, plutôt que copier le sac, on le déplace directement dans celui de brigand en utilisant la fonction std::move.

brigand.bag = std::move(my_bag);

Au passage, on vient d’écraser tout ce qu’il y avait dans le sac de notre voleur ; bien fait pour lui ! Mais le plus important est là: Pikachu appartient maintenant au brigand, my_bag ne devrait plus être utilisé. On a bien eu un transfert des pokémons d’un sac A vers un sac B, il y a eu déplacement.

La copie profonde est une copie de tous les membres, y compris des données référencées par un pointeur lorsque leur durée de vie est gérée par la classe. Ce dernier point est important, car sans pointeur – et pour aller plus loin, sans ressource, – il n’y a pas de différence entre une copie classique ou une copie superficielle. Vouloir les opérateurs de déplacement dans cette dernière situation ne sert à rien, l’implémentation serait strictement identique à celle d’une copie. Autre point, même s’il y a un pointeur, il faut que les fonctions de copie fassent une copie profonde pour que les fonctions de déplacements puissent faire une copie superficielle, sinon, rebelote, aucune différence avec la copie.

Comme une illustration est plus parlante, supposons une classe vector avec 2 variables membres:

• int* p, un pointeur alloué dynamiquement et désalloué dans le destructeur
• size_t n qui représente le nombre d’éléments alloué

L’instance de référence nommé A contient les nombres 7, 1, 3, 7, 0, 5, ce qui donne en mémoire

A = {
  p = /*adresse=*/0x12345678 /*valeurs=*/{ 7, 1, 3, 7, 0, 5 }
  n = 6
}

La copie profonde va faire une nouvelle allocation dynamique et copier les valeurs de A.p dans B.p. L’adresse du pointeur est donc différente, mais le contenu est identique.

// B = A
B = {
  p = /*adresse=*/0x87654321 /*valeurs=*/{ 7, 1, 3, 7, 0, 5 }
  n = 6
}

La copie superficielle effectuée par un déplacement n’alloue pas de mémoire, elle copie simplement A.p dans B.p qui est une opération bien plus rapide. L’adresse des pointeurs est identique.

// B = std::move(A)
B = {
  p = /*adresse=*/0x12345678 /*valeurs=*/{ 7, 1, 3, 7, 0, 5 }
  n = 6
}

Malheureusement, lorsque le destructeur est appelé, il libère la mémoire du pointeur p qui est partagé entre A et B. Cela donne inévitablement une double désallocation qui finit sur un crash de l’application. Pour prévenir cette erreur, A.p ne doit pas être libéré, par exemple en mettant le pointeur à nullptr.

// B = std::move(A)
A = {
  p = nullptr
  n = 0
}

Le déplacement a le même fonctionnement que le principe d’unicité: l’allocation dynamique (la ressource) ne doit être possédée que par une seule instance.

Le constructeur de déplacement prend ce qu’on nomme une rvalue (noté T&&). C’est une référence qui se veut temporaire. Si la valeur de cette expression provient d’une opération, elle doit être capturée dans la classe, autrement, elle est perdue. Lorsque cette valeur provient d’un déplacement explicite comme avec std::move(x), il faut considérer que x est dans un état qui ne permet plus de l’utiliser (sauf si la documentation indique le contraire).

À savoir que toutes variables – quel que soit son type réel – est toujours manipulée comme une lvalue. C’est-à-dire qu’avec int i; foo(i);, la fonction foo() reçoit une référence (int&), pas juste int.

Pour prendre un exemple connu, les chapitres suivants reposent sur le fonctionnement de std::unique_ptr, un pointeur intelligent qui fait une désallocation automatique de la mémoire dans son destructeur et interdit la copie pour respecter le principe d’unicité.

#include <cassert>

struct unique_ptr
{
  using value_type = int; // normalement un type template,
                          // mais pour cet exemple, juste un int

  unique_ptr(value_type* p = nullptr)
  : m_p(p)
  {}

  // Notre constructeur de déplacement
  // D'après la documentation std::unique_ptr, après cette fonction
  // other.m_p doit être nullptr
  unique_ptr(unique_ptr&& other);

  ~unique_ptr()
  {
    delete m_p;
  }

  // Pour simplifier, la classe ne possède que `operator*` et `operator bool ()`

  explicit operator bool () const
  {
    return m_p;
  }

  value_type& operator*()
  {
    assert(m_p);
    return *m_p;
  }

private:
  value_type* m_p;
};

Et un premier exemple d’utilisation.

#include <iostream>
#include <utility>

void print(unique_ptr& ptr)
{
  if (ptr) std::cout << *ptr;
  else std::cout << "nullptr";
  std::cout << "\n";
}

int main()
{
  unique_ptr p1(new int(3));
  unique_ptr p2{std::move(p1)}; // on déplace p1 dans p2

  // p1 est vide, cela affiche nullptr
  std::cout << "p1: ";
  print(p1);

  // p2 possède un pointer valide, cela affiche 3
  std::cout << "p2: ";
  print(p2);
}

Reste l’implémentation du constructeur de déplacement. Comme dit précédemment, seule une instance doit posséder le pointeur interne. L’instance déplacée doit être modifiée pour ne plus y faire référence, tout en restant dans un état dit destructible pour que le destructeur fonctionne convenablement. Les prérequis de MoveConstructible parlent d’un état non spécifié. C’est-à-dire que l’implémentation est libre de faire ce qu’elle veut du moment que la destruction fonctionne encore, mais il ne faut plus utiliser la variable.

Cependant, chaque fonction peut explicitement documenter le comportement comme c’est le cas avec std::unique_ptr qui met le pointeur déplacé à nullptr.

unique_ptr::unique_ptr(unique_ptr&& other)
: _p(std::exchange(other._p, nullptr))
{}

Finalement beaucoup d’explications pour 1 ligne de code. Mais nous sommes loin d’avoir terminé, notre unique_ptr ne respecte pas tous les prérequis nécessaires pour un bon constructeur de déplacement. Il n’y a pas non plus d’affectation par déplacement qui amène à de grosse surprise. Et surtout, qui nous dit qu’il n’est pas copiable ?

Une classe possède 6 fonctions spéciales générées automatiquement par le compilateur:

• le constructeur par défaut
• le constructeur par copie
• l’affectation par copie
• le constructeur par déplacement
• l’affectation par déplacement
• le destructeur

Si aucune de ces fonctions n’est déclarée dans la classe, leur existence dépend des membres la composant. Ainsi, si un membre comme std::unique_ptr existe, les 2 fonctions liées à la copie seront implicitement supprimées car inexistantes pour le type std::unique_ptr.

De plus, définir explicitement certaines fonctions va en désactiver d’autres. Il est nécessaire d’utiliser =default pour les réactiver.

À cela s’ajoute que le constructeur par défaut n’est plus défini en présence de n’importe quel autre constructeur (pas uniquement ceux de copie ou de déplacement).

Si on reprend notre unique_ptr précédemment, ce tableau affirme une chose: la copie n’est pas possible et l’affectation par déplacement est bien manquante.

À titre personnel, je pense qu’il vaut mieux explicitement indiquer que la copie est interdite, soit via une classe spécifique comme boost::noncopyable soit en ajoutant les prototypes suivants:

unique_ptr(unique_ptr const&) = delete;
unique_ptr& operator=(unique_ptr const&) = delete;

Quitte à déclarer certaines fonctions comme étant supprimées, il est aussi plus explicite pour l’utilisateur de la classe de mettre explicitement =default pour les autres fonctions. C’est le principe de la règle de 5 qui consiste à définir explicitement les fonctions spéciales (en excluant le constructeur par défaut dans cette règle).

À savoir aussi que – sauf cas très spécifique – les constructeurs et operator= vont par paire. Si l’un est implémenté, l’autre devrait l’être également. Ce que nous allons faire dans le prochain chapitre.

Cette fonction est proche du constructeur de déplacement, mais possède un petit piège qu’il est bon de savoir. Commençons par une implémentation possible:

unique_ptr& operator=(unique_ptr&& other)
{
  delete m_p;
  m_p = std::exchange(other.m_p, nullptr); // ligne qu'on retrouve dans le constructeur
  return *this;
}

En apparence, aucun problème, le pointeur à l’intérieur de other est déplacé puis remis à zéro, alors que l’ancien se fait détruire. Un petit test le confirme:

int main()
{
  unique_ptr p1{new int(3)};
  unique_ptr p2;

  print(p2); // nullptr
  p2 = std::move(p1);
  print(p2); // p2 contient int* sur 3
  print(p1); // p1 est maintenant nullptr
}

Mais que se passe-t-il si on fait un déplacement sur soi-même ?

int main()
{
  unique_ptr p{new int(3)};
  print(p); // 3
  p = std::move(p);
  print(p); // ???
} // double-free !!!

Le code affiche n’importe quoi et explose ! La raison est toute bête, on désalloue le pointeur puis on récupère celui dans other qui est identique au pointeur précédemment libéré. Une écriture aussi explicite que p = std::move(p) n’a pas beaucoup de sens, mais il est possible d’arriver dans une telle situation avec un code plus complexe et 2 variables à priori bien distinctes.

Si on se réfère au prérequis de MoveAssignable, il n’y a aucune indication sur l’état de t dans t = rv lorsque t et rv sont la même référence. Plusieurs choix s’offrent à nous en cas de self-move-assignment:

• considérer cela comme un comportement indéfini
• définir rv comme étant égal à nul (donc le pointeur est ici supprimé)
• définir t comme contenant le pointeur de rv (et donc ici ne rien faire)

Ce choix peut paraitre étrange voire dangereux, mais il est justifié pour un besoin de performance: le déplacement doit être rapide. Gérer un tel scénario demande du code supplémentaire – généralement un if (this != &other) – et cela peut avoir un impact signification pour un cas de figure fortement marginal. Le choix du standard penche beaucoup pour un comportement indéfini et seules certaines classes l’autorisent.

Pour information, les implémentations de libc++ et libstdc++ (clang et gcc) vident les containers tel que std::vector. Il y a même une assertion si on utilise libstdc++ avec la macro _GLIBCXX_DEBUG.

#include <vector>

int main()
{
  std::vector<int> v{1,2,3};
  v = std::move(v); // kaboum avec -D_GLIBCXX_DEBUG: https://godbolt.org/z/Gn4KWe
  // v.size() == 0
}

g++ test.cpp -D_GLIBCXX_DEBUG && ./a.out
[...]
Error: attempt to self move assign.
[...]

Définir l’état de rv sur self-move-assignment

Dans ce scénario, seul l’état de rv dans t = rv est défini comme étant à nul. Pour ce faire, on désalloue le pointeur de t puis on le met à nullptr. Après un déplacement sur soi-même, le pointeur est systématiquement détruit.

unique_ptr& operator=(unique_ptr&& other)
{
  delete m_p;
  m_p = nullptr; // other.m_p devient nullptr quand other.m_p == m_p
  m_p = std::exchange(other.m_p, nullptr);
  return *this;
}

Ce comportement n’est pas très logique. Ce qui importe dans un déplacement est de connaître l’état de la destination (t). De plus, se retrouver avec t == nullptr est en contradiction avec le comportement principal du déplacement: « la valeur de t est équivalent à la valeur de rv avant affectation ».

Finalement ce choix n’est pas très judicieux.

Définir l’état de t sur self-move-assignment

Ici l’état de t est défini, même quand t = rv équivaut à un déplacement sur soi-même. Si c’est le cas, on ne désalloue rien et le déplacement ne fait rien: on a bien t équivalent à la valeur de rv avant affectation.

unique_ptr& operator=(unique_ptr&& other)
{
  auto* new_p = std::exchange(other.m_p, nullptr);
  delete m_p; // m_p = nullptr quand other.m_p == m_p
  m_p = new_p;
  return *this;
}

Cette dernière peut aussi s’écrire avec l’idiome copy-and-swap ou avec if (this == &other) return *this en début de fonction pour complètement ignorer l’affectation sur soi-même. Personnellement, j’évite les conditions dans les fonctions de déplacement lorsque cela est possible.

// copy-and-swap
unique_ptr& operator=(unique_ptr other) // on prend par valeur
{
  using std::swap;
  swap(other.m_p, m_p); // et on swap
  return *this;
  // le destructeur de other va libérer la mémoire à sa destruction
}

Ce comportement pour le déplacement est celui documenté dans std::unique_ptr qui impose l’équivalence à reset(r.release()): la valeur ne change pas lorsque t et rv référencent le même objet.

Les déplacements devraient être noexcept

C’est une chose qu’on oublie facilement, mais les fonctions de déplacement devraient être noexcept pour 2 raisons simples:

• Le déplacement est une opération qui se veut la plus triviale possible. Les risques d’exception sont normalement nuls.
• Les containers de la STL utilisent les fonctions de déplacement à la condition que ceux-ci sont noexcept ou qu’il n’y ait pas de fonction de copie. Voici un exemple qui montre le problème.

#include <vector>
#include <cstdio>

// copie interdite
struct A
{
  A()=default;
  A(A const&)=delete;
  A(A&&) { std::puts("A&&"); }
};

// copie autorisée, mais déplacement qui n'est pas noexcept
struct B
{
  B()=default;
  B(B const&)=default;
  B(B&&) { std::puts("B&&"); }
};

// copie autorisée et déplacement noexcept
struct C
{
  C()=default;
  C(C const&)=default;
  C(C&&) noexcept { std::puts("C&&"); }
};

int main()
{
  // va afficher au moins un A&&
  std::vector<A> a;
  a.emplace_back();
  a.emplace_back();
  a.emplace_back();

  // aucun B&&
  std::vector<B> b;
  b.emplace_back();
  b.emplace_back();
  b.emplace_back();

  // va afficher au moins un C&&
  std::vector<C> c;
  c.emplace_back();
  c.emplace_back();
  c.emplace_back();
}

(Je n’ai pas mis operator=, mais il est évident que la version par déplacement devrait aussi être noexcept.)

Une note sur l’implémentation derrière: les containers se basent sur la fonction std::move_if_noexcept.

Je ne vais pas mentir, tout le baratin précédent n’est là que pour placer ce chapitre. Autant de bla bla juste pour le plaisir de mettre ce titre :).

Ceci dit, arrivé ici, vous devriez être conscient que std::move ne fait pas grand-chose: tout se situe dans les constructeurs et opérateurs de déplacement.

Mais alors, que fait std::move ? Eh bien, rien… Ou plus précisément, la fonction ne touche pas à l’instance, mais à la catégorie de valeur. Ce n’est rien de plus qu’un cast d’une lvalue en rvalue ! On pourrait tout aussi bien remplacer std::move(x) par static_cast<std::remove_reference_t<decltype(x)>&&>(x) , le résultat serait exactement le même – à la verbosité près.

Puisque std::move n’est rien de plus qu’un cast, il est inutile de l’utiliser sur des rvalues. std::move(Bidule{}) n’a aucun sens, Bidule{} est déjà une rvalue (mieux, c’est une prvalue). Il n’est pas non plus nécessaire de l’utiliser sur le retour des fonctions qui bénéficient de la RVO et de l’élision de copie en général.

Pire, utiliser std::move lorsque cela n’est pas nécessaire désactive certaines optimisations. Sur ce point, gcc et clang ont tous deux les avertissements -Wpessimizing-move et -Wredundant-move qui se déclenchent sur une utilisation inappropriée de std::move.

A foo()
{
  A ret;
  // ...
  return std::move(ret); // -Wpessimizing-move
  return ret; // NRVO
}

A foo(A a)
{
  return std::move(a); // -Wredundant-move
}

A bar()
{
  foo(std::move(A{})); // -Wpessimizing-move
  return std::move(foo()); // -Wpessimizing-move
  return foo(); // RVO
}

Pour finaliser les explications sur le déplacement, il faut introduire std::forward.

Cette fonction n’est utile que sur des types templates dont la catégorie de valeur n’est pas connue. L’exemple le plus simple est une fonction template<class T> void foo(T&& x); où T représente une forwarding reference. Càd une référence qui est soit une lvalue, soit une rvalue. On peut aussi croiser le nom de référence universelle venant d’avant la normalisation du nom officiel.

Il faut bien comprendre que les forwarding references s’appliquent sur un type template complet, ce qui n’est pas le cas par exemple pour void foo(std::vector<T>&& vec) où la fonction attend toujours une rvalue.

Le but de std::forward est de propager la référence en castant une variable vers une rvalue quand le type d’origine est une rvalue (n’oublions pas qu’à ce niveau, une variable est une lvalue, même si son type est une rvalue).

#include <iostream>

void foo(int&& x) { std::cout << "foo(int&&)\n"; }
void foo(int& x) { std::cout << "foo(int&)\n"; }

template<class T>
void bar(T&& x)
{
  foo(std::forward<T>(x)); // `x` est castée en rvalue lorsque T&& est une rvalue
}

int main()
{
  int i = 0;
  bar(i);            // foo(int&)
  bar(std::move(i)); // foo(int&&)
}

Sans l’usage de std::forward, les 2 appels donneraient foo(int&).

Si on veut comprendre la magie derrière, il faut regarder le type réel de T:

• bar(i): T&& = int&. T = int&
• bar(std::move(i)): T&& = int&&. T = int.

Appliquer une rvalue sur un type qui est une lvalue donne une lvalue. C’est ce qu’on appelle les règles de reference collapsing.

C’est également le mécanisme derrière std::forward<T>(x) qui combine simplement T à une rvalue pour caster la variable dans la bonne catégorie de valeur. Ceci est strictement équivalent à static_cast<T&&>(x) ou static_cast<decltype(x)&&>(x). Certains projets définissent une macro FWD(x) qui fonctionne ainsi.

Pour résumer tout ça:

• std::move n’est qu’un cast user-friendly vers une rvalue, ce n’est pas lui qui fait le déplacement à proprement parler. Mal l’utiliser désactive aussi certaines optimisations.
• Le comportement du déplacement est défini par les fonctions qui reçoivent une rvalue.
• Définir certaines fonctions spéciales en désactive d’autres, il est préférable d’indiquer explicitement le comportement de chacune de préférence avec =default ou =delete. Pour rappel, les fonctions spéciales sont ici les constructeurs de déplacement et de copie, l’affectation par déplacement et de copie ainsi que le destructeur.
• le constructeur de déplacement et l’affectation par déplacement devrait être noexcept pour que les containers de la STL les utilisent.
• std::forward s’utilise pour des paramètres template de la forme T&& pour propager le type de référence (lvalue ou rvalue).

Voilà qui clôture cet article sur la sémantique de déplacement. Et n’oubliez pas, une variable n’est jamais une rvalue et – sauf exception de la NRVO – il faut explicitement utiliser std::move pour l’utiliser comme une rvalue.

SFINAE (Substitution Failure Is Not An Error) est un mécanisme du compilateur pour ignorer certaines instanciations de fonction ou de classe qui ne compilent pas, sans pour autant émettre une erreur de compilation.

Pour comprendre pleinement le mécanisme derrière, il faut assimiler le principe de substitution appliquée par le compilateur. Lorsqu’une expression dépend d’un paramètre template, le compilateur va évaluer l’expression en la substituant par le type ou la valeur de l’expression. Prenons le code suivant:

struct A { using type = int; };

template<class T>
void foo(typename T::type value);

foo<A>(3);

À l’appel de foo<A>, le compilateur remplace typename T::type par A::type, qui correspond ici à int. C’est la substitution. Lorsque le compilateur n’arrive pas à faire cette substitution – car par exemple il n’y a pas de membre type – il va chercher une autre fonction foo<A> qui pourrait être utilisée.

struct B { using value_type = int; };

template<class T>
void foo(typename T::type value); // B::type n'existe pas, cette fonction est ignorée

template<class T>
void foo(typename T::value_type value);

foo<B>(3);

Bien sûr, si le compilateur peut utiliser les 2 fonctions foo précédentes, il y aura ambiguïté et finalement une erreur.

struct C
{
  using value_type = int;
  using type = int;
};

foo<C>(3);

test.cpp:15:3: error: call to 'foo' is ambiguous
  foo<C>(3);
  ^~~~~~
test.cpp:2:6: note: candidate function [with T = C]
void foo(typename T::type value);
     ^
test.cpp:5:6: note: candidate function [with T = C]
void foo(typename T::value_type value);
     ^

Il faut bien comprendre que SFINAE n’est pas un mécanisme pour simplifier les messages d’erreur, ni pour les ignorer. Le résultat est même plutôt inverse, à un certain point, il est difficile de savoir pourquoi une fonction est utilisée à la place d’une autre, le compilateur ne donnant aucun diagnostic. Les erreurs sont plus verbeuses – l’ensemble des prototypes sont listés – et les ambiguïtés difficiles à corriger sans ajouter de la complexité.

Plus le nombre de prototypes liés à un nom de fonction croît, plus le code devient difficile et les erreurs – principalement d’ambiguïtés – nombreuses. Il faut bien réfléchir à la manière de s’y prendre pour ne pas être happé par le code avec des prototypes à rallonge à ne plus savoir quoi en faire. Le but de cet article est de présenter différentes solutions pour exploiter SFINAE sans être enfermé dans un usage unique qui se limite souvent à la superposition de condition dans un std::enable_if_t.

Le SFINAE repose entièrement sur les valeurs ou types template, on parle de value-dependent ou type-dependent (je ne ferais pas de distinction entre les 2). Tout ce qui n’est pas lié à une valeur template sera évalué automatiquement par le compilateur, que l’expression soit ou non dans une classe ou une fonction template.

Par exemple:

struct A { using type = int; };

template<class T>
int foo(T x, A::type y) // A::type doit exister, car le type n'est pas type-dependent
                        // Si A::type n'existe pas, il y aura une erreur
                        // même si foo() n'est pas utilisée
{
  return x + 1; // Cette expression dépend de x qui est template,
                // une erreur ne pourra survenir qu'au moment de l'instanciation de foo()
  return ""; // cette expression n'a aucune dépendance -> il devrait y avoir une erreur
}

Si le compilateur respecte scrupuleusement la norme et sans la moindre utilisation de foo(), tout ce qui n’a pas de dépendance doit être évalué au plus tôt et systématiquement.

• le type A::type doit exister
• le second retour ne doit pas compiler

Étrangement, du moment que la fonction n’est pas utilisée, gcc ne vérifie pas si le retour est convertible vers celui de la fonction, mais demande quand même une expression valide, alors que msvc ne fait aucune vérification au sein de la fonction. Par contre clang indique qu’une chaîne de caractères n’est pas convertible en int.

L’évaluation systématique des types indépendants explique pourquoi le code ci-dessous donne toujours une erreur.

if constexpr (xxx)
{
  // ...
}
else
{
  static_assert(false); // toujours évalué -> erreur de compilation
}

On touche ici au contexte d’évaluation: le prototype, suivi du corps de fonction. Le second est évalué différemment selon les compilateurs, mais cela ne cause pas réellement de problème, car les erreurs apparaissent au moment de l’utilisation de la fonction.

Quand on parle de contexte, on parle aussi de sous-contexte. Dans le cas de SFINAE, la dépendance d’un contexte au contexte parent ne peut pas être attrapé, ce qui résultera dans tous les cas à une erreur de compilation. Le corps d’une fonction est un exemple, un autre concerne les membres d’une classe:

struct A
{
  using type = int;
};

struct B
{};

template<class T>
struct C // contexte principal (instanciation de la structure)
{
  using type = typename T::type; // sous-contexte,
                                 // T::type dépend de T du contexte parent
};

template<class T, class = typename T::type>
constexpr int foo(int)
{ return 1; }

template<class T>
constexpr int foo(char)
{ return 2; }

static_assert(foo<A>(0) == 1);
static_assert(foo<B>(0) == 2);
static_assert(foo<C<A>>(0) == 1);
static_assert(foo<C<B>>(0) == 2); // erreur

test.cpp:12:28: error: no type named 'type' in 'B'
  using type = typename T::type; // sous-contexte,
               ~~~~~~~~~~~~^~~~
test.cpp:16:36: note: in instantiation of template class 'C<B>' requested here
template<class T, class = typename T::type>
                                   ^

Pour que C fonctionne avec SFINAE, il faut une spécialisation de C sans le membre type. Cela requière un développement spécifique qui rend le support de SFINAE quelquefois difficile à mettre en place.

Partout où il est possible de mettre un type ou une valeur est propice à la substitution: paramètre template, contenu de noexcept, decltype, sizeof et même les paramètres par défaut. Quel que soit l’emplacement, si le compilateur ne trouve pas une expression qu’il peut compiler, il va simplement ignorer la fonction ou l’instanciation.

Généralement, pour vérifier une expression, le plus simple est d’ajouter un paramètre de template initialisé avec l’expression qui doit être valide ou passer par decltype. Pour ce dernier, une petite astuce pour ajouter plusieurs expressions consiste à les séparer par des virgules et entourer le tout d’une paire de parenthèse:

template<..., class = decltype(...)> // ici ou
auto f(...) -> decltype(((void)expr1, (void)(expr2), expr3));
                     // ^ pour que decltype ne voit qu'une expression
                     //  ^ le cast en void permet d'inhiber d'éventuelle surcharge de ,
                     //             ^ la virgule pour séparer chacune des expressions
                     //                              ^ l'expression pour le type de retour

À partir de maintenant, je vais présenter les techniques qui me viennent à l’esprit en me basant si possible sur des éléments de la STL pour des exemples pratiques. Les plus curieux pourront comparer avec l’implémentation de la STL qu’ils utilisent (msvc, clang (libc++) et gcc (libstdc++) pour les plus connues).

Dans ce premier exemple, nous allons voir comment implémenter std::make_unique. Pour rappel, il existe 3 versions:

make_unique<T>(args...) -> unique_ptr<T>;
make_unique<T[]>(size) -> unique_ptr<T[]>; // arrays of unknown bound
make_unique<T[N]>(args...) = delete; // arrays of known bound

Comme le premier type template influence les paramètres et le type de retour, le plus simple est un trait qui va sélectionner le bon prototype. Contrairement au trait que l’on rencontre habituellement, celui-ci va définir un type membre différent pour chaque spécialisation utilisée par un prototype. Ainsi, seul un prototype pourra être utilisé pendant que les autres ne trouveront pas le membre attendu. Cette implémentation est tout droit sortie des STLs.

namespace detail
{
  template<class T>
  struct make_unique_select
  {
    using single_object = std::unique_ptr<T>;
  };

  template<class T>
  struct make_unique_select<T[]>
  {
    using array = std::unique_ptr<T[]>;
  };

  template<class T, std::size_t N>
  struct make_unique_select<T[N]>
  {
    struct invalid_type {};
  };
}

template<class T, class... Args>
typename detail::make_unique_select<T>::single_object
make_unique(Args&&... args)
{
  return std::unique_ptr<T>(new T(std::forward<Args>(args)...));
}

template<class T>
typename detail::make_unique_select<T>::array
make_unique(std::size_t num)
{
  return unique_ptr<T>(new std::remove_extent_t<T>[num]());
}

template<class T, class... Args>
typename detail::make_unique_select<T>::invalid_type
make_unique(Args&&...) = delete;

Si le C++ supportait la spécialisation partielle de fonction, on pourrait se passer de detail::make_unique_select. Par contre, comme l’implémentation de make_unique dépend uniquement d’un type template qui doit être explicitement mis, on peut simplifier le code grâce aux variables template et en déplaçant l’implémentation des fonctions dans les spécialisations de structure.

namespace detail
{
  template<class T>
  struct make_unique_impl
  {
    template<class... Args>
    std::unique_ptr<T> operator()(Args&&... args) const
    {
       return std::unique_ptr<T>(new T(std::forward<Args>(args)...));
    }
  };

  template<class T>
  struct make_unique_impl<T[]>
  {
    std::unique_ptr<T[]> operator()(std::size_t num) const
    {
      return std::unique_ptr<T[]>(new std::remove_extent_t<T>[num]());
    }
  };

  template<class T, std::size_t N>
  struct make_unique_impl<T[N]>
  {
    template<class... Args>
    struct invalid_type operator()(Args&&...) const = delete;
  };
}

template<class T>
constexpr detail::make_unique_impl<T> make_unique {};

Ce qui revient à des bêtes spécialisations de template.

Grâce à un paramètre supplémentaire, il est possible d’ajouter des conditions dans une spécialisation pour y ajouter des contraintes. Voici un exemple simplifié avec une implémentation de std::is_convertible.

template<class From, class To, class = void>
struct is_convertible : std::false_type
{};

template<class From, class To>
struct is_convertible<From, To,
  // on utilise le paramètre "fantôme",
  // mais le type final de l'expression doit être le même que la valeur par défaut
  class = decltype(
    // fonction créée à la volée qui prend un paramètre To
    // qui échouera si From n'est pas convertible
    std::declval<void(&)(To)>()(std::declval<From>())
  )
> : std::true_type
{};

Cette technique permet de n’instancier un type que si tous les prérequis sont acceptés. Au début de l’article, j’ai présenté un exemple de classe où T::type (avec T = C<B>) donne une erreur, car le sous-membre (type) dépend d’un contexte parent. Voici comment on peut palier à ce problème:

template<class T, class = void>
struct C
{
  // par défaut aucun membre
};

// si T::type existe bien, cette spécialisation sera utilisée
template<class T>
struct C<T, std::void_t<typename T::type>>
{
  using type = typename T::type;
};

Ceci fonctionne pour des types, mais les compilateurs sont plus capricieux avec des valeurs. Par exemple, une spécialisation sur des valeurs divisibles par 16 comme ci-dessus donne une erreur avec gcc, msvc et icc. Étrangement, seul clang l’accepte.

template<std::size_t N, bool = false>
struct is_mod16 : std::false_type
{};

template<std::size_t N>
struct is_mod16<N, (N % 16 == 0)> : std::true_type // erreur
{};

Faute de mieux, le plus simple est de passer par std::enable_if_t<N % 16 == 0> et prendre un type comme second paramètre de template.

Il est possible d’ajouter un paramètre dans une fonction et jouer avec les conversions implicites pour prioriser l’ordre d’appel.

template<class T, class = typename T::type>
constexpr int foo(int) { return 1; }

template<class T, class = typename T::value_type>
constexpr int foo(char) { return 2; }

struct A
{
  using type = int;
};

struct B
{
  using value_type = int;
};

struct C : A, B
{};

static_assert(foo<A>(42) == 1);
static_assert(foo<B>(42) == 2);
// les 2 fonctions sont valides, mais T::type est prioritaire car 42 est un int
static_assert(foo<C>(42) == 1);

On peut même ajouter autant de paramètres que nécessaire pour avoir une chaîne de priorité. Par exemple, on pourrait faire une fonction front() qui utilise en priorité la fonction front(cont) dans le namespace de l’objet (règles d’ADL), sinon cont.front() et en dernier recours *begin(cont).

#include <iterator>

// juste pour simplifier l'écriture des fonctions
#define DECLTYPE_AUTO_RETURN_NOEXCEPT(...)                 \
  noexcept(noexcept(__VA_ARGS__)) -> decltype(__VA_ARGS__) \
  {                                                        \
    return (__VA_ARGS__);                                  \
  }

namespace adl_barrier
{
  // pour que front_impl() voit une fonction front() qu'elle pourrait utiliser
  struct na {};
  void front(na) = delete;

  // pour que begin(cont) utilise le begin de son namespace (ADL) ou std::begin()
  using std::begin;

  template<class Cont>
  constexpr auto front_impl(Cont& cont, int, int)
  DECLTYPE_AUTO_RETURN_NOEXCEPT(front(cont))

  template<class Cont>
  constexpr auto front_impl(Cont& cont, int, char)
  DECLTYPE_AUTO_RETURN_NOEXCEPT(cont.front())

  template<class Cont>
  constexpr auto front_impl(Cont& cont, char, char)
  DECLTYPE_AUTO_RETURN_NOEXCEPT(*begin(cont))
}

template<class Cont>
constexpr auto front(Cont&& cont)
// le perfect forwarding n'est pas respecté pour simplifier l'exemple
DECLTYPE_AUTO_RETURN_NOEXCEPT(adl_barrier::front_impl(cont, 1, 1))


namespace mylib
{
  struct A
  {
    char const * s;
  };

  constexpr char front(A const& a)
  {
    return a.s[0];
  }


  struct B
  {
    char const * s;
  };

  constexpr char const* begin(B const& b)
  {
    return b.s;
  }


  struct C
  {
    char const * s;

    constexpr char front() const
    {
      return s[0];
    }
  };
}

static_assert(front(mylib::A{"ax"}) == 'a'); // mylib::front(A)
static_assert(front(mylib::B{"bx"}) == 'b'); // *mylib::begin(B)
static_assert(front(mylib::C{"cx"}) == 'c'); // C::front()
constexpr char carr[] = "dx";
static_assert(front(carr) == 'd'); // *std::begin(carr)

Il existe en C des paramètres variadiques dont l’usage est limité aux types de base et aux pointeurs. Ce genre de paramètre à une particularité intéressante: il n’est pris en compte qu’à la seule condition qu’aucune autre fonction ne pourrait correspondre. Il a donc une priorité inférieure à la conversion et ne rentre pas en conflit avec. On pourrait réécrire std::is_convertible comme suit

template<class From, class To>
struct is_convertible_impl
{
  std::true_type test(To);
  std::false_type test(...);
};

template<class From, class To>
using is_convertible = decltype(is_convertible_impl<From, To>::test(std::declval<From>()));

Cela peut paraître idiot, mais pour rendre dépendant un type indépendant du contexte, il suffit qu’il traverse un type dépendant.

Voici un exemple pour avoir le plus proche d’un if constexpr () {} else static_assert(false):

constexpr auto fn_identity = [](auto&& x) -> decltype(auto) {
  return static_cast<decltype(x)&&>(x);
};

template<class>
inline auto dependent_identity = fn_identity;

template<class T>
void foo(T const& x)
{
  if constexpr (std::is_array_v<T>)
  {
    // ...
  }
  else
  {
    // _ depend de T, mais est toujours égal à fn_identity
    auto _ = dependent_identity<T>;
    // _(false) retourne false,
    // mais la valeur est indirectement dépendante de T
    static_assert(_(false));
    // on notera que même si _ n'est pas une variable constexpr
    // le résultat de _(false) l'est :)
  }
}

// on peut aussi utiliser la variable x plutôt que T, avec quelque chose comme
template<class T, class U>
constexpr first(T x, U const&)
{
  return x;
}

//...
static_assert(first(false, x));

Cela s’applique aussi au membre d’une classe en ajoutant un template avec un paramètre par défaut qui ne sera jamais modifié par l’extérieur.

template<class T>
struct A
{
  template<class U = T>
  using type = typename U::type;
};

// son écriture en est par contre fortement alourdie:
A<T>::type<>
A<T>::template type<> // dans une fonction/classe template

Ou sur une fonction membre:

template<class T>
struct A
{
  // sans ce template, le type T doit obligatoirement avoir une fonction foo()
  // sinon, l'instanciation de A ne pourra pas se faire et A<int> donnerait
  // request for member ‘foo’ in ‘std::declval<int&>()’, which is of non-class type ‘int’
  template<class U = T>
  decltype(std::declval<U&>().foo()) foo();
};

Depuis C++20, il existe un nouvel outil pour exploiter le SFINAE: les concepts. Les concepts sont des contraintes ajoutées aux types qui doivent être vérifiées pour que le compilateur accepte d’utiliser la fonction ou d’instancier le type. Cela simplifie l’utilisation du SFINAE et rend le code beaucoup plus lisible. La fonctionnalité étant récente, la plupart des compilateurs ne la supporte pas encore.

noexcept est un mot clef apparu en C++11. Dans le prototype d’une fonction, il indique que cette dernière ne jette pas d’exception. Cela ne veut pas dire qu’aucune exception ne sera présente dans la fonction, mais qu’aucune exception ne sortira de la fonction. Dans le cas contraire, le programme s’arrête subitement avec un appel à std::terminate.

noexcept n’impose aucune restriction sur ce que peut faire la fonction. Il est tout à fait possible d’utiliser des fonctions qui ne sont pas marquées noexcept à l’intérieur d’une fonction noexcept, voire, de jeter des exceptions. La seule contrainte se trouve sur le chemin de sortie: il ne doit pas se faire avec une exception.

Voici un code totalement inutile de démonstration avec une exception qui traverse une fonction foo() marquée noexcept:

void foo() noexcept
{
  throw 42; // noexcept ? Pas vu
}

#include <iostream>

int main()
{
  try {
    foo(); // le programme s'arrête ici
  }
  catch (...) {
  }
  std::cout << "ok\n"; // ne s'affiche jamais
}

La compilation puis l’exécution donne:

$ g++ test.cpp && ./a.out
test.cpp: In function ‘void foo()’:
test.cpp:3:9: warning: throw will always call terminate() [-Wterminate]
    3 |   throw 42;
      |         ^~
terminate called after throwing an instance of 'int'
zsh: abort (core dumped)  ./a.out

G++, Clang et MSVC émettent tous 3 un avertissement et le programme explose comme attendu.

L’avertissement ici est évident, mais ce n’est pas toujours le cas, le compilateur ne pouvant garantir que toutes les fonctions utilisées dans une fonction noexcept ne jettent pas elles-mêmes des exceptions.

Notre fonction foo() est une énorme bombe à retardement. Chouette, une raison supplémentaire pour faire planter un programme ;)

Une mauvaise utilisation de noexcept peut faire planter un programme. Mais une fonctionnalité à risque ne vient jamais sans avantage. Puisque noexcept garantit qu’aucune exception ne sorte de la fonction, le compilateur peut éjecter le code qui s’en occupe. Si les fonctions ne lancent pas d’exception, il peut déterminer avec certitude quels sont les chemins de sortie, supprimer du code, réordonner les instructions et appliquer autres obscures magies dont il a le secret.

Dit comme ça, on pourrait croire que plein d’optimisations s’offrent à nous, mais non. Premièrement, les compilateurs sont capables de faire des exceptions qui n’ont de coût qu’au moment de l’appel. Bien sûr, l’exécutable est plus gros et peut impacter le cache d’instruction, mais le coût d’une exception non utilisée est nulle. Secundo, ce n’est pas évident de produire un exécutable qui supprime vraiment du code, à moins d’avoir absolument toutes les fonctions en noexcept, la magie du compilateur se verra limité. Surtout que les bonnes options d’optimisation donnent des résultats comparables.

Après plusieurs essais d’exemples de code pseudo-réaliste, en voici 2 basés sur une fonction très simple

// foo.cpp
int foo(int x) NOEXCEPT
{
  return x;
}

NOEXCEPT sera à remplacer par noexcept ou rien. Respectivement les options de compilation -DNOEXCEPT=noexcept et -DNOEXCEPT=.

Ce premier exemple prouve que le compilateur est capable de prendre en compte noexcept pour supprimer du code.

// main.cpp
#include <iostream>

int foo(int) NOEXCEPT;

void bar(std::ostream& out)
{
  char const* err;
  try {
    // trace de l'étape en cours
    err = "foo step";
    auto r = foo(1);
    // fin du "traitement"
    err = nullptr;

    out << r; // ceci peut lancer une exception std::ios_base::failure
  }
  catch(std::exception const& e)
  {
    // err != nullptr uniquement si foo() lance une exception
    if (err)
      std::cerr << "oups: " << err << "\n";
    std::cerr << e.what() << "\n";
  }
}

Ce code permet d’afficher un message sur l’étape en cours avant une éventuelle exception. Dans notre cas, foo() ne lance pas d’exception, mais en l’absence de noexcept, main.cpp ne le sait pas.

Si foo() ne lance pas d’exception, alors err sera toujours égal à nullptr dans le catch. Il est alors possible de supprimer la condition qui serait toujours évaluée à false, ce qui doit donner un exécutable plus petit.

Le petit script suivant va compiler chaque .cpp avec et sans noexcept puis afficher la taille de l’exécutable.

for x in noexcept '' ; do
  d=NOEXCEPT=$x
  g++ -O3 -D$d *.cpp &&
  echo $d &&
  stat ./a.out *.o --format="$(echo "%n\t%s")"
done

Pronostic vérifié. On peut même regarder l’assembleur sur godbolt pour s’en convaincre.

Voici un second exemple plus simple qui montre que le compilateur supprime totalement la gestion des exceptions lorsqu’il lui est permis de le faire.

#include <memory>

int foo(int) NOEXCEPT;

int bar(std::unique_ptr<int>&& p)
{
    // some stuff
    // ...
    auto u = std::move(p);
    return foo(*u);
}

Et l’asm de https://godbolt.org/z/-yIB7m

bar(std::unique_ptr<int, std::default_delete<int> >&&):
        push    r12
        push    rbp
        sub     rsp, 8
        mov     rbp, QWORD PTR [rdi]
        mov     QWORD PTR [rdi], 0
        mov     edi, DWORD PTR [rbp+0]
        call    foo(int)
        mov     rdi, rbp
        mov     esi, 4
        mov     r12d, eax
        call    operator delete(void*, unsigned long)
        add     rsp, 8
        mov     eax, r12d
        pop     rbp
        pop     r12
        ret
; ce qui suit ne concerne que l'éventuelle exception de foo()
        mov     r12, rax
        jmp     .L2
bar(std::unique_ptr<int, std::default_delete<int> >&&) [clone .cold]:
.L2:
        mov     rdi, rbp
        mov     esi, 4
        call    operator delete(void*, unsigned long)
        mov     rdi, r12
        call    _Unwind_Resume

La seconde partie du code asm n’est utilisée que pour le traitement d’une exception, elle se situe en dehors du flux normal d’exécution et disparait lorsque foo() ne lance pas d’exception.

Mais attention, si une fonction noexcept appelle une fonction qui n’est pas noexcept, le compilo va ajouter du code pour forcer l’utilisation de std::terminate(). Cela revient presque à un support d’exception, mais en plus léger.

Maintenant, il faut savoir qu’avec l’option -flto la taille des exécutables sont les mêmes que foo() soit noexcept ou pas. Simplement parce que le compilateur déduit que foo() ne lance pas d’exception. Mais dans le cas de bibliothèque partagée, -flto ne pourra rien faire et la différence subsistera.

Puisque le compilateur peut déduire lui-même qu’une fonction ne lance pas d’exception, pourquoi et surtout quand mettre noexcept ?

Déjà, on peut dire qu’une fonction qui ne lance absolument pas d’exception peut être noexcept. Cette information est surtout utile dans les APIs ou bibliothèques qui ont cette garantie. Un analyseur statique pourrait aussi vérifier qu’aucune exception ne la traverse. Dans le cas contraire, c’est plutôt risqué.

Néanmoins, noexcept est vraiment important sur les constructeurs déplacement.

Pour être plus précis, conjointement avec les conteneurs de la STL, cela va déterminer si le conteneur utilise ou non le déplacement. Si la fonction est noexcept, le déplacement d’un élément ne peut pas échouer. Dans le cas d’un std::vector<T>, cela veut dire qu’après un agrandissement de la capacité, tous les éléments peuvent être déplacés sans échec. Par contre, si le déplacement lance une exception, une partie des données pourrait se perdre et std::vector utilise alors la copie. On parle de résistance aux exceptions ou d’exception-safety. Dans le cas de std::vector, c’est une garantie forte: l’état du vector est inchangé s’il y a une exception sur l’augmentation de la capacité. Pour en savoir un peu plus sur l’exception-safety, c’est par là.

Pour illustrer l’influence de noexcept avec std::vector, voici une petite classe qui affiche quel constructeur est utilisé. Le constructeur de déplacement est toujours présent, seule la présence de noexcept diffère.

#include <iostream>

struct A
{
  A(int i) : i(i) {}

  A(A const& a) : i(a.i)
  { std::cout << "A&(" << i << ")\n"; }

  A(A&& a) NOEXCEPT : i(a.i)
  { std::cout << "A&&(" << i << ")\n"; }

  int i;
};

#include <vector>

int main()
{
  std::vector<A> v;
  v.emplace_back(1);
  v.emplace_back(2); // agrandissement de la capacité + déplacement/copie de A(1)
}

Et les résultats après compilation:

Maintenant imaginons que notre classe A contienne des std::string et des std::vector. Si le constructeur de déplacement n’est pas noexcept, alors il y aura de nombreuses copies qui auront un gros impact sur les performances. Ce n’est généralement pas ce qu’on veut.

Personnellement, je déconseille d’écrire le constructeur et operator= de déplacement ou de copie. 99% du temps, la version par défaut fait le job, le compilateur déduisant lui-même noexcept pour les fonctions par défaut – et c’est bien le seul moment. S’il y a une véritable nécessité, il est généralement possible d’avoir une classe qui ne fournit que ce service et l’utiliser en variable membre.

Si on écrit explicitement noexcept sur une fonction par défaut – par exemple X(X&&) noexcept = default; – le compilateur va vérifier que le déplacement de chaque membre ne lance pas d’exception. Et dans le cas contraire, ne compile pas.

Pour finir, les destructeurs sont implicitement noexcept. Si un destructeur balance une exception, le programme va s’arrêter. Les raisons sont assez simples: il est difficile de catcher une exception d’un destructeur et il est impossible d’arriver à un état cohérent sans code spécifique si les objets ne peuvent être détruits. De plus, il faut savoir que jeter une exception pendant le traitement d’une exception appelle automatiquement std::terminate(). Du coup, les exceptions dans un destructeur sont plutôt une mauvaise idée.

Mais si on veut autoriser le destructeur à jeter des exceptions ou pouvoir marquer nos fonctions en noexcept à la seule condition qu’une expression précise soit elle-même noexcept il existe un nouveau mot clef: noexcept. Oui, mais non, il est différent.

Il existe 2 mots clef pour noexcept: le spécificateur d’exception et l’opérateur.

• Le spécificateur noexcept ou noexcept(bool) se met toujours dans le prototype de la fonction. noexcept et noexcept(true) indiquent que la fonction ne jette pas d’exception, noexcept(false) indique que la fonction jette potentiellement une exception.
• L’opérateur noexcept(expr) prend une expression est retourne un booléen qui indique si oui ou non une expression peut lancer une exception.

Voici quelques exemples:

constexpr bool foo() { return true; }

void f1() noexcept;
void f2() noexcept(false);
void f3() noexcept(foo()); // -> noexcept(true)
void f4() noexcept(noexcept(f1())); // noexcept seulement si f1() est noexcept
void f5() noexcept(noexcept(new int));
void f6() noexcept(noexcept(false));

std::cout << noexcept(f1())  << "\n"; // true
std::cout << noexcept(f2())  << "\n"; // false
std::cout << noexcept(f3())  << "\n"; // true
std::cout << noexcept(f4())  << "\n"; // true
std::cout << noexcept(f5())  << "\n"; // false
std::cout << noexcept(f6())  << "\n"; // true
std::cout << noexcept(true)  << "\n"; // true
std::cout << noexcept(false) << "\n"; // true

Pas très compliqué dans l’ensemble, même si bien que logique, le résultat de f6() et la dernière ligne peuvent surprendre: false est une expression qui ne retourne jamais d’exception, par conséquent, l’opérateur noexcept retourne true.

La STL offre aussi les traits std::is_nothrow_* pour vérifier si certaines expressions sont noexcept ; ainsi qu’une fonction std::move_if_noexcept qui retourne une rvalue si le constructeur de déplacement est noexcept et une lvalue constante dans le cas inverse.

Avant C++11, il existait le spécificateur throw() pour indiquer qu’une fonction ne jette pas d’exception. Son comportement est très différent et pas du tout efficace. En C++17, il devient l’équivalent de noexcept(true) pour finalement être supprimé en C++20.

2 fonctions qui ne diffèrent que par la spécification d’exception ne peuvent être surchargées car leur signature est identique. Ceci n’est pas autorisé:

void foo();
void foo() noexcept; // erreur

Du fait de la signature identique, noexcept peut très bien apparaître dans le prototype d’une fonction exposée dans une bibliothèque C (extern "C"), mais cette information disparaît dans la bibliothèque elle-même. Mieux que ça, si la bibliothèque est compilée sans noexcept, mais que le .h distribué les met, le compilateur retrouve ses petits, car le name mangling est le même.

Par contre, avant C++17 le type d’une fonction ne prend jamais en compte noexcept. C’est-à-dire que les types void(*)() et void(*)() noexcept sont identiques.

À partir de C++17, noexcept fait partie intégrante du type de la fonction. Un pointeur de fonction noexcept n’est pas compatible avec un pointeur de fonction qui jette potentiellement une exception. Néanmoins, une fonction noexcept est convertible en un pointeur de fonction qui n’est pas noexcept. Les posts conditions sont plus fortes ce qui ne brise pas le LSP.

void foo() noexcept;
void bar();

void(*f)() noexcept = foo;
void(*f)() noexcept = bar; // non depuis C++17

void(*g)() = bar;
void(*g)() = foo; // ok

Cette caractéristique s’applique aussi aux fonctions virtual.

class A
{
  virtual void foo() noexcept = 0;
  virtual void bar() = 0;
};

class B : A
{
  void foo() override; // il manque noexcept
  void bar() noexcept override; // ok, plus de restriction sur les conditions de sortie
};

class C : B
{
  void bar() override; // erreur, même si A::bar() n'est pas noexcept, B::bar() l'est
};

Finalement il n’y a pas grand chose à retenir. noexcept permet certaines optimisations, mais appliqué n’importe comment il est source de bug. Si vous n’êtes pas sûr, ne l’utilisez pas.

Cependant, comme cela influence les conteneurs de la STL, il faut impérativement penser à le mettre sur le constructeur de déplacement.

Depuis C++11, un nouveau type de tableau fait son apparition: std::array. S’il est là, ce n’est pas uniquement parce que la STL est cool, mais bien parce que les tableaux C posent des problèmes dans lesquels les débutants sautent à pieds joints.

Le tableau C a l’alarmante faculté de se convertir en pointeur par simple affectation ou opération arithmétique. Par exemple, Soustraire 2 tableaux donne la distance qui sépare les 2 variables dans la mémoire, ce qui n’a aucun sens. Mais puisque les tableaux se dégradent en pointeur, le compilateur l’accepte sans broncher.

Le seul pseudo-avantage est l’arithmétique des pointeurs qui permet de manipuler un tableau presque comme un pointeur – à la différence que l’incrémentation et la décrémentation ne sont pas possibles.

Ainsi, on pourra écrire auto* p = a + i plutôt que auto* p = &a[i].

Ou encore &i[a] (i.e. &2[a]), forme uniquement valide avec des tableaux ou des pointeurs. Tant qu’à hériter du C, prenons le meilleur… :D

Voici une fonction tout à fait banale qui affiche les valeurs d’un tableau:

void print(int const array[3])
{
  for (int i : array)
  {
    std::cout << i << "\n";
  }
}

Fonction qui ne compile pas, car array n’est pas un tableau, mais un pointeur. Et un pointeur ne fonctionne pas avec les boucles sur intervalle. Gcc indique l’erreur en affichant le prototype tel qu’il devrait être lu: “dans la fonction void print(const int*)”. Clang va même jusqu’à dire qu’un paramètre de type int[3] est considéré comme un pointeur. La conversion en pointeur se propage même à ce niveau.

Ce qui veut dire qu’écrire un prototype qui prend un tableau de 3 int est un mensonge. Le compilateur ne fera aucune vérification sur la taille du tableau passé en paramètre. Pour lui, que l’argument soit un tableau de 1, 2, 3 ou plus d’éléments, c’est pareil: un pointeur. Par conséquent, les 4 prototypes suivants sont strictement identiques:

void print(int const array[4]);
void print(int const array[3]);
void print(int const array[]);
void print(int const* array);

Bien sûr, il est possible d’avoir un vrai tableau en paramètre avec l’aide des références et d’une syntaxe alambiquée:

void print(int const (&array)[3]); // bienvenue dans le monde merveilleux de C++

À ce moment, le compilateur considère array comme étant un tableau de 3 entiers constants et la boucle précédente pourra fonctionner. Si l’utilisateur met un tableau de moins ou de plus de 3 éléments, le compilateur va gentiment l’envoyer bouler.

Il est possible de convertir un tableau C en entier sans faire exprès, de la même manière qu’un pointeur se convertit en entier.

using T = unsigned long long;

void foo(T);

int a[10];

foo(T(a1)); // ok, on passe l'adresse de `a`. À ne pas confondre avec la valeur du premier élément

J’ai déjà eu ce genre d’erreur dans un code proche de write(a, std::size_t(a)) à la place de write(a, std::size(a)).

Lorsqu’on déclare un tableau multidimensionnel, l’ordre des dimensions est à lire à l’envers. Ce qui n’est pas le cas en utilisant des alias.

int a[2][3]; // tableau de 2 tableaux de 3 int

using A = int[2]; // tableau de 2 int
A a[3]; // tableau de 3 tableaux de 2 int

Le tableau est le seul type du C qui ne supporte ni la copie, ni l’affectation, ce qui le rend inutilisable en retour de fonction ou dans n’importe quel conteneur de la STL tel que std::vector. Il n’est pas non plus possible de construire un tableau directement dans l’appel d’une fonction sauf en C99 ou C++ avec un cast ou à travers un alias.

// cast
foo((int[]){1,2});

// alias
template<class T>
using carray = T[];

foo(carray<int>{1,2});

Par contre, une structure qui contient un tableau est aussi bien copiable qu’affectable. Manipuler un tableau directement impose plusieurs contraintes complètement loufoques, mais mettez le tout dans une boîte et tout est permis. Ce qui m’amène à std::array, car il fait justement office de boîte.

Le gros avantage de std::array est son interface commune avec les autres conteneurs:

• size()
• empty()
• begin()/end()
• data()

Ainsi que quelques membres utilitaires comme fill(), front(), back() et la panoplie de type comme value_type, reference, etc qu’on s’attend à voir.

Si je prends le cas de size(), la version tableau C est beaucoup plus compliquée: sizeof(array)/sizeof(array[0]), Mais aussi dangereuse, car le comportement sera totalement imprévisible si, suite à un refactoring, notre tableau est remplacé par std::vector.

La manière intelligente de faire consiste en une fonction libre size(T(&)[N]) qui s’occupe de cela pour nous. Si le type change, alors la fonction ne correspond plus et des erreurs apparaissent. Au passage, C++17 introduit std::size(cont), std::empty(cont) et std::data(cont) valides pour tous les conteneurs, y compris les tableaux. Voici un article de Lmghs sur le sujet et les raisons de ce choix.

Dans certaines circonstances, on peut vouloir un tableau de 0 élément. Cela fonctionne très bien avec std::array contrairement au tableau C qui doit utiliser une extension du compilateur pour le supporter (c’est interdit par le standard). Pour pallier à ce problème avec les tableau C, sa taille est généralement forcée à 1, mais d’autres complications surviennent dès que les types ne sont pas trivialement constructibles.

Propriété anecdotique, les fonctions et classes associées au tuple sont disponibles pour std::array. Cela permet par exemple de jouer avec std::apply pour transformer un std::array en un pack variadique.

std::array<int, 3> a{1,2,3};
int sum = std::apply([](auto... xs){ return xs + ...; }, a);

Dans la pratique, il n’y a pas d’inconvénient à le faire sur un tableau C ici, mais le standard ne le prévoit pas.

Un gros avantage du tableau C se situe sur la déclaration de la taille au moment de l’initialisation: le compilateur peut la déduire. Alors qu’avec std::array il faut la mettre en paramètre template au risque d’y mettre une valeur trop grande (une valeur trop petite donne une erreur).

Sauf que depuis C++17, les guides de déduction rendent optionnels les paramètres template. Ce n’est pas un strict équivalent puisque le type est aussi déduit, mais c’est généralement ce qu’on veut car tous les éléments doivent être du même type¹. Dans le pire des cas, on peut se tourner vers quelque chose comme std::make_array<T>(xs...) (en TS) qui permet de spécifier le type du tableau sans indiquer explicitement la taille.

int a1[3]{1,2,3}
int a2[]{1,2,3} // taille implicite

std::array<int, 3> a3{1,2,3};
std::array a4{1,2,3}; // taille et type implicites
std::array a5 = std::make_array<int>(1,2,3); // taille implicite

Depuis plusieurs années maintenant, j’utilise Zsh comme shell par défaut. Et par la force des choses, il m’arrive de taper des commandes zsh, de faire des boucles zsh, de penser zsh. Bref, de coder en zsh. Bien que le langage a des inconvénients, il possède de nombreuses fonctionnalités qui recouvrent celles de certains utilitaires Unix.

Les gros avantage d’utiliser zsh plutôt que les commandes Unix sont au nombre de 3:

• Pas de post traitement pour mettre le résultat d’une commande dans une variable.
• Beaucoup plus rapide que lancer une commande. La création de process prend du temps et se ressent dans une boucle.
• Écrire en 3 lettres ce qu’on peut faire en 32. C’est-à-dire frimer ;).

Il y a aussi des inconvénients:

• Moins lisible, surtout lorsque l’on remplace une suite de pipe comme aaa | bbb | ccc. Mais on peut simplifier avec des variables intermédiaires.
• Peut être plus lent lorsqu’il y a beaucoup de texte à manipuler. En gros, faire un grep d’un fichier de 1000 lignes est plus lent qu’avec zsh, mais plus rapide si le fichier fait 100000 lignes, car zsh ne travaille pas par flux.

Le man de zsh fait plus de 5 fois celui de bash. Le manuel est tellement gros qu’il est divisé en 16 parties + un man zshall pour les afficher tous. Difficile de tout mettre en 1 article alors je me contente de certaines parties de zshexpn (zsh expansion and substitution). Parmi celles utilisées ici il y a les options d’expansion de paramètres (${(@)x}) et les modificateurs (${x:h} ou $x:h). Il existe un pdf compilant les options et syntaxe de zsh: http://www.bash2zsh.com/zsh_refcard/refcard.pdf.

Voici comment les scripts zsh peuvent lire un fichier et mettre chaque ligne dans un tableau grâce aux extensions de paramètres:

content=$(<file) # lire un fichier
content=$(<file1 <file2) # lire 2 fichiers (si multios est activé)
content=$(<file ; ls) # lire un fichier et le retour de la commande `ls`

lines=( ${(f)content} ) # tableau sans ligne vide
lines=( ${(s:\n:)content} ) # équivalent
lines=( "${(@f)content}" ) # tableau avec toutes les lignes (il faut les quotes et @)

lines=( ${(f)$(<file)} ) # forme condensée du premier cas

# -E permet de désactiver l'interpréation des séquences d'échappement (ex. \e)
echo -E ${(j:\n:)lines} # concatène les lignes avec \n
# ou
echo -E ${(F)lines}

# affiche chaque ligne d'un fichier dans des crochets
echo -E "[${(j:]\n[:)"${(@f)$(<file)}"}]"

Il y a encore de nombreux paramètres qui peuvent être trouvés dans le manuel ou via l’auto-complétion de zsh. Aussi, pour simplifier les exemples qui suivront, j’utiliserai directement les variables content et lines.

Petite note concernant echo: comme cette commande prend des arguments, le contenu affiché peut influencer le résultat. Pour éviter tout problème, il vaut mieux partir sur une redirection de flux de cette forme >&1 <<<$content. Équivalent à cat <<<$content mais sans appel de commande.

L’une des grandes forces de zsh réside dans le globbing. Il ne se restreint pas qu’à la recherche de fichier, mais peut aussi s’appliquer sur les éléments d’un tableau ou des chaînes pour filtrer ou transformer. En plus de * et ?, zsh comprend [...], [^...] et <x-y> pour un nombre entre x et y inclu (<-> pour n’importe quel nombre).

Avec le glob étendu (setopt extendedglob) on possède alors un équivalent des regex:

• x# 0 ou plus de x
• x## 1 ou plus de x
• x~y exclut y de x
• ^x tous sauf x
• (#s) début (équivalent de ^ des regex)
• (#e) fin (équivalent de $ des regex)

Ainsi que la syntaxe ksh si activée

Maintenant que la petite introduction syntaxique est faite, on peut s’attaquer au remplacement des commandes systèmes. Bien sûr, toutes les options d’une commande ne peuvent pas être simulées facilement avec zsh, mais je présente ici l’essentiel. Je précise que les commandes bash ont implicitement <<<$content comme flux de lecture et que le résultat des commandes zsh est fait avec un echo -E.

Je conseille aussi le petit Zsh Native Scripting Guide.

(#i) pour insentive n’est utilisable qu’avec setopt extendedglob et peut s’appliquer sur un groupe seulement de caractère (i.e. ((#i)a)lbator). Il existe l’option inverse: #I. Ainsi que #l qui fait une recherche insensible à la case pour les lettres minuscules du pattern, et en majuscule pour celles en majuscule dans le pattern.

agrep pour “approximate grep”. C’est un grep qui autorise une marge d’erreur dans la recherche. Zsh possède une option de glob qui fait à peu près la même chose: (#a3) pour une recherche avec 3 erreurs.

Malheuresement, un nombre négatif en dehors du tableau va afficher un contenu vide. Si on veut un strict équivalent, il faut faire un petit calcul mathématique:

n=10

result=$lines[$((n > $#lines ? 1 : -n)),-1]

Pour celui-là, l’entrée sera le texte ci-dessous. Le programme va coloriser le préfixe.

info: un alligator dort sur le balcon
avertissement: l'alligator se réveille
erreur: l'alligator attaque
note: penser à investir dans une porte plus solide