Est-il préférable d'inclure <cassert> ou <assert.h>?

Question

En utilisant C++11, vaut-il mieux #include ou ? Ou il n'y a pas de différence?

Modifier:

Il semble Dois-je inclure or dans les programmes C++? soutient que cela revient à polluer l'espace de noms global. Est-ce un cas spécial car assert est un macro et il n'y a pas de std::assert?

Answer 1

Le contenu de est le même que l'en-tête de bibliothèque standard C , sauf qu'un macro nommé static_assert n'est pas défini.1

Préférez .

Toutes les en-têtes C (y compris ) sont obsolètes:

D.5 En-têtes de bibliothèque standard C [depr.c.headers]

Mise à jour concernant le macro static_assert de C

Dans D.5 [depr.c.headers], la norme C++ fait référence aux en-têtes comme "les en-têtes C:

1 Pour la compatibilité avec la bibliothèque standard C, la bibliothèque standard C++ fournit les en-têtes C indiqués dans le Tableau 141.

En C++14, la spécification faisait référence à C99 (ISO/CEI 9899:1999). C99 ne définissait pas le macro static_assert (dans aucun en-tête). C++14 disait ceci à propos de dans 19.3 [assertions]:

2 Le contenu est le même que l'en-tête de bibliothèque standard C .

C++17 fait référence à C11 (ISO/CEI 9899:2011) qui le fait définir static_assert dans , et dit ceci à propos de dans 22.3.1 [cassert.syn]:

1 Le contenu est le même que l'en-tête de bibliothèque standard C , sauf qu'un macro nommé static_assert n'est pas défini.

C++14 et C++17 définissent uniquement en référence à leurs spécifications C respectives, ainsi que par ceci:

Voir aussi: ISO C 7.2.

(qui est la section C qui spécifie )

La façon dont je comprends ceci, techniquement , lorsqu'il est compilé avec un compileur C++17, définit en fait un macro nommé static_assert. Cependant, le faire serait inutile, et je ne peux pas imaginer qu'une implémentation le fait réellement.

Quoi qu'il en soit, je maintiens ma recommandation ci-dessus:

Préférez .

C'est simplement la manière de faire en C++. Et au moins en C++98/03/11/14/17, cela évite de dépendre de fonctionnalités obsolètes. Qui sait ce que C++20 apportera. Mais C++20 ne dépréciera certainement pas .

---

1 22.3.1 Synopsis de l'en-tête [cassert.syn]

2 Lien vers la spécification C++11.

3 Lien vers la spécification C++17.

Answer 2

En regardant le code :

Utilisation de assert.h   // Compatible avec le standard du langage C
---------------
#include 

int main() {
    assert(true == true); // L'exécution continue
    assert(true == false); // L'exécution sera interrompue avec assert valeur false !
    return 0;
}

Utilisation de cassert    // Non compatible avec le standard du langage C
--------------
#include 

int main() {
    assert(true == true); // L'exécution continue
    assert(true == false); // L'exécution sera interrompue avec assert valeur false !
    return 0;
}

Les deux fonctionnent !

---

Lequel est meilleur en C++11 ?

En ce qui concerne la spécification de C++11 et C++17 :

C.5.1 (section du document C++17)
Modifications aux en-têtes [diff.mods.to.headers]

1. Pour la compatibilité avec la bibliothèque standard de C, la bibliothèque standard de C++ fournit les en-têtes C énumérés dans D.5, mais leur utilisation est dépréciée en C++.

2. Il n'y a pas d'en-têtes C++ pour les en-têtes C , , et , ni les en-têtes C eux-mêmes font partie de C++.

3. Les en-têtes C++ (D.4.1) et (D.4.4), ainsi que leurs en-têtes C correspondants et , ne contiennent pas de contenu de la bibliothèque standard C et incluent plutôt d'autres en-têtes de la bibliothèque standard C++.

---

D.5 En-têtes de la bibliothèque standard C [depr.c.headers] 1. Pour la compatibilité avec la bibliothèque standard C, la bibliothèque standard C++ fournit les en-têtes C indiqués dans la Table 141.

Les documents des spécifications standards de C++11 et C++17 indiquent que l'utilisation de reste pour la compatibilité avec la norme C, bien que leur utilisation soit considérée comme dépréciée.

---

En ce qui concerne la proposition de norme C++ 20

Ils envisagent de annuler la dépréciation de l'utilisation des en-têtes de la bibliothèque C en C++20. apparaissent surlignés en vert. La dépréciation de C++11 et C++17, pour l'instant, est qualifiée de "recommandation faible" et un "ajustement" pour maintenir les "en-têtes de la bibliothèque standard C (c.headers)" est affiché ci-dessous :

"Les en-têtes de la bibliothèque standard C de base sont une caractéristique de compatibilité essentielle et ne vont pas disparaître de sitôt." (provenant du document de révision de C++ 20)

---

D.5 En-têtes de la bibliothèque standard C
[depr.c.headers]

Recommandation faible : En plus de ce qui précède, également retirer les en-têtes C correspondant de la norme C++, tout comme nous n'avons pas les en-têtes correspondants , , ou . Comme ci-dessus, mais avec les ajustements suivants : 20.5.5.2.1 En-têtes de la bibliothèque standard C [c.headers]

Pour la compatibilité avec la bibliothèque standard C, la bibliothèque standard C++ fournit les en-têtes C indiqués dans la Table 141. Table 141 — En-têtes C

L'en-tête se comporte comme s'il incluait simplement l'en-tête . L'en-tête se comporte comme s'il incluait simplement les en-têtes et .

---

Bjarne Stroustrup recommande de maximiser l'interopérabilité entre les langages C et C++, en réduisant les incompatibilités autant que possible. D'autres argumentent différemment, car cela complique les choses.

Il semble donc que les ne vont pas disparaître. En fin de compte, vous pouvez utiliser les deux. Personnellement, je prendrais ma décision sur lequel utiliser en fonction de la compatibilité ascendante de votre code avec du code C ou non.