Si nullptr_t n'est pas un mot clé, pourquoi sont char16_t et char32_t?

Question

Comme indiqué à la page Pourquoi, nullptr_t n'est pas un mot clé , il est préférable d'éviter d'introduire de nouveaux mots clés car ils risquent de compromettre la compatibilité ascendante.

Pourquoi alors char16_t et char32_t mots clés, alors qu’ils auraient tout aussi bien pu être définis ainsi?

 namespace std {
    typedef decltype(u'q') char16_t;
    typedef decltype(U'q') char32_t;
}
 

Answer 1

La proposition elle-même s'en explique: pour permettre la surcharge avec le sous-jacent types d' uint_least16_t et uint_least32_t. Si ils ont été typedefed cela ne serait pas possible.

Définir char16_t distincte nouveau type, qui a la même taille et de la représentation en uint_least16_t. De même, définir char32_t distincte nouveau type, qui a la même taille et de la représentation en uint_least32_t.

[N1040 définis char16_t et char32_t comme typedefs d' uint_least16_t et uint_least32_t, qui font de la surcharge sur ces caractères impossible.]

Quant à savoir pourquoi ils ne sont pas dans l' std d'espace de noms, c'est pour la compatibilité avec le C d'origine de la proposition. C++ interdit la C définitions d'apparaître dans sa propre version d' <cuchar>

[c.chaînes] / 3

Les en-têtes ne sont pas définir les types d' char16_t, char32_t, et wchar_t (2.11).

Les types ensuite besoin d'être global typedefs, qui porte son propre ensemble de problèmes tels que

typedef decltype(u'q') char16_t;

namespace foo {
  typedef int char16_t;
}

La raison pour std::nullptr_t de ne pas être un mot-clé peut être trouvé dans la question que vous avez lié

Nous ne nous attendons pas à voir beaucoup de l'utilisation directe d' nullptr_t dans de véritables programmes.

rendant nullptr_t le véritable exception à la règle.

Answer 2

A cause d'un code méchant comme celui-ci:

 typedef uint16_t char16_t;

extern char * strndup16to8 (const char16_t* s, size_t n);
extern size_t strnlen16to8 (const char16_t* s, size_t n);
 

Bien sûr, l’ existence de compilateurs prenant en charge C ++ 11 n’exclut pas l’existence de bibliothèques C ++ 03, ni la pléthore de systèmes ou d’utilisateurs qui utilisent des compilateurs / bibliothèques C ++ 03.

Si vous avez de la chance, ils feront ceci:

 #if __STDC_VERSION__ < 201112L && __cplusplus < 201103L
   typedef uint16_t char16_t;
#endif