Article original : Best ways to convert an enum to a string | Belay the C++ (belaycpp.com)
Traductrice : Chloé Lourseyre

Une problématique particulièrement récurrente que les développeurs C++ rencontrent (tous niveaux confondus) est comment afficher la valeur d’un enum de manière claire et lisible.

Le problème est qu’il n’y a pas une seule solution objectivement meilleure que les autres. Cela dépend beaucoup des contraintes liées à l’environnement, les besoins spécifiques et, comme toujours, la version de C++ utilisée.

Cet article compile une petite liste de manière d’ajouter la réflexivité aux enums.

NB : si vous connaissez une autre manière de faire qui a son propre intérêt, n’hésitez pas à la partager en commentaire.

Bien sûr, idéalement on voudrait que cette réflexivité soit statique. Dans la plupart des cas listés ci-dessous, on aura recours au mot-clé constexpr.

La librairie Magic Enum

Magic Enum est une librairie qui fait exactement ce qu’on cherche à faire : elle ajoute de moyens de donner la réflexivité aux enums.

Avec elle, vous pouvez convertir statiquement en chaîne de caractère (et accessoirement depuis une chaîne de caractère) des enums que vous avez définis. En gros, elle implémente l’enum_cast. Elle permet aussi d’itérer sur la liste des littéraux d’un enum.

Vous pourrez la trouver ici : GitHub – Neargye/magic_enum: Static reflection for enums (to string, from string, iteration) for modern C++, work with any enum type without any macro or boilerplate code

Inconvénients

• C’est une librairie tierce.
• Ne fonctionne qu’en C++17
• Vous avez besoin d’une version spécifique de votre compilateur pour qu’elle fonctionne (Clang >= 5, MSVC >= 15.3 et GCC >= 9)
• Elle a d’autres contraintes liées à son fonctionnement interne (consultez la page Limitations de sa documentation pour plus d’informations : magic_enum/limitations.md at master · Neargye/magic_enum · GitHub)

Utiliser une fonction dédiée (avec exception)

Version statique

constexpr est un mot-clé fabuleux qui nous permet de définir des expressions de manière statiques. Quand on l’utilise dans le type de retour d’une fonction, cela permet au compilateur d’évaluer statiquement le résultat de cette fonction.

Dans cette version, j’ai placé exception dans le default du switch-case pour s’assurer que si on ajoute un littéral mais qu’on oublie de mettre à jour la fonction, l’exception soit levée pour nous prévenir.

#include <iostream>
 
enum class Esper { Unu, Du, Tri, Kvar, Kvin, Ses, Sep, Ok, Naux, Dek };
 
constexpr const char* EsperToString(Esper e) throw()
{
    switch (e)
    {
        case Esper::Unu: return "Unu";
        case Esper::Du: return "Du";
        case Esper::Tri: return "Tri";
        case Esper::Kvar: return "Kvar";
        case Esper::Kvin: return "Kvin";
        case Esper::Ses: return "Ses";
        case Esper::Sep: return "Sep";
        case Esper::Ok: return "Ok";
        case Esper::Naux: return "Naux";
        case Esper::Dek: return "Dek";
        default: throw std::invalid_argument("Unimplemented item");
    }
}
 
int main()
{
    std::cout << EsperToString(Esper::Kvin) << std::endl;
}

Version dynamique

Le problème est qu’avoir plusieurs return dans une fonction constexpr est une fonctionnalité disponible à partir du C++14. Si vous utilisez une version antérieure, vous devez retirer le constexpr et rendre la fonction dynamique pour qu’elle compile :

#include <iostream>
 
enum class Esper { Unu, Du, Tri, Kvar, Kvin, Ses, Sep, Ok, Naux, Dek };
 
const char* EsperToString(Esper e) throw()
{
    switch (e)
    {
        case Esper::Unu: return "Unu";
        case Esper::Du: return "Du";
        case Esper::Tri: return "Tri";
        case Esper::Kvar: return "Kvar";
        case Esper::Kvin: return "Kvin";
        case Esper::Ses: return "Ses";
        case Esper::Sep: return "Sep";
        case Esper::Ok: return "Ok";
        case Esper::Naux: return "Naux";
        case Esper::Dek: return "Dek";
        default: throw std::invalid_argument("Unimplemented item");
    }
}
 
int main()
{
    std::cout << EsperToString(Esper::Kvin) << std::endl;
}

Si vous utilisez une version antérieure aux C++11, vous pouvez remplacer l’enum class par un simple enum pour que cela fonctionne.

Inconvénients

• Avoir plusieurs return dans une fonction constexpr est C++14 (pour la version statique)
• Il faut écrire une fonction par enum est ladite fonction est très verbeuse.
• Lève une exception

Utiliser une fonction dédiée sans exception)

Version statique

Parfois, on préfère un code qui ne peut pas lever d’exception, quoi qu’il arrive. Ou peut-être êtes-vous comme moi et compilez votre code avec -Werror. Dans les deux cas, vous pouvez écrire la même fonction que dans l’exemple précédent, sans lever d’exception.

Vous avez juste à surveiller les warnings quand vous ajoutez des éléments à votre enum.

#include <iostream>
 
enum class Esper { Unu, Du, Tri, Kvar, Kvin, Ses, Sep, Ok, Naux, Dek };
 
constexpr const char* EsperToString(Esper e) noexcept
{
    switch (e)
    {
        case Esper::Unu: return "Unu";
        case Esper::Du: return "Du";
        case Esper::Tri: return "Tri";
        case Esper::Kvar: return "Kvar";
        case Esper::Kvin: return "Kvin";
        case Esper::Ses: return "Ses";
        case Esper::Sep: return "Sep";
        case Esper::Ok: return "Ok";
        case Esper::Naux: return "Naux";
        case Esper::Dek: return "Dek";
    }
}
 
int main()
{
    std::cout << EsperToString(Esper::Kvin) << std::endl;
}

Version dynamique

Une fois de plus, la version dynamique sans constexpr :

#include <iostream>
 
enum class Esper { Unu, Du, Tri, Kvar, Kvin, Ses, Sep, Ok, Naux, Dek };
 
const char* EsperToString(Esper e) noexcept
{
    switch (e)
    {
        case Esper::Unu: return "Unu";
        case Esper::Du: return "Du";
        case Esper::Tri: return "Tri";
        case Esper::Kvar: return "Kvar";
        case Esper::Kvin: return "Kvin";
        case Esper::Ses: return "Ses";
        case Esper::Sep: return "Sep";
        case Esper::Ok: return "Ok";
        case Esper::Naux: return "Naux";
        case Esper::Dek: return "Dek";
    }
}
 
int main()
{
    std::cout << EsperToString(Esper::Kvin) << std::endl;
}

Inconvénients

• Avoir plusieurs return dans une fonction constexpr est C++14 (pour la version statique)
• Il faut écrire une fonction par enum est ladite fonction est très verbeuse.
• Il y a un risque de ne pas voir les warnings quand un élément est ajouté sans que la fonction soit mise à jour.

Avec une macro

Les macros peuvent faire beaucoup de choses que le code dynamique ne peut pas faire. Voici deux implémentations de réflexivité d’enum avec une macro.

Version statique

#include <iostream>
 
#define ENUM_MACRO(name, v1, v2, v3, v4, v5, v6, v7, v8, v9, v10)\
    enum class name { v1, v2, v3, v4, v5, v6, v7, v8, v9, v10 };\
    const char *name##Strings[] = { #v1, #v2, #v3, #v4, #v5, #v6, #v7, #v8, #v9, #v10};\
    template<typename T>\
    constexpr const char *name##ToString(T value) { return name##Strings[static_cast<int>(value)]; }
 
ENUM_MACRO(Esper, Unu, Du, Tri, Kvar, Kvin, Ses, Sep, Ok, Naux, Dek);
 
int main()
{
    std::cout << EsperToString(Esper::Kvin) << std::endl;
}

Version dynamique

Très similaire à la version statique, mais celle-ci est compatible avec du code antérieur au C++11 (constexpr et enum class sont des mots-clés apparus en C++11) :

#include <iostream>
 
#define ENUM_MACRO(name, v1, v2, v3, v4, v5, v6, v7, v8, v9, v10)\
    enum name { v1, v2, v3, v4, v5, v6, v7, v8, v9, v10 };\
    const char *name##Strings[] = { #v1, #v2, #v3, #v4, #v5, #v6, #v7, #v8, #v9, #v10 };\
    const char *name##ToString(int value) { return name##Strings[value]; }
 
ENUM_MACRO(Esper, Unu, Du, Tri, Kvar, Kvin, Ses, Sep, Ok, Naux, Dek);
 
int main()
{
    std::cout << EsperToString(Kvin) << std::endl;
}

Inconvénients

• Utilise une macro (je pourrais écrire un article parlant des macros et de leur toxicité au sein d’une codebase — j’en ai déjà un peu parlé et le referai, mais ce n’est pas le sujet ici et maintenant. Cependant, gardez à l’esprit que si vous ne savez pourquoi les macros peuvent être dangereuses, alors vous ne devriez pas les utiliser).
• Vous avez besoin d’écrire une macro différente chaque fois que vous avez besoin d’un enum avec un nombre d’éléments différents (et elle devra avoir un nom différent, ce qui est pénible).

Avec une macro et Boost

On peut contourner l’inconvénient du « nombre d’éléments dans l’enum » en utilisant des fonctionnalités de Boost.

Version statique

#include <iostream>
#include <boost/preprocessor.hpp>
 
#define PROCESS_ONE_ELEMENT(r, unused, idx, elem) \
  BOOST_PP_COMMA_IF(idx) BOOST_PP_STRINGIZE(elem)
 
#define ENUM_MACRO(name, ...)\
    enum class name { __VA_ARGS__ };\
    const char *name##Strings[] = { BOOST_PP_SEQ_FOR_EACH_I(PROCESS_ONE_ELEMENT, %%, BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__)) };\
    template<typename T>\
    constexpr const char *name##ToString(T value) { return name##Strings[static_cast<int>(value)]; }
 
ENUM_MACRO(Esper, Unu, Du, Tri, Kvar, Kvin, Ses, Sep, Ok, Naux, Dek);
 
int main()
{
    std::cout << EsperToString(Esper::Kvin) << std::endl;
}

Dans cette version (un peu plus complexe que les précédentes), PROCESS_ONE_ELEMENT « convertit » l’élément en une version « stringifiée » (à l’aide de BOOST_PP_STRINGIZE) et BOOST_PP_SEQ_FOR_EACH_I permet d’itérer sur tous les éléments de __VA_ARGS__ (qui est le pack de paramètres de la macro).

Version dynamique

Une version quasi-identique, mais une fois encore sans constexpr et sans enum class pour être compatible pré-C++11 :

#include <iostream>
#include <boost/preprocessor.hpp>
 
#define PROCESS_ONE_ELEMENT(r, unused, idx, elem) \
  BOOST_PP_COMMA_IF(idx) BOOST_PP_STRINGIZE(elem)
 
#define ENUM_MACRO(name, ...)\
    enum name { __VA_ARGS__ };\
    const char *name##Strings[] = { BOOST_PP_SEQ_FOR_EACH_I(PROCESS_ONE_ELEMENT, %%, BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__)) };\
    const char *name##ToString(int value) { return name##Strings[value]; }
 
ENUM_MACRO(Esper, Unu, Du, Tri, Kvar, Kvin, Ses, Sep, Ok, Naux, Dek);
 
int main()
{
    std::cout << EsperToString(Kvin) << std::endl;
}

Inconvénients

• Utilise une macro (…)
• Utilise Boost

NB: bien que ce soit techniquement une librairie tierce, Boost est plus facilement intégrable sur un projet que les librairies plus méconnue comme Magic Enum.

En résumé

Voici un tableau résumant les avantages et inconvénients de chaque méthode :

Je le répète : si vous connaissez une méthode intéressante de convertir un enum en string, partagez-la en commentaire !

Merci de votre attention et à la semaine prochaine !

Article original : Best ways to convert an enum to a string | Belay the C++ (belaycpp.com)
Traductrice : Chloé Lourseyre

Article original : How to choose between a setter and a reference-getter? | Belay the C++ (belaycpp.com)
Traductrice : Chloé Lourseyre

Contexte

Quand on implemente une classe, on a souvent besoin d’implémenter un accesseur pour un ou plusieurs attributs de cette classe pour les modifier.

Il y a deux manières de faire cela :

• Implémenter un setter, une méthode qui prend comme argument une nouvelle valeur à destination de l’attribut.
• Implémenter un reference-getter, une méthode qui renvoie une référence vers l’attribut lui-même.

Voici un petit exemple qui montre comment accéder à l’attribut bar en utilisant les deux méthodes :

class Foo {
    int m_bar;
 
public:
    // Setter
    void set_bar(int bar) {
        m_bar = bar;
    }
 
    // Reference-getter
    int & get_bar() {
        return m_bar;
    }
};
 
int main() {
    Foo foo;
 
    // Editing via setter
    foo.set_bar(42);
 
    // Editing via reference-getter
    foo.get_bar() = 84;
 
    return 0;
}

Certains d’entre vous objecteront peut-être qu’il existe d’autres manières d’accéder à un attribut en écriture, mais je soutiens qu’il s’agira toujours d’une variation d’une de ces deux méthodes.

Le setter

Un setter est une interface lecture-seule sur une classe. Vous lui fournissez une valeur et la classe est mise à jour en conséquence.

Souvent (mais pas toujours), cela va plus ou moins directement mettre à jour l’attribut en copiant/movant le paramètre.

Exemples

// Most simple setter
void set_foo(int foo) {
    m_foo = foo;
}

// A setter that performs a test before edition
void set_foo(Foo foo) {
    if (foo.is_valid())
        m_foo = foo;
}

// A move-setter
void set_big_foo(BigFoo && big_foo) {
    m_big_foo = std::forward<BigFoo>(big_foo);
}

Le reference-getter

Un reference-getter est une méthode qui renvoie directement une référence sur l’attribut qu’on veut éditer.

C’est particulièrement pratique sur un attribut qui est un objet sur lequel on peut appeler des méthodes non-constantes.

Exemples

// Here is the implementation of the reference-getter
Foo & MyClass::get_foo() {
    return m_foo;
}
 
// ...
 
// Used to edit an attribute
myClass.getFoo().bar = 42;
 
// Used to call a non-const method
myClass.getFoo().udpate();

Comment choisir ?

C’est assez simple quand on arrive à distinguer les différences entre les deux.

Le setter est nécessaire quand on veut recréer la valeur et la place à la place de l’existante. C’est recommandé quand on modifie des valeurs très simple (entiers, flottants, pointeurs, etc.) ou si vous avez besoin d’un objet tout neuf. De plus, on doit utiliser un setter quand on veut explicitement interdire la lecture de l’attribut (écriture-seule).

Le reference-getter est nécessaire quand ce sont les données de l’attribut qui sont modifiées (et non l’attribut lui-même). Souvent, on l’utilise pour modifier une partie seulement de l’attribut ou pour appeler des fonctions de modification dessus.

En d’autres mots, le setter remplace la valeur et le reference-getter modifie la valeur.

Exemple

Prenez ce code:

#include <vector>
 
using namespace std;
 
struct Item
{
    bool validity;
    int value;
};
 
class Foo
{
public:
    Foo(size_t size) :
        m_max_size(size),
        m_data(size, {true, 0})
    {}
 
    void set_max_size(size_t max_size) {
        m_max_size = max_size;
    }
 
    Item & get_item(size_t index) {
        return m_data.at(index);
    }
 
    size_t get_data_size() const {
        return m_data.size();
    }
 
private:
    bool m_max_size;
    std::vector<Item> m_data;
};
 
static void set_foo_size(Foo & foo, size_t new_size)
{
    foo.set_max_size(new_size);
    for (size_t i = new_size ; i < foo.get_data_size() ; ++i)
        foo.get_item(i).validity = false;
}

Ici, nous avons une simple petite classe qui détient une collection de données (des Item). Ces items peuvent être valident ou invalides (true est valide, false est invalide).

Puis, on implémente une petite fonction qui change la taille max de la collection. On choisit de ne pas enlever les éléments mais à la place de les rendre invalides.

On accède à m_max_size via un setter parque que c’est une donnée élémentaire (un size_t) qui est remplacée quand on change la taille de la collection.

On accède à chaque Item de m_data en utilisant un reference-getter car on ne veut juste modifier l’item, ni plus ni moins.

Alternative

On aurait pu faire autrement pour mettre à jour la validité, en utilisant un setter plus spécifique, comme ceci :

class Foo {
 
        // ...
 
        void set_item_validity(size_t index, bool validity) {
                m_data.at(index).validity = validity;
        }
 
        // ...
 
};

Procéder ainsi empêche de modifier la value de l’Item. De fait, la décision d’utiliser cette alternative dépendra entièrement de votre implémentation.

Cependant, il faut considérer comme mauvaise pratique le fait d’implémenter un setter pour validity et value. Le faire pour un data-bucket de deux attributs n’est pas conséquent, mais plus votre codebase grossira plus vous serez pollué·e par des accesseurs inutiles. Vous avez besoin d’un accès complet ? Implémentez un reference-getter.

En conclusion

Cela peut sembler être un sujet trivial, mais je vois beaucoup de confusion entre les deux méthodes aujourd’hui. Soyez vigilant·e·s et gardez en tête que les deux méthodes existent.

Merci de votre attention et à la semaine prochaine !

Article original : How to choose between a setter and a reference-getter? | Belay the C++ (belaycpp.com)
Traductrice : Chloé Lourseyre

Article original : Should every variable be const by default? | Belay the C++ (belaycpp.com)
Traductrice : Chloé Lourseyre

Un peu de terminologie

Dans le titre de l’article, j’utilise le mot const car const est un mot-clé que tous les développeurs C++ connaissent (enfin j’espère). Cela dit, le concept qui est adressé ici porte un nom plus générique, il s’agit de l’immuabilité. const est un mot-clé utilise dans certains langages (comme le C++ ou le Javascript par exemple) mais la notion d’immuabilité existe aussi dans d’autres langages (qui parfois n’ont même pas de mot-clé équivalent à const, comme en Rust par exemple).

Ainsi, afin d’être inclusif, j’utiliserai les mots immuable et immuabilité à la place des mots constant et constance.

Nota bene : en C++ le mot-clé const ne représente pas exactement la notion d’immuabilité. Par exemple, vous pouvez utiliser le mot-clé const dans le prototype d’une fonction pour indiquer que vous n’allez pas le modifier, mais vous pouvez tout à fait passer une variable muable à cette fonction en guise de paramètre. Cela étant dit, cet article s’en réfère à const pour son caractère à rendre les données immuables, donc je vous saurais gré d’ignorer les cas où const ne s’en réfère pas à des données qui sont immuables de manière inhérente. C’est aussi une autre raison pour laquelle je préfère dire immuable et non pas constant.

Quelques très bonnes raisons de rendre vos variables immuables

Sécurité

Ce qu’on appelle la const-correctness (qui peut être maladroitement traduit en correction de constance, avec « correction » au sens de « qui est correct ») est une notion importante en C++ qui correspond au fait que si vous spécifiez qu’une variable est immuable, alors elle ne sera pas modifiée.

La const-correctness est atteinte lorsque vous utilisez le mot-clé const pour indiquer quelles variables ne doivent pas être modifiées. Ainsi, vous ne pourrez pas modifier par inadvertance des données qui n’ont pas à l’être et cela donne une indication sémantique aux autres développeurs et au compilateur.

Documentation

Ces cinq petits caractères en disent long. Si vous vous trouvez dans un code digne de confiance, la présence -ou l’absence- du mot-clé const donne des informations importantes sur les intentions derrière telle ou telle variable.

Optimisation

Le compilateur peut (et va) optimiser le code en fonction des directives d’immuabilité

En sachant si telle ou telle variable est immuable, le compilateur pourra faire des suppositions et prendre des raccourcis.

Si vous voulez en savoir plus à ce sujet je vous conseille le talk de J. Turner : Jason Turner: Practical Performance Practices – YouTube

Sources

Si vous n’êtes toujours pas convaincu(e) que l’immuabilité est utile (au bas mot), ou si vous êtes juste curieux(se), vous pouvez lire les articles suivants :

• What does “Fred const* p” mean?, C++ FAQ (parashift.com)
• GotW #6: Const-Correctness

Y a-t-il des inconvénients à utiliser l’immuabilité dès que possible ?

Comme l’immuabilité est une restriction technique, il n’y a aucun inconvénient technique à l’utiliser.

Cependant, il peut y avoir des inconvénients plus subjectifs. Premièrement, cela augmente un peu la verbosité du code. Même s’il ne s’agit que de cinq caractères (qui dans la plupart des IDE prennent la même couleur que le type associé), certaines personnes peuvent trouver cela gênant. Il y a également une forme d’inertie qui peut apparaître : si à un moment donné vous avec besoin que la donnée soit muable, alors vous devrez aller chercher sa déclaration et la modifier. Certains considèrent cela comme une mesure de sécurité, d’autres comme un inconvénient.

Est-ce que ces arguments sont suffisants pour ne pas utiliser l’immutabilité dès qu’on le peut ? C’est à vous de juger, mais en mon humble avis, je ne pense pas.

Et les autres langages ?

D’autres langages ont effectivement rendu les variables immuables par défaut.

C’est le cas du Rust. En Rust, vous n’avez pas d’équivalent du mot-clé const, toutes les variables sont immuables par défaut. Au contraire, vous avez le mot-clé mut (pour mutable, la traduction anglaise de muable) que vous devez apposer devant chaque variable muable.

Par exemple, le code suivant ne compile pas en Rust :

fn main() {
    let foo = 2;
    println!("Foo: {}", foo);
    foo += 40; // error[E0384]: cannot assign twice to immutable variable `foo`
    println!("Foo: {}", foo);
}

Mais il faut plutôt écrire ceci :

fn main() {
    let mut foo = 2;
    println!("Foo: {}", foo);
    foo += 40;
    println!("Foo: {}", foo);
}

La raison mentionnée dans le manuel Rust est la suivante (je traduis) : « C’est un des nombreux coups de pouce que le Rust vous donne pour écrire du code qui tire profit de la sécurité […] que le langage a à offrir. »

Rust est un langage moderne qui vise à produire du code sécurisé tout en étant performant. Dans cette optique je suis d’accord avec le choix qu’il a fait de rendre les variables immuables par défaut pour la sécurité que cela apporte.

Est-il raisonnable de changer le standard pour rendre toutes les variables immuables par défaut ?

Si un jour fatidique, le C++ committee décide de rendre toutes les variables immuables par défaut… personne ne migrera vers cette nouvelle version du standard.

La rétro-compatibilité est importante pour adoucir les migrations. Il y a des exemples historiques de suppression de fonctionnalité du standard, mais à chaque fois il y avait une très bonne raison pour cela (la plupart du temps étant que cette fonctionnalité était obsolète depuis des lustres).

On ne peut pas sérieusement penser à enlever const du standard et le remplacer par un mut juste pour égard à ce qui est, en définitive, du sucre syntaxique.

Que faire alors ?

Pour ma part, j’utilise le mot-clé const systématiquement sans réfléchir, chaque fois que je déclare une variable. Je ne l’enlève que lorsque j’écris une instruction qui requiert effectivement que la variable soit muable (ou quand le compilateur me crie que j’essaye de modifier une variable constante). C’est un peu brut, mais selon moi c’est le meilleur moyen d’acquérir le bon réflexe de mettre const dès que l’on peut.

Bien sûr, vous pensez sans doute qu’on peut être plus malin et en essayant de prévoir si la variable sera mutable dès sa déclaration, mais je peux garantir que vous ne serez pas 100% fiables et vous laisserez passer des opportunités de rendre des données immuables (du moins, tant que vous n’aurez pas pris cette bonne habitude).

Voici donc mon conseil : jusqu’à ce que vous ayez le réflexe de mettre des const partout où vous les pouvez, utilisez const systématiquement et pour toutes les variables. Au pire vous aurez quelques erreurs de compilation facile à corriger, au mieux vous attraperez une bonne habitude.

Et quid de constexpr ?

constexpr est un mot-clé qui permet d’indiquer qu’une expression peut être évaluée au moment de la compilation. Le but est d’essayer de gagner du temps d’exécution en faisant un plus gros travail à la compilation.

En un sens, c’est une immutabilité plus forte que const. Tout ce que j’ai dit dans cet article peut s’appliquer à constexpr : utilisez-le dès que c’est possible.

Cependant, contrairement à const, je ne vous conseille pas d’être spécialement trop zélé(e)s avec constexpr.
Il est plus rare de pouvoir l’utiliser et les cas d’utilisation sont un peu plus évidents que son homologue. Mais gardez bien en tête d’utiliser constexpr dès que possible.

Merci de votre attention et à la semaine prochaine !

Article original : Should every variable be const by default? | Belay the C++ (belaycpp.com)
Traductrice : Chloé Lourseyre

Article original : Exceptions are just fancy gotos | Belay the C++ (belaycpp.com)
Traductrice : Chloé Lourseyre

À propos de goto

Retour aux bases : pourquoi est-ce que les goto sont mauvais ?

Pour répondre à cette question, il me suffirait de vous jeter un lien vers l’article de E. Dikjstra, Go To Statement Considered Harmful (arizona.edu), qui explique plutôt bien pourquoi les goto sont l’incarnation du mal, mais j’ai envie d’aller un peu plus loin.

Je vais donner ici une liste de raison pour lesquelles il ne faut pas utiliser goto, résumant ainsi l’article susmentionné tout en y apportant une touche de modernisation :

1. Les goto sont des structures de contrôle non structurées, contrairement aux autres structures de contrôle en C ++. Les if et les boucles sont géographiquement liées au bloc de code qu’ils contrôlent (avec leur propre cycle de vie). Quand on les lit, on comprend aisément où le bloc de contrôle commence et où il finit. Les fonctions, qui sont une autre structure de contrôle, sont des points d’accès. Elles suivent un contrat dont le compilateur assure la validité. On leur donne une entrée, elles nous renvoient une sortie. Les goto, eux, ne sont pas structurés : ils correspondent à un aller simple dans le code, sans être géographiquement proche et sans assurer un système d’entrée-sortie comme les fonctions. Cela est sujet à produire du code spaghetti peu maintenable.
2. Considérant ce que cela implique, le goto est probablement le mot-clé le moins sécurisé du langage. Je ne donnerais pas d’exemple expansif dans cet article, mais le nombre de choses autorisées avec les goto est surprenamment élevé. Si vous n’êtes pas assez vigilant, vous pourrez provoquer des crashs, parfois aléatoires, du jardinage mémoire, des comportements indéfinis, etc.
3. Ici et maintenant, à l’ère du C ++ moderne, plus personne n’utilise les goto. Ça signifie que presque plus personne n’en est familier. La plupart des développeurs sait qu’il ne faut pas l’utiliser, mais assez peu d’entre eux savent pourquoi. De ce fait, si jamais d’aventure ils en croisent un dans une codebase, ils vont soit tenter de refactorer le code (avec le risque qu’ils comprennent la fonctionnalité de travers et causent une régression), soit le laisser en plan sans essayer de le comprendre. Étant donné qu’il est compliqué à utiliser, le fait que personne n’utilise le goto sur une base régulière est un argument de plus contre son utilisation.

Il existe des contextes spécifiques dans certains langages où le goto peut être considéré comme une bonne pratique, mais pas en C ++ moderne.

À propos des structures de contrôle et du code spaghetti

Dans la section précédente, le premier point (qui constitue l’argument principal contre le goto) parle de « structure de contrôle » et de « code spaghetti ».

De manière imagée, on pourrait voir l’exécution d’un programme comme une corde que l’on déroule le long du code, à mesure qu’il est exécuté. Tant que ce sont des instructions classiques qui sont exécutées, la corde se déroule normalement. Mais lorsqu’on atteint une structure de contrôle, cela se passe un peu différemment.

Quand l’exécution atteint une boucle for ou while, alors la corde effectue elle-même des boucles autour du bloc de code concerné. Quand l’exécution atteint une conditionnelle (if ou else), alors la corde passe au-dessus du code si nécessaire (en fonction de la condition vérifiée) pour continuer juste après.

Quand l’exécution atteint un appel de fonction, alors un brin de la corde se détache, forme un lacet qui va suivre le corps de la fonction puis revenir à la corde, là où elle l’a quitté.

Par contre, quand l’exécution atteint un goto, alors parfois la corde n’aura d’autre choix que d’être tendue à travers tout le code, pour atteindre le label associé. S’il y a plusieurs goto dans le code, alors la corde sera tendue à plusieurs endroits et dans tous les sens.

Si vous avez de bonnes structures de contrôle, alors vous pourrez suivre aisément votre corde du début à la fin, sans jamais être perdu. Mais si vos structures de contrôle sont chaotiques, alors la corde va se croiser partout et partir dans tous les sens. Elle ressemblera alors à un plat de spaghetti. C’est ça qu’on appelle avoir un code spaghetti.

Comme le goto a tendance à tendre la proverbiale corde à travers tout le code, son utilisation est facilement sujette à du code spaghetti.

Mais est-ce que le goto est vraiment malveillant ?

En prenant en compte tout ce que l’on vient de dire, ne pourrait-on pas quand même imaginer une manière sécurisée d’utiliser le goto ? Après tout, goto n’est malveillant que s’il provoque du code spaghetti. Mais si on réalise un code qui n’utilise le goto que localement, dans un espace contrôlé, alors le code ne sera pas spécialement spaghetti-esque, n’est-ce pas ?

Il existe effectivement des designs qui utilisent le goto pour rendre le code plus clair qu’il ne le serait avec d’autres structures de contrôle.

L’exemple le plus classique est celui des boucles imbriquées :Capture1.P

//...
 
bool should_break = false;
for (int i = 0 ; i < size_i ; ++i)
{
    for (int j = 0 ; j < size_j ; ++j)
    {
        if (condition_of_exit(i,j))
        {
            should_break = true;
            break;
        }
    }
    if (should_break)
        break;
}
 
//...

Si on écrit le même code avec un goto, ça sera un peu plus court et plus clair :Capture2.PNG888x314

// ...
 
for (int i = 0 ; i < size_i ; ++i)
{
    for (int j = 0 ; j < size_j ; ++j)
    {
        if (condition_of_exit(i,j))
            goto end_of_nested_loop;
    }
}
end_of_nested_loop:
 
// ...

Vous voyez ? goto n’est pas si inutile que ça !

Du coup, devrait-on utiliser ce mot-clé dans ces cas très spécifiques où il rend le code plus clair ? Je ne pense pas.

Il est au final assez compliqué de trouver des exemples variés où le goto est meilleur que les autres structures de contrôle, et les boucles imbriquées similaires à celle présentée ici sont rares. Et même si, dans cet exemple, le code est plus court, personnellement je ne le trouve pas plus clair pour autant. Il y a 2 niveaux de bloc de différence entre le goto et son label, ce qui à la lecture est contre-intuitif. De plus, dans tous les cas le facteur humain reste un gros problème.

Donc, est-ce que goto est vraiment malveillant ? Non, mais il reste, dans l’absolu, une très mauvaise pratique.

À propos des exceptions

Les exceptions : une manière moderne de casser les structures de contrôle

Les exceptions sont une manière de gérer les cas d’erreur. Elles peuvent aussi être utilisées comme une structure de contrôle standard, vu qu’on peut personnaliser ses propres exceptions, puis les lever et les attraper à loisir.

J’aime bien m’imaginer les exceptions comme étant des if qui pendouillent dans le code : d’une part si tout se passe bien, le code se déroule de manière linéaire, sans accroc, mais d’autre part, si une erreur survient, alors on lance la balle dans les airs en espérant que quelque chose dans les strates supérieures du programme la rattrape.

Les exceptions cassent les structurent de contrôle standard. Reprenons l’image de la corde déroulée le long du code : quand vous appelez une fonction qui peut lever une exception, alors un brin de corde se détache pour exécuter la fonction (comme avant), mais vous n’avez aucune garantie que le brin sera retourné à votre corde à l’endroit où vous avez appelé la fonction. Il pourra être raccordé n’importe où au-dessus, dans la pile d’appel. Le seul moyen d’empêcher ce scénario est de try–catch toutes les exceptions quand vous appelez la fonction, mais c’est un luxe qui n’est possible que si vous savez quoi faire dans tous les cas dégradés possibles.

De plus, quand vous écrivez une fonction dans laquelle vous levez possiblement une exception, vous n’avez aucun moyen de savoir si et où elle sera attrapée.

Même si ce n’est pas aussi mauvais que goto, parce qu’on a plus de contrôle dessus, il est très facile d’écrire du code spaghetti en usant d’exceptions. Avec ce recul, on peut même considérer que les exceptions sont « des goto modernes ».

On peut même écrire l’exemple des boucles imbriquées avec des exceptions :

//...
 
try
{
    for (int i = 0 ; i < size_i ; ++i)
    {
        for (int j = 0 ; j < size_j ; ++j)
        {
            if (condition_of_exit(i,j))
                throw;
        }
    }
}
catch (const std::exception& e)
{ /* nothing */ }
 
//...

Je ne recommanderais pas une telle écriture cependant. Les exceptions sont malfaisantes.

Est-ce que les exceptions sont vraiment malfaisantes ?

… le sont-elles ? Pas vraiment.

Dans la section précédente, j’ai statué sur le fait que les goto ne sont pas à proprement parler malveillantes mais qu’elles sont très sujettes aux fautes et aux erreurs. Elles n’en valent juste pas la peine. C’est pareil pour les exceptions : elles ne sont pas malfaisantes, c’est juste une feature.

En mon humble opinion, contrairement aux goto, il existe des moyens sécurisés d’utiliser les exceptions.

Une différence majeure entre les exceptions et les goto

Pour comprendre comment bien utiliser les exceptions, il faut comprendre les différences qu’elles ont avec le goto.Les exceptions, contrairement aux goto, n’envoient pas l’exécution à un endroit totalement indéterminé, elle envoie l’exécution vers le haut. Cela peut être de quelques blocs (comme dans l’exemple des boucles imbriquées) ou sur plusieurs appels de fonctions.

Quand utiliser les exceptions ?

Envoyer l’exécution du programme vers le haut reste assez indéterminé malgré tout, et dans la plupart des cas cela brise la continuité du programme.

Dans la plupart des cas.

Il existe une situation spécifique où vous voulez que l’exécution se stoppe abruptement : quand quelqu’un utilise une fonctionnalité d’une manière qui provoque un comportement indésirable.

Quand vous écrivez une fonctionnalité, vous voulez avoir la possibilité de tout stopper pour éviter un cas dégradé dangereux, et à la place de finir le traitement renvoyer l’exécution vers le haut en indiquant « Quelque chose d’imprévu s’est produit, je ne peux pas continuer ». Non seulement cela va prévenir les comportements indésirables, mais cela va aussi indiquer à l’utilisateur qu’il n’a pas correctement utilisé la fonctionnalité, le forçant à se corriger ou à gérer le cas d’erreur.

Quand vous rédigez une fonctionnalité, il y a un mur virtuel entre vous et l’utilisateur, avec un petit trou symbolisé par l’interface de la fonctionnalité. C’est à chacun d’entre vous de gérer correctement le comportement de la corde proverbiale de chaque côté du mur.

Une fonctionnalité peut d’ailleurs très bien être une grosse librairie ou une simple classe. Du moment qu’il y a un niveau d’encapsulation, il est valide d’utiliser des exceptions comme faisant partie de l’interface.

Un bon exemple de cela est la méthode at () de std ::vector < >. Le but de cette méthode est de renvoyer le énième élément du vecteur, mais il y a un risque que l’utilisateur demande un élément hors-limite. Dans ce cas, lever une exception est le moyen qu’a std ::vector < > d’empêcher un comportement indéfini. Si l’utilisateur capture l’exception, alors il peut écrire le code à exécuter en cas d’indice hors-limite. Sinon, le programme sera stoppé, lui indiquant qu’il a commis une erreur et le forcera à sécuriser son code ou à gérer le cas dégradé.

Dans tous les cas, vous devez documenter toute exception que vous levez.

Conclusion

En résumé, les bonnes pratiques à employer vis-à-vis des exceptions peuvent se résumer en trois points :

• N’utilisez pas les exceptions comme des structures de contrôle.
• Vous pouvez utiliser les exceptions comme partie de l’interface d’une fonctionnalité.
• Vous devez documenter toute exception que vous levez.

Merci de votre attention et à la semaine prochaine !

Article original : Exceptions are just fancy gotos | Belay the C++ (belaycpp.com)
Traductrice : Chloé Lourseyre

Article original : Dealing with integer overflows | Belay the C++ (belaycpp.com)
Traductrice : Chloé Lourseyre

Le dépassement d’entier (integer overflow dans la langue de Ritchie) peuvent être considérablement embêtants. Il n’y a pas de manière simple et fiable de les détecter, encore moins de les détecter statiquement, et ils peuvent rendre votre logiciel inconsistant.

Cet article parlera indistinctement du dépassement des entiers signés et non-signés. Même si le dépassement des entiers non-signés n’est pas un comportement indéfini (contrairement au dépassement des entiers signés), 99.9% du temps vous ne voulez ni l’un, ni l’autre.

Comment détecter les dépassements d’entier ?

Même si elle sont peu nombreuses, il existe effectivement des manières de détecter les dépassements d’entier. Le souci est qu’elles sont soit complexes, soit peu fiables.

Dans cette section, je vais vous présenter quelques manières de détecter les dépassements d’entier (si vous en connaissez d’autres, n’hésitez pas à le partager en commentaire pour que tout le monde puisse en profiter)

UBSan

Undefined Behavior Sanitizer, ou UBSan pour les intimes, est un outil dynamique de vérification des comportements indéfinis.

Il est capable de détecter les dépassements d’entier sous la forme d’une option de compilation. Notez que même s’il est conçu pour détecter les comportements indéfinis, il nous fait le plaisir de détecter également les dépassements de entiers non-signés (qui, pour rappel, ne sont pas indéfinis).

Voici, à titre d’exemple, lesdites options de compilations appliquée au compilateur clang :

clang++ -fsanitize=signed-integer-overflow -fsanitize=unsigned-integer-overflow

Cet outil est implémenté pour clang et GCC :

• UndefinedBehaviorSanitizer — Clang 13 documentation (llvm.org)
• GCC Undefined Behavior Sanitizer – ubsan | Red Hat Developer

Je peux me tromper, mais je n’ai pas réussi à trouver d’intégration de cet outil sur d’autres compilateurs.

Le principal inconvénient d’un outil dynamique comme celui-ci est qu’il faut re-compiler et lancer des essais exhaustifs du logiciel pour que l’outil puisse détecter un éventuel problème. Si les essais ne couvrent pas assez de cas de figure, il est possible qu’un dépassement d’entier passe entre les mailles du filet.

Écrire des test unitaires adéquats

Si votre projet implémente des tests unitaires (je ne m’étendrais pas sur le fait qu’il le devrait, car les développeurs ne sont pas toujours décisionnaires sur ce sujet), alors vous avez à votre disposition une manière assez directe de prévenir les dépassements d’entier.

Il vous suffit, pour toute fonctionnalité où c’est pertinent, de fournir en entrée de cette fonctionnalité de très grands entiers. Vous n’avez plus qu’à vérifier que le résultat reste cohérent, qu’une exception est levée, qu’un code d’erreur est mis à jour, ou quoique ce soit que la fonctionnalité est sensée faire dans ce cas.

Si vous ne savez pas quel résultat la fonctionnalité est sensée renvoyer parce que l’entrée est trop grosse pour être traitée et qu’elle ne gère pas ces cas d’erreur, alors cette fonctionnalité est dangereuse. Vous devez implémenter les cas d’erreur pour vous assurer qu’aucun dépassement n’aura lieu.

Parfois, détecter un dépassement d’entier potentiel peut nécessiter un refactoring assez lourd. N’ayez pas peur de le faire : il vaut mieux prévenir que guérir.

Ne mettez pas votre code dans une situation où il pourrait faire un dépassement

Le meilleur moyen d’être sûr qu’il n’y aura pas de dépassement et de prévenir toute possibilité qu’il survienne. Si vous être certain que votre code ne peux pas provoquer de dépassement d’entier, vous n’aurez pas besoin de les détecter.

La section suivante va vous fournir quelques pratiques pour vous aider dans cette optique.

Comment prévenir le dépassement d’entier ?

Utilisez des entiers de 64 bits

Une très bonne manière d’éviter le dépassement est d’utiliser int64_t pour implémenter les entiers. Dans la plupart des cas, les entiers de 64 bits ne provoqueront pas de dépassement, contrairement à leurs homologues de 32 bits et moins.

Veuillez noter que j’utilise des entiers signés comme exemple mais que toute cette section vaut aussi pour les entiers non-signés.

Il y a en réalité très peu de désavantages à utiliser int64_t plutôt que int32_t. La plupart du temps, vous n’aurez pas besoin de vous inquiéter de l’écart de performance ou de l’écart de taille entre les deux types. Seulement si vous travaillez sur des système embarqués ou sur des algorithmes de traitement de données pour pourriez avoir à vous en soucier.

Notez que avoir des entiers plus grands ne veut pas nécessairement dire que les calculs seront plus longs, et avec tout le panel de pointeurs / références / forwarding que le C++ nous fournit, on n’a pas souvent besoin de copier des grosses structure de données.

Dans tous les cas, même si vous avez des contraintes de performance ou de taille, gardez en tête la maxime suivante :

D’abbord la sécurité, ensuite les performances.
– Chloé Lourseyre, 2021

Essayer de suroptimiser et risquer ce faisant un dépassement d’entier est toujours pire que d’écrire du code sécurisé puis d’utiliser des outils pour cibler les morceaux de code qui doivent être optimisés.

Donc, ma recommandation finale est que, sauf contre-indication spécifique, vous utilisiez des int64_t (et des uint64_t) pour coder vos entiers.

À propos des performances de int64_t

J’ai fait tourner quelques opérations arithmétiques (addition, multiplication et division) sur un outil de benchmarking avec à la fois des int32_t et des int64_t pour voir s’il y avait des différences notables.

En utilisant clang et sur deux niveaux d’optimisation différents, voici les résultats :

Cela ne vous surprendra peut-être pas, mais dans tous les cas c’est la division la plus lente. Nonobstant les divisions, vous noterez qu’il n’y a pas de différence sensible entre les entiers 64-bits et les entiers 32-bits. Par contre, si vous effectuez des divisions, les entiers 32-bits seront plus adaptés (mais le simple fait d’utiliser des divisions démoli vos performance, donc c’est un gain en demi-teinte).

Petit rappel sur les types de base

Peut-être vous êtes vous demandé pourquoi, depuis le début de cette section, j’utilise les types int32_t et int64_t et non les bon vieux int et long. La raison à cela, c’est tout simplement parce que la taille de ces deux types dépend de votre environnement.

En effet, les seules contraintes que le standard applique sur les tailles des int et long sont les suivantes :

• Les int doivent faire au moins 16-bits.
• Les long doivent faire au moins 32-bits.
• La tailles des int doit être supérieure ou égale à la taille des short et inférieure ou égale à la taille des long.
• La taille des long doit être supérieure ou égale à la taille des int, bool et wchar_t et inférieure ou égale à la taille des long long.

À cause de cela, évitez autant que possible d’utiliser les int et les long quand vous voulez éviter les dépassements d’entier.

Ne présumez jamais que, parce qu’une valeur est dans les limites, elle ne provoquera pas de dépassement d’entier

Mettons que vous avez une variable int32_t my_val qui représente un donnée qui sera toujours contenue entre 0 et un milliard (1 000 000 000). Comme la valeur max d’un int32_t est 2^31-1 (2 147 483 647), on pourrait penser que la variable ne provoquera jamais de dépassement.

Mais, un jour fatidique, un développeur écrira, sans rien soupçonner :

#include <cstdlib>
 
const int32_t C_FOO_FACTOR = 3;
 
int32_t evaluate_foo(int32_t my_val)
{
    // foo is always C_FOO_FACTOR times my_val
    return my_val * C_FOO_FACTOR;
}

Vous l’avez vu ? Dépassement d’entier. En effet, il existe des valeur de my_val qui, quand elles sont multipliées par 3, causent un dépassement d’entier.

À qui la faute ? Doit-on toujours vérifier qu’une valeur est dans un intervalle adéquat avant toute opération arithmétique ? Comment faire ?

Et bien, il y a une pratique assez simple à réaliser qui vous aidera à prévenir la plupart des cas de figure concernés. Quand vous aurez à stocker un entier plutôt grand, même si en lui-même il ne peut pas dépasser, mettez-le dans une structure plus grande.

Par exemple, je ne met jamais une valeur qui peut être plus grande que 2^15 dans une donnée dont la valeur maximale est de 2^31. Ainsi, même si la valeur est multipliée avec elle-même, elle ne provoquera pas de dépassement d’entier.

Avec cette méthode, on peut garder les petites valeurs dans de plus petites structures de donnée sans effet de bord. Dans l’exemple mentionné, C_FOO_FACTOR pourra rester un int32_t, et le résultat de toute opération avec lui sera promu s’il est associé avec un type de plus grande taille dans une opération arithmétique.

E.g. :

#include <cstdlib>
 
const int32_t C_FOO_FACTOR = 3;
 
int64_t evaluate_foo(int64_t my_val)
{
    // foo is always C_FOO_FACTOR times my_val
    return my_val * C_FOO_FACTOR; // The result of the multiplication is a int64_t
}

Utilisez auto

Oui, auto peut parfois vous sauver la vie, en particulier si vous n’êtes pas 100% sûr des type que vous manipulez.

Par exemple :

#include <cstdlib>
 
int32_t  C_FOO = 42;
 
int64_t compute_bar();
 
int main()
{
    // Big risk of overflow overflow here
    int32_t foo_bar = compute_bar() + C_FOO;
 
    // Probably no overflow here
    auto better_foo_bar = compute_bar() + C_FOO;
}

Ici, auto est utile car il prévient l’erreur commise ligne 10, où le résultat de l’opération compute_bar() + C_FOO, qui est un int64_t, est rétrogradée en int32_t quand elle est assignée. Ligne 13, auto devient un int64_t, donc aucun dépassement ne peut avoir lieu.

(Note : convertir un entier en un type trop petit pour le contenir est un dépassement d’entier)

Il y a aussi un autre cas spécifique, qui ne survient pas spécialement souvent, où auto peut être utile. Considerez le code suivant :

#include <cstdlib>
 
int32_t  C_FOO = 42;
 
int32_t compute_bar();
 
int main()
{
    // Big risk of overflow overflow here
    auto foo_bar = compute_bar() + C_FOO;
}

Ici, la valeur de retour de compute_bar() est int32_t. Mais si plus tard, l’auteur de cette fonction, voyant que int32_t est trop petit, change le type de retour en un int64_t, comme ceci :

#include <cstdlib>
 
int32_t  C_FOO = 42;
 
int64_t compute_bar();
 
int main()
{
    // Big risk of overflow overflow here
    auto foo_bar = compute_bar() + C_FOO;
}

Alors l’auto sera automatiquement « promu » en int64_t lui aussi, évitant une conversion implicite qui pourrait résulter en un dépassement d’entier.

Si on avait utilisé int32_t à la place de auto dès le départ, alors il y aurait eu un risque que l’auteur de la fonction compute_bar() ne corrige pas le type de la variable foo_bar, sans qu’aucun avertissement ni aucune erreur ne survienne à la compilation. Du coup, avoir auto dans ce cas nous a fait éviter le pire.

En conclusion

Faites toujours attention, quand vous manipulez des grands entiers, d’utiliser des grands type (bien plus grand que nécessaire, par sécurité). Utilisez auto quand vous ne savez pas ce que vous manipulez, et utilisez des analyseurs si vous pensez que votre code peut contenir un dépassement d’entier. Et bien sûr, comme toujours, écrivez de bons tests unitaires.

Si vous connaissez d’autres manières de prévenir ou de détecter des dépassement d’entier, n’héistez pas à le partager en commentaire.

Merci de votre attention et à la semaine prochaine !

Article original : Dealing with integer overflows | Belay the C++ (belaycpp.com)
Traductrice : Chloé Lourseyre