La fonction de conversion pour la vérification des erreurs est considérée comme bonne ?

Question

J'aimerais avoir un moyen simple de vérifier la validité d'un objet. J'ai pensé à une simple fonction de conversion, quelque chose comme ceci :

operator bool() const { return is_valid; }

La vérification de sa validité serait très simple maintenant.

// is my object invalid?
if (!my_object) std::cerr << "my_object isn't valid" << std::endl;

Est-ce que cela est considéré comme une bonne pratique ?

Answer 1

En C++03, vous devez utiliser la fonction idiome bool sûr pour éviter les mauvaises choses :

int x = my_object; // this works

En C++11, vous pouvez utiliser une conversion explicite :

explicit operator bool() const
{
    // verify if valid
    return is_valid;
}

De cette façon, vous devez être explicite quant à la conversion en bool, de sorte que vous ne pouvez plus faire des choses folles par accident (en C++, vous pouvez toujours faire des choses folles exprès) :

int x = my_object; // does not compile because there's no explicit conversion
bool y = bool(my_object); // an explicit conversion does the trick

Cela fonctionne toujours normalement dans des endroits comme if y while qui nécessitent une expression booléenne, car la condition de ces déclarations est converti en contexte en bool :

// this uses the explicit conversion "implicitly"
if (my_object)
{
    ...
}

Ceci est documenté dans §4 [conv] :

Une expression e peut être implicitement converti à un type T si et seulement si la déclaration T t=e; est bien formé, pour une variable temporaire inventée t (§8.5). Certaines constructions du langage exigent qu'une expression soit convertie en une valeur booléenne. Une expression expression e apparaissant dans un tel contexte est dit être converti contextuellement en bool et est bien formée si et seulement si la déclaration bool t(e); est bien formé, pour une certaine variable temporaire inventée t (§8.5). L'effet de l'une ou l'autre conversion implicite est le même que d'effectuer la déclaration et l'initialisation, puis d'utiliser la variable temporaire comme résultat de la conversion.

(Ce qui fait la différence, c'est l'utilisation de bool t(e); au lieu de bool t = e; .)

Les endroits où cette conversion contextuelle en bool se produit sont les suivants :

• les conditions de if , while et for déclarations ;
• les opérateurs de négation logique ! , conjonction logique && et la disjonction logique || ;
• l'opérateur conditionnel ?: ;
• l'état de static_assert ;
• l'expression constante facultative de la noexcept spécificateur d'exception ;

Answer 2

Non un simple opérateur de conversion bool est no car vous pouvez maintenant faire de mauvaises comparaisons entre des types non apparentés . En général, oui, une fonction de conversion est acceptable. Utilisez simplement le bon ( idiome safe-bool ). Je ne peux pas l'expliquer mieux que les liens donnés.

Answer 3

La question initiale était

Est-ce que cela est considéré comme une bonne pratique ?

Le problème de la conversion sûre des bools était très pertinent dans la pratique, mais il a heureusement été résolu par les normes.

Mais le jugement si cette approche est appropriée, est un la question de la conception.

En introduisant un tel "contrôle de validité", vous déclarez effectivement que vos objets peuvent être dans un état invalide. Autrement dit, en termes d'informatique, vous ajoutez une nouvelle valeur distincte au domaine de valeurs représenté par vos objets. Une valeur appelée valeur inférieure

L'exemple le plus frappant d'un domaine de valeur avec cette propriété est le pointeur. Un pointeur peut faire référence à divers emplacements de mémoire, mais il peut également être NULL (invalide).

Nous devons donc nous demander si une telle valeur inférieure reflète réellement la nature des choses que nous voulons modéliser avec nos classes y -- avons-nous vraiment besoin de couvrir cet aspect de la nature dans notre modèle ?

L'expérience montre que les valeurs inférieures ont tendance à être sujettes aux erreurs, faciles à oublier et généralement plus un handicap qu'un atout. Si vous êtes capable d'organiser votre code de manière à ce que vos objets ne puissent pas être invalides, votre code devient plus simple, plus facile à lire, à comprendre et à maintenir