Le blog déménage

Je me rends compte que je n'ai jamais fait d'article pour annoncer la nouvelle: l’adresse du blog devient https://jonathanpoelen.github.io À quelques exceptions, tous les articles ont été migré sur le nouveau blog. Il y en a même des nouveaux !

Comment se passer de std::forward.

Actuellement en pleine écriture d'une fonction match (petit projet de 200 lignes actuellement), je me retrouve, pour respecter le perfect forwarding, avec une armée de std::forward utilisée à chaque appel de fonction. J'en compte 21 pour un total de 6 niveaux d'imbrications. Autant dire qu'oublier de le mettre est plutôt facile.

Pour réduire son utilisation et alléger le code, je me suis fait un petit wrapper qui sauvegarde le type de référence. Comme l'objet créé a pleinement connaissance du type de variable qu'il contient et que traverser une chaîne de fonctions ne fait pas disparaître cette information, il n'y a plus besoin de std::forward. Le dernier maillon peut alors extraire une lvalue ou une rvalue via -par exemple- une fonction `get()`.

Pour illustrer, voilà ce que cela donne:

template<class T>
struct forwarder
{
  T & x;
  T && get() const { return static_cast<T&&>(x); }
};

template<class T>
struct forwarder<T&>
{
  T & x;
  T & get() const { return x; }
};


#include <iostream>

template<class T> void print(T &&) { std::cout << "&&\n"; }
template<class T> void print(T &) { std::cout << "&\n"; }

// dernier niveau d’imbrication avant l'appel de la vrai fonction
// note: le coup d'une copie est nulle pour le type forwarder
template<class T> void f1(T x) { print(x.get()); }

// pas besoin de std::forward
template<class T> void f2(T x) { f1(x); }

// premier maillion, création du contexte
template<class T> void foo(T && x) { f2(forwarder<T>{x}); }

int main() {

  int i = 1;
  int const ci = 2;

  foo(i); // &
  foo(ci); // &
  foo(3); // &&
  foo(std::move(i)); // &&
  foo(std::move(ci)); // &&

}

Avec 2 fonctions d'accès par référence en plus (ref et cref pour la version const) on possède une petite classe qui simplifie pas mal la vie.

[C++] Filtrage par type

Exécuter du code dépendant du type des entrées est le principe même de la surcharge. La procédure est plutôt simple pour les types concrets, mais devient rapidement compliquée quand des templates interviennent avec des priorités de concept.

Pour exemple, une fonction foo() spécialisée dans l'ordre pour les types flottants, signés et non-signés requière 3 prototypes de la forme:

enable_if_t<   is_floating_point_v<T> > foo(T);
enable_if_t< ! is_floating_point_v<T> &&   is_signed_v<T> > foo(T);
enable_if_t< ! is_floating_point_v<T> && ! is_signed_v<T> > foo(T);

Comme is_signed inclut également les nombres flottants, il faut les exclure pour empêcher tout appel ambigü, ce qui tend le prototype à grandir inexorablement.

Une première approche consiste à la création d'une hiérarchie de fonctions.

- is_floating_point foo()
- ! is_floating_point foo()
  \- is_signed foo_with_integral()
  \- ! is_signed foo_with_integral()

Ce qui accroît le nombre de fonctions et n'est pas vraiment plus lisible.

Les autres solutions passent par les tags, la spécialisation de template et d'autres que j'oublie peut-être. Au final, la problématique est très proche de l'article précédent concernant static_if.

La solution aussi :D.

Le plus simple consiste en un pattern chaîne de responsabilité appliqué aux protypes de fonction.
Pour rappel, ce pattern permet d'exécuter la première fonction qui répond à une demande. Ici, notre demande sera: cette fonction peut-elle être appelée avec tel type de variable ?

// foo(T xxx)
select(
  xxx,
  if_<std::is_floating_point>([](auto & x) { ... }),
  if_<std::is_unsigned>([](auto & x) { ... }),
  if_<std::is_signed>([](auto & x) { ... }),
  // et plus
  [](std::string const & x) { ... },
  [](auto & x) -> decltype(x.foo()) { ... },
  // ...
  [](auto & x) { static_assert(decltype(void(x),1){},
    "Oups, il n'y a pas de correspondance :/"
  ); }
);


// Implémentation (présentation de la méthode: ici)

template<template<class> class Tpl, class F>
struct case_tpl
{
  F f;

  template<class T>
  auto operator()(T && x, std::enable_if_t<Tpl<std::decay_t<T>>{}>* = 0) const
  { return f(std::forward<T>(x)); }
};

template<template<class> class Tpl, class F>
case_tpl<Tpl, F> if_(F && f) {
  return {f};
}

template<class T>
void select_impl(int, T &) {}

template<class T, class Fn, class... Fns>
auto select_impl(int, T & x, Fn & fn, Fns & ...)
-> decltype(fn(x)) {
  return fn(x);
}

template<class T, class Fn, class... Fns>
auto select_impl(unsigned, T & x, Fn &, Fns & ... fns) {
  return select_impl(1, x, fns...);
}

template<class T, class... Fns>
auto select(T && x, Fns && ... fns) {
  return select_impl(1, x, fns...);
}

On peut même faire une implémentation qui utilise la surcharge et ainsi avoir une garantie forte que seule une fonction existe pour un type donné.

Avec les inconvénients concernant les appels ambigüs ;).

template<class T, class Fn>
auto match(T & x, Fn f) {
  return f(x);
}

template<class T, class Fn1, class Fn2, class... Fns>
auto match(T & x, Fn1 && fn1, Fn2 && fn2, Fns && ... fns) {
  struct F : Fn1, Fn2 {
    using Fn1::operator();
    using Fn2::operator();
    F(Fn1 f1, Fn2 f2) : Fn1(f1), Fn2(f2) {}
  };
  return match(F{fn1,fn2}, fns...)
}

[c++] static_if

Le but de `static_if` est de ne pas vérifier la validité d'un code dans la phase de compilation. Le code doit être syntaxiquement valide, mais n'a pas l'obligation de pouvoir être compilé.

Plutôt étrange n'est-ce pas ? Cette propriété se révèle pourtant fort pratique dans les fonctions templates. Prenons comme exemple relativement bidon une fonction `foo(T & array)` qui vérifie si `array.size()` est au moins à 4 et, dans le cas contraire, agrandit le container avec `array.resize(4)`.

// pour T[N]
if (std::is_array<T>{})) {
  static_assert(std::extent<T>{} >= 4, "");
}
// pour std::vector
else { 
 array.resize(4);
}

Le problème ici: `static_assert` est toujours exécuté et `resize()` toujours évalué. Résultat, le code ne compile jamais, car `resize()` n'existe pas pour les tableaux et `size()` n'est pas `constexpr` pour `std::vector`.

Évidemment, `static_if` résout le problème. Dit comme cela, on pourrait croire que c'est un nouveau mot clef du langage, mais non. (Il eut une proposition dans ce sens, mais celle-ci fut rejetée.) Alors comment faire ?

Alternatives au static_if

En réalité, il existe plusieurs alternatives utilisées, et ce, bien avant C++11.

Trait et tag

Parmi celles qui font le sujet d'un de mes articles: les 'tags', souvent associés à un type_trait pour l'extraction.

Sur le principe, un type catégorie est extrait d'un paramètre et propagé à des fonctions surchargées sur la catégorie désirée. Malheureusement, cette approche disperse le code et rend la lecture difficile pour des besoins spécifiques et ponctuels. L'autre inconvénient est la transmission du scope de variable qui s'avère délicat (c'est une union (dans le sens mathématique) de toutes les variables utilisées par l'ensemble des surcharges).

Spécialisation de template

Sans plus m'étendre sur cette technique, le principe est exactement le même que pour les tags, sauf que l'on remplace la surcharge de fonction par de la spécialisation de template.

Classes internes sélectionnées avec std::conditional

La classe interne (comme utilisée dans l'article précédent) permet un code monolithique, mais n'a pas de conséquence sur le scope de variable, il faut toujours le propager. Sa lourdeur d'écriture est aussi un peu rédhibitoire.

Lambda

Les lambdas permettent de capturer le scope et se définissent n'importe où. Mais un problème survient, comment empêcher l'évaluation de la lambda si la condition n'est pas respectée ?

Depuis C++14, il existe les lambdas polymorphes. Celles-ci permettent l'usage de template à travers un type `auto`. Comme les templates ne sont évaluées qu'à leur appel, on peut faire du branchement conditionnel à la compilation en utilisant de la surcharge sur `std::true_type` et `std::false_type`. Au final, static_if devient un appel de fonction.

#include <type_traits>

class dummy { dummy(){} void operator()() const {} };

template<class TrueFn, class FalseFn = dummy>
auto static_if(std::true_type, TrueFn yes_fn, FalseFn const & = FalseFn{}) {
  return yes_fn(std::true_type{});
}

template<class TrueFn, class FalseFn>
auto static_if(std::false_type, TrueFn const &, FalseFn no_fn) {
  return no_fn(std::false_type{});
}


template<class T>
void foo(T & array) {
  static_if(std::is_array<T>{}, [&](auto){
    static_assert(std::extent<T>{} >= 4, "");
  },
  /*else*/[&](auto){
    array.resize(4);
  });
}


#include <vector>

int main()
{
  {
    std::vector<int> a;
    foo(a); // ok
  }
  {
    int a[5];
    foo(a); // ok
  }
  {
    int a[2];
    foo(a); // static_assert
  }
}

J'ai mis une valeur arbitraire pour le paramètre envoyé aux lambdas, on pourrait aussi le rendre optionnel en utilisant la méthode présentée dans cet article.

L'implémentation de static_if ne se prête pas très bien à l'imbrication. Une autre manière de faire, passe par une classe et du chaînage `static_if(...).else_if(...)`. C'est un peu plus compliqué si on veut un type de retour et on ne pourra pas utiliser de AAA sans appeler explicitement une fonction `eval()`.

auto xxx = static_if(..., []{ return 1; }).else_([]{ return 2; });
// decltype(xxx) != int (définit par l'implémentation de static_if)
auto xxx = static_if(..., []{ return 1; }).else_([]{ return 2; }).eval();
// decltype(xxx) = int

Je pense qu'il vaut alors mieux se tourner vers une forme proche du switch.

static_switch(xxx
, case_<std::is_array>() = [&](auto){ static_assert(std::extent<T>{} >= 4, ""); }
, case_<yyy>() | case_<zzz>() = [&]{ ... }
, default_ = []{ ... }
);

Que je laisse à la discrétion de chacun ;)

Paramètres de fonction nommés en C++

Cet article est la démonstration de l'article précédent. La problématique présentée est la suivante: "Comment, dans une fonction avec plusieurs paramètres optionnels, initialiser un paramètre précis sans indiquer les valeurs optionnels qui précèdent ?"

La fonction de référence sera la suivante:

void draw_rect(
  unsigned w, unsigned h
, char border_top = '-', char border_bottom = '-'
, char border_left = '<', char border_right = '>'
, char fill = '#'
) {
  std::cout << std::setfill(border_top) << std::setw(w+2) << "" << "\n";
  while (h--) {
    std::cout << border_left << std::setfill(fill) << std::setw(w) << "" << border_right << "\n";
  }
  std::cout << std::setfill(border_bottom) << std::setw(w+2) << "" << "\n";
}

Comment faire un appel proche de `draw_rect(4,3, fill='@')` ?

Création d'un paramètre nommé.

La première étape consiste à créer un type par paramètre optionnel. Comme je n'ai pas envie de me compliquer la vie, la syntaxe `fill='@'` qui demande plus de code sera remplacer par un simple appel de constructeur `fill{'@'}`.

La définition des types devient alors véritablement simpliste:

struct border_top { char value; };
struct border_bottom { char value; };
struct border_left { char value; };  
struct border_right { char value; };
struct fill { char value; };

Adapter draw_rect.

Au lieu d'adapter draw_rect, je vais passer par une surcharge, ceci n'impactera pas le résultat.

La nouvelle fonction doit pouvoir prendre les nouveaux types, mais pas forcement tous et de préférence dans un ordre indéfini.

On pourrait faire toutes les surcharges possibles, il n'y a "que" plus d'une centaine de possibilités après tous... Solution rejetée, évidemment ;).

Une variadique template fera l'affaire.

template<class... Ts>
void draw_rect(unsigned w, unsigned h, Ts... params);

Il reste maintenant à associer chaque type de `params` avec le paramètre de notre premier prototype de draw_rect.

Distribution des paramètres.

C'est là qu'intervient le magasin de type de l'article précédant (toujours pas trouvé de meilleur nom).

Le principe est simple, toutes les valeurs de params sont regroupées sous une même enseigne appelé ici 'pack'. On vérifie si le pack est convertible en un type voulu et dans le cas contraire, on utilise une valeur par défaut.

Notre pack ressemble à ça:

struct Pack : Ts... {
  Pack(Ts... args) : Ts(args)... {}
} pack{params...};

Et la distribution des paramètres se fait ainsi:

draw_rect(w, h
, getval<border_top>(pack, '-')   
, getval<border_bottom>(pack, '-')
, getval<border_left>(pack, '<')  
, getval<border_right>(pack, '>')
, getval<fill>(pack, '#')  
);

Pour les plus attentifs (il m'a fallu 2 jours pour le réaliser xD), rien n'empêche d'envoyer des paramètres inutiles, on peut l'empêcher grâce à un static_assert avec une condition style `std::is_convertible_t<border_top>() + std::is_convertible<border_bottom>() + /*etc*/ == sizeof...(Ts)`.

Dans l'histoire, bien que largement surmontable, getval est la fonction la plus compliquée. Si Pack est convertible en T alors Get::get() est utilisé, sinon Default::get().

template<class T, class Pack>
char getval(Pack & pack, char default_) {
  struct Get     { static char get(T item, char         ) { return item.value; } };
  struct Default { static char get(Pack &, char default_) { return default_;   } };
  return std::conditional<std::is_convertible<Pack, T>::value, Get, Default>::type
  ::get(pack, default_);
}

Conclusion

Je trouve la technique du 'pack' très adapté pour les paramètres optionnel. Contrairement à l'alternative hyper lourdingue via fonctions récursives et 2 tuples (un des paramètres reçus + un des paramètres triés), getval() est plutôt limpide. Aspect suffisamment rare dans le domaine de la méta-programmation pour être souligné ^^.

Les choses se compliquent quand on veut récupérer un type partiel d'un pack. Un std::vector<T> par exemple. Actuellement, je n'ai pas de solution aussi simple qu'utiliser is_convertible. J'espère dans les prochains jours trouver une solution et l'ajouter à Falcon.Store.

Pour aller plus loin dans la voie des paramètres nommés, il existe Boost.Parameters.

Implémentation d'un magasin de type

Ce que j'appelle ici un magasin de type n'est autre qu'un std::tuple où les types ne sont présents qu'une seule fois. Une espèce de set version tuple en somme.

Je me suis servi de ce type de structure à 2 reprises.

Une fois pour manipuler de façon similaire des types hétérogènes sans la lourdeur de std::tuple. Il faut dire aussi que j'étais en C++11 et que dans cette norme std::get<Type>() n'existe pas.

L'autre fois dans une fonction variadique qui distribue les valeurs vers différentes fonctions. Le but étant de ne pas se soucier de l'ordre des paramètres, certains étant optionnels.

std::tuple fait plutôt bien le boulot, mais possède plusieurs inconvénients pour ce cas de figure.

• Aucune erreur de compilation si un type est présent 2 fois (et c'est normal pour un tuple).
• Prend beaucoup de mémoire et de temps de compilation (osef !)

Je pourrais faire l'apologie de RapidTuple histoire de me faire mousser (le projet contient un tuple_set), mais en fait non, on peut faire encore plus simple en 10 lignes de code :).
Bon ok, 3 lignes.
Mais 10 pour rendre pratique ;).

Planter la compilation quand un type est en doublon.

Le C++ dispose déjà d'un mécanisme interne qui vérifie et hurle au scandale si un type doublon existe. J'ai nommé l'héritage.

Seulement, un héritage direct n'est pas possible avec les types scalaires, il faut un intermédiaire.

template<class T> struct item { T x;  }; 

template<class... Ts>
struct store : item<Ts>... {}; 

Avec cette implémentation, des petits malins pourraient faire de la pseudo-duplication de type en y ajoutant des qualificatifs, store<int, int const> par exemple.

On peut être tolérant ou devenir un tyran sans pitié en empêchant cela.

template<class... Ts>
struct tyrannical_store_impl : store<std::remove_cv_t<Ts>...> {
  using type = store<Ts...>; 
}; 

template<class... Ts>
using tyrannical_store = typename tyrannical_store_impl<Ts...>::type; 

Le store tyrannique est construit en 2 étapes, car un alias direct sur un store épuré ne permet pas de garder les qualificatifs.

Piocher dans le magasin.

Piquer un élément du magasin est une affaire de cast. Un simple static_cast.

store<int, char> my_store; 

static_cast<item<int>&>(my_store).x; 

En mettant des opérateurs de cast dans la classe item, plus besoin de préciser cette dernière avec le static_cast.

template<class T> struct item {
  explicit operator T & () noexcept { return x_;  }
  explicit operator T const & () const noexcept { return x_;  }
private:
  T x_; 
}; 

store<int, char> my_store; 

static_cast<int&>(my_store); 

Petit bémol toutefois, cela ne permet pas d'enlever l'ambiguïté pour un type qui diffère uniquement par son qualificatif.

store<int, int volatile> my_store; 

static_cast<int volatile&>(my_store);  // 'store<int, volatile int>' to 'volatile int&' is ambiguous

Ce qu'il manque

• Les constructeurs, évidemment.
• Une fonction get<Type>() pour un parallèle avec la STL.
• Une fonction pour boucler sur chaque item (apply_from_store ?).
• Et sûrement d'autres.

J'ai mis tout ça dans un repo au nom provisoire (falcon.store).

Délégation d'appel de fonctions utilitaires.

Cet article fait suite à l'utilisation de swap et des fonctions utilitaires en général.

L'article précédemment cité montre pourquoi il faut exporter avec using la fonction utilitaire généraliste avant de l'utiliser. La nécessité de "déplacer" les fonctions dans le scope est lourd et facile à oublier.

L'idéal serait la présence d'une unique fonction en charge d'appeler la bonne surcharge. Heureusement, une solution existe. Elle consiste en la création d'un namespace dans lequel la fonction générale est exportée et où une fonction intermédiaire l'appelle. Comme la règle d'adl s'applique, la fonction surchargée sera appelée si existante.

#include <algorithm>

namespace fn {
  namespace {
    using std::swap;

    template<class T>
    void swap_impl(T & a, T & b)
    { swap(a,b); }
  }

  template<class T>
  void swap(T & x, T & y)
  { ::fn::swap_impl(x,y); }
}

Cependant, cette solution souffre de l'effet inverse: la fonction ne peut pas être déplacée dans le même scope qu'une fonction généraliste. Il y aurait 2 prototypes identiques, le compilateur ne pourrait pas lever l’ambiguïté. Comme il est très courant de voir `using namespace std;`, un `using fn::swap` dans le même scope rentrerait en conflit avec std::swap lors de l'appel (aucun problème si dans un sous-scope).

#include <iostream>

namespace my {
  struct A{};
  void swap(A&, A&)
  { std::cout << "ok\n"; }
}

int main()
{
  {
    my::A a, b;
    fn::swap(a,b); // affiche ok
  }
  {
    int a, b;
    fn::swap(a,b); // compile
  }

  {
    using fn::swap;
    using std::swap;
    int a, b;
    swap(a,b); // ambiguïté
  }

  {
    using std::swap;
    {
      using fn::swap;
      my::A a, b;
      fn::swap(a,b); // affiche ok
    }
  }
}

Appel conditionnel de fonction selon la validité d'une expression.

Il existe une méthode à base de trait pour changer le comportement d'une fonction. Je l'ai déjà présenté dans un article plus ancien en prenant comme exemple les itérateurs et la fonction std::advance: "taguer vos classes, cataloguées-les".

L'approche suivante consiste non plus à définir des types internes ou des traits mais vérifier qu'une fonction (membre ou statique) est appelable. De manière plus générale, la méthode présentée ici s'applique à toutes expressions.

Appeler T::sort si possible, sinon std::sort(begin(T), end(T))

L'exemple va se faire sur la classe std::list qui n'est pas triable avec std::sort mais possède une fonction membre sort(). Ainsi que sur std::vector qui, inversement, n'a pas de fonction membre sort() mais est triable avec std::sort.

La méthode est simple et consiste à créer 2 fonctions: une pour vérifie si une expression est valide (ici x.sort()) et une autre en cas d'échec.

Seulement, qui dit 2 fonctions dit 2 prototypes. Leur prototype doit être légèrement différent mais compatible avec les mêmes valeurs d'entrée pour appeler la seconde si la première échoue.

Pour vérifier l'expression, seul 2 mots clef existent: sizeof et decltype. Cette procédure est donc possible avant C++11, même si sizeof requière un peu d'enrobage.

#include <algorithm>

//avec decltype
template<class Container>
auto dispatch_sort(int, Container & c)
-> decltype(void(c.sort())) //force decltype au type void
{ c.sort(); }

template<class Container>
void dispatch_sort(unsigned, Container & c)
{
 using std::begin;
 using std::end;
 std::sort(begin(c), end(c));
}

template<class Cont>
void sort(Cont & c)
{ dispatch_sort(1,c); }

La fonction sort appel dispatch_sort avec un int (la valeur n'importe pas, seul le type compte). Comme la seule différence des 2 fonctions dispatch_sort est le premier paramètre, le prototype avec un int correspond parfaitement.

Si une fonction membre sort existe alors l'expression dans decltype est valide et la fonction est appelé. Dans le cas contraire, le compilateur cherche une fonction avec des paramètres pouvant être convertit. Le int pouvant être convertit en unsigned, le compilateur se rabat sur le second prototype qui fait appel à std::sort.

Le point clef étant de mettre toutes les informations dans le prototype. J'aurais par exemple put mettre decltype dans un paramètre initialisé avec une valeur par défaut (R f(int, decltype(xxx)* = 0); Mais il faudra probablement ajouter std::remove_reference (un pointeur sur une référence n'est pas permis))).

---

Programme de test:

#include <iostream>
#include <vector>
#include <list>

int main()
{
  std::vector<int> v({2,6,4});
  std::list<int>   l({2,6,4});

  sort(v);
  sort(l);

  for ( auto i : v ) std::cout << i << ' ';
  std::cout << '\n';
  for ( auto i : l ) std::cout << i << ' ';
}

Résultats:

2 4 6
2 4 6

---

J'ai indiqué qu'il été possible d'utiliser sizeof à la place de decltype. Voici comment:

template<std::size_t, class T = void>
struct dispatch_result_type
{ typedef T type; };

template<class T>
T declval();

template<class Container>
typename dispatch_result_type<sizeof(void(declval<Container&>().sort()),1)>::type
dispatch_sort(int, Container & c)
{ c.sort(); }

Le ,1 de sizeof(xxx,1) peut dérouter mais est requis si l'expression xxx retourne void. Comme void n'est pas vraiment un type, il ne fonctionne pas avec sizeof et il faut donc lui fournir autre chose. Il faut bien comprendre qu'ici xxx,1 est une seule expression et non pas 2 paramètres.

Bien que très peu probable, si j'ai mit void(yyy), c'est pour prévenir la surcharge de l'opérator ',' sur le type de retour retourné par yyy (car cet opérateur peut lui-même retourner un void).

sizeof ne donne pas l'information sur le type de retour mais une valeur, il est couplé à dispatch_result_type qui prend en second paramètre template le type de retour (void par défaut). Quand à declval, c'est le même principe que celui de la sl.

Réduire l'empreinte mémoire d'une agglomération de types

Un petit article pour parler d'optimisation mémoire (si on peut appeler ça comme ça) avec comme exemple la structure de donnée utilisée par std::unique_ptr.

Petit rappel, unique_ptr prend 2 paramètres en template: T et Deleter (qui est par défaut std::default_delete<T>).

Naïvement, l'implémentation serait:

template<T, Deleter = std::default_delete<T>>
class unique_ptr {
  T * m_pointer;
  Deleter m_deleter;

  //...
};

Rien d'extraordinaire.

Cependant, même si le Deleter est une classe sans attribut, sa taille est de 1 octet.

À partir d'ici je considère que Deleter est toujours la valeur par défaut, ce qui donne:

• sizeof(T*) == 4
• sizeof(Deleter) == 1
• sizeof(unique_ptr<T>) == 8

Ouille, méchant padding alors que seule 4 octets sont vraiment utilisés.

La solution ? Une classe qui contient le pointeur et hérite de Deleter. Les attributs de la classe dérivée vont se mettre après ceux de Deleter, et s'il n'en a pas, les attributs se positionnent au début de la classe.

Cette optimisation se nomme Empty Base Class Optimization (EBCO). Merci Guillaume.

template<T, Deleter = std::default_delete<T>>
class unique_ptr {
  struct Pointer : Deleter {
    T * m_pointer;
    //...
  };
  //...
};

• sizeof(unique_ptr<T>) == 4

Mieux, non ?

Et si le Deleter est une référence ? Bien entendu, l'héritage ne fonctionne pas, il faut se rabattre sur la première forme (celle naïve ^^).
Avec des traits et un code volumineux cela est "facile".

En allant encore plus loin, on peut utiliser un Deleter personnalisé final.
(Mais qui utilise des classes finales... ?)

À ce moment, évidemment, même remarque que les références, l'héritage ne compile pas et l'utilisation de la première forme s'impose.
Avec un trait is_final c'est possible, mais ce dernier n'existe pas et son implémentation est impossible... On est coincé !

Vraiment ? Non, car d'irréductibles développeurs de compilos ont créé __is_final, une fonction non-standard utilisée notamment par std::tuple.
De là à dire que toutes les implémentations l'utilisent... Il n'y a qu'un pas que je suis prêt à franchir :).
(En C++14 le trait std::is_final devient standard.)

Au final, l'utilisation de std::tuple permet de s'affranchir de ces difficultés tout en optimisant l'espace mémoire¹.

template<T, Deleter = std::default_delete<T>>
class unique_ptr {
  std::tuple<T*, Deleter> m_t;
  //...
};

Il y a toutefois un léger problème avec std::tuple. Si un élément doit être initialisé, alors ils doivent tous l'être. Cela peut causer quelques soucis si un des types n'a ni copy-ctor, ni move-ctor.

¹ À condition de mettre les types dans l'ordre croissant d'alignement afin de réduire le padding lorsqu'il y en a plus de 2 (falcon::optimal_tuple).

256 couleurs et plus dans la console

Note: ajout à la fin concernant le TrueColor.

J'ai récemment appris l'existence de 256 couleurs dans la console. À chaque fois que je cherche des infos sur les couleurs je tombe toujours sur les trucs basiques.

Mais récemment j'ai vu un peu trop de couleurs sur un screen. Ce qui m'a dirigé sur un dépôt contenant un $LS_COLORS particulièrement fourni.

En fait, il s'avère qu'en rajoutant extended dans la recherche "color shell" on puisse trouver quelque(s) ressource(s). J'aurais bien voulu y penser la semaine dernière, ça m'aurait évité de comprendre par tâtonnement...

Comme le lien ci-dessus est très bien expliqué je ne fais ici qu'un condensé. Je passe également sous silence les 8 et 16 couleurs.

Utilisation

<Esc>[FormatColorm

Le caractère <Esc> est obtenu avec les séquences suivantes:

• \e
• \033
• \x1B

(Pour bash et echo, utiliser l'option -e pour interpréter les séquences backslashés.)

FormatColor correspond à la couleur de texte, de fond ou l'effet. Plusieurs peuvent être mis en les séparant par des ';'. L'ordre n'a pas d'importance.

Couleur	Texte	Fond
Noir	30	40
Rouge	31	41
Vert	32	42
Jaune	33	43
Bleu	34	44
Magenta	35	45
Cyan	36	46
Gris clair	37	47

Les couleurs précédentes peuvent être configurées sur certains shells.

Effet	Code	Code annulation
normal	0
gras	1	21
italique	3	23
souligné	4	24
clignotant	5	25
inversé	7	27

Couleur supplémentaire en 16 couleurs (si supporté)

Couleur	Texte	Fond
Gris foncé	90	40
Rouge clair	91	101
Vert clair	92	102
Jaune clair	93	103
Bleu clair	94	104
Magenta clair	95	105
Cyan clair	96	106
Blanc	97	107

Couleur étendue avec X allant de 0 à 255 inclus:

• Texte: 38;5;X
• Fond: 48;5;X

Par contre, outre le fait que les couleurs étendues ne fonctionnent pas partout, elles peuvent allègrement pourrir le rendu. Pour retrouver un rendu normal: `tput reset`. À essayer sur les tty, c'est marrant ^^.

Le bout de code ci-dessous permet de visualiser la palette de couleur.

for m in 38 48 ; do
  n=0
  for l in {0..31} ; do
    for c in {0..7} ; do
      echo -ne "\033[$m;5;$n;1m$n\e[0m\t"
      ((++n))
    done
    echo
  done
done

TrueColor

La console supporte aussi les couleurs hexadécimal.

• \e[48;2;$r;$g;${b}m pour le fond
• \e[38;2;$r;$g;${b}m pour le texte

$r, $g et $b sont des valeurs allants de 0 à 255. Encore une fois, les effets comme gras, italique, etc, peuvent être ajoutés (echo -e '\e[38;2;205;110;0;3mplop' pour un texte couleur cuivre et italique).