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.
