Bonjour à tous ! Après ce mois et demi d’absence, je vous propose de commencer doucement avec un petit article dédié à un ajout de C++20 : explicit (bool).
Cette proposition vient de la problématique qui se pose lorsqu’on souhaite proposer un constructeur qui soit conditionnellement explicit.
Il y a quelques temps, la proposition “Improving pair and tuple“ a introduit une amélioration sur les deux conteneurs standards de manière à proposer un constructeur explicit si le type des arguments ne peut pas être converti en le type voulu, ce qui était alors nommé la perfect initialization :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
#include <type_traits> #include <utility> template<class T> struct A { template<class U, typename std::enable_if< std::is_constructible<T, U>::value && std::is_convertible<U, T>::value , bool>::type = false > A(U&& u) : t(std::forward<U>(u)) {} template<class U, typename std::enable_if< std::is_constructible<T, U>::value && !std::is_convertible<U, T>::value , bool>::type = false > explicit A(U&& u) : t(std::forward<U>(u)) {} T t; }; |
L’idée est donc d’utiliser std::enable_if pour proposer soit la version explicit =du constructeur (si au moins l’un des éléments n’est pas convertible) soit la version classique.
Dans la P0892 dont il est question aujourd’hui, des exemples de la STL tels que std::pair, std::tuple ou encore std::variant sont cités, puisqu’en effet, ils s’agit de cas classiques où un constructeur conditionnellement explicit est utile.
Le code d’exemple proposé pour std::pair utilise donc la même méthode pour proposer deux versions du constructeur :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
template <typename T1, typename T2> struct pair { template <typename U1=T1, typename U2=T2, std::enable_if_t< std::is_constructible_v<T1, U1> && std::is_constructible_v<T2, U2> && std::is_convertible_v<U1, T1> && std::is_convertible_v<U2, T2> , int> = 0> constexpr pair(U1&&, U2&& ); template <typename U1=T1, typename U2=T2, std::enable_if_t< std::is_constructible_v<T1, U1> && std::is_constructible_v<T2, U2> && !(std::is_convertible_v<U1, T1> && std::is_convertible_v<U2, T2>) , int> = 0> explicit constexpr pair(U1&&, U2&& ); }; pair<string, string> safe() { return {"meow", "purr"}; // ok } pair<vector<int>, vector<int>> unsafe() { return {11, 22}; // error } |
Cependant, cela nécessite de définir deux fois le constructeur. C’est pour quoi la P0892 propose d’ajouter une nouvelle forme pour le spécificateur explicit prenant un booléen en argument. A la manière de noexcept et noexcept(bool) , le constructeur sera explicit si l’expression est évaluée à true.
Avec l’exemple précédent de std::pair , C++20 permet donc de faire plus simple :
|
1 2 3 4 5 6 7 8 9 10 11 |
template <typename T1, typename T2> struct pair { template <typename U1=T1, typename U2=T2, std::enable_if_t< std::is_constructible_v<T1, U1> && std::is_constructible_v<T2, U2> , int> = 0> explicit(!std::is_convertible_v<U1, T1> || !std::is_convertible_v<U2, T2>) constexpr pair(U1&&, U2&&); }; |
Le code permet donc de ne définir qu’une fois la fonction plutôt que de s’appuyer sur une double définition. Le papier propose également un exemple équivalent utilisant les concepts de C++20 :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
template <typename T1, typename T2> struct pair { template <typename U1=T1, typename U2=T2> requires std::is_constructible_v<T1, U1> && std::is_constructible_v<T2, U2> && std::is_convertible_v<U1, T1> && std::is_convertible_v<U2, T2> constexpr pair(U1&&, U2&&); template <typename U1=T1, typename U2=T2> requires std::is_constructible_v<T1, U1> && std::is_constructible_v<T2, U2> explicit constexpr pair(U1&&, U2&&); }; |
Qui devient avec explicit(bool) :
|
1 2 3 4 5 6 7 8 9 |
template <typename T1, typename T2> struct pair { template <typename U1=T1, typename U2=T2> requires std::is_constructible_v<T1, U1> && std::is_constructible_v<T2, U2> explicit(!std::is_convertible_v<U1, T1> || !std::is_convertible_v<U2, T2>) constexpr pair(U1&&, U2&&); }; |
On constate encore une fois que ça simplifie pas mal le code. Une série d’articles est d’ailleurs prévue au sujet des concepts, mais je ne peux pas encore donner de date étant donné que c’est un gros morceau ;).
Du point de vue grammaire, notez aussi que explicit, qui faisait partie des function-specifier aux côtés de virtual, a désormais sa propre classe lexicale explicit-specifier.
L’introduction de cette nouvelle syntaxe rend certaines constructions invalides, puisque ce qui est entre parenthèse à la suite du spécificateur explicit est désormais considéré comme faisant part de celui-ci. cppreference donne un exemple de code désormais invalide :
|
1 2 3 4 |
struct S { explicit (S)(const S&); // error in C++20, OK in C++17 explicit (operator int)(); // error in C++20, OK in C++17 }; |
Voilà, un petit article pour se remettre dans le bain. Je vous remercie de m’avoir lu et je vous dis à très vite =).
You must log in to post a comment.