Caractéristiques finales du C 17

Ces dernières semaines, le Comité C s'est réuni à Oulu, où les caractéristiques finales du C 17 ont été déterminées et il est sur le point de devenir un standard international. Après la dernière réunion à Jacksonville, je n’avais pas de grands espoirs que le C 17 apporterait de grandes surprises, mais la réunion d’Oulu a travaillé dur pour ajouter des informations importantes et intéressantes aux nouvelles caractéristiques du C 17. La page Reddit fournit un bon aperçu des fonctionnalités du C 17, et Herb Sutter a également donné un bon aperçu des fonctionnalités du C 17 dans un récent site CppCast (et son rapport de voyage). De plus, Michael Wong nous donne un aperçu plus complet des fonctionnalités du C17.

Laissez-moi d'abord parler des choses importantes

Comme je l'ai déjà dit, la réunion à Jacksonville Après la réunion , de nombreuses caractéristiques du C 17 étaient déjà très claires. J'ai écrit une série de blogs en trois parties donnant des conseils sur l'opportunité de passer au C++17. Nous entrons dans un nouveau siècle du C et, parallèlement à de puissantes spécifications techniques, sont publiées des normes connexes qui feront partie de la prochaine génération de normes C. Cela signifie que les fonctionnalités non C17 (par exemple, les concepts ou les modules) seront disponibles sous forme de plugins dans les prochaines versions du compilateur. Visual Studio fournit actuellement des modules, mais GCC est le premier compilateur à prendre en charge le concept. Clang prend également en charge les modules, et Visual Studio et Clang implémenteront bientôt les spécifications basées sur TS des modules. 3bb3ba5d8a8c1e677360c9d603cb067b Le standard C n'ajoutera pas de nouveau contenu, mais apportera plus ou moins de modifications. Mais j'espère toujours que toutes ces fonctionnalités seront retenues lors de la révision finale.

Le point culminant ultime de C 17

std::variante

Commençons par ce qui m'a le plus surpris : les variations. Oui, sérieusement, C 17 a apporté std::variant. C'est génial et ouvre la voie à de futures fonctionnalités basées sur des variantes et d'autres idées connexes. Par exemple, la correspondance de style, on en parle très bien en C à ce sujet. Selon David Sankel, std::variant est conçu après boost::variant et/ou d'autres bibliothèques de variantes. Possède une API très similaire à boost::variant

C'est formidable de voir cette fonctionnalité incluse dans la norme C 17 au lieu d'adopter le détour TS.

if constexpr(expression)

variant<int, float> v, w;
v = 12;int i = get<int>(v);
w = get<int>(v);
w = get<0>(v); // same effect as the previous linew = v; // same effect as the previous lineget<double>(v); // ill formedget<3>(v); // ill formedtry {
  get<float>(w); // will throw.}catch (bad_variant_access&) {}

Il s'agit de la version C de static if (presque). Pour moi, c'était l'un des points forts de Jacksonville, et à l'époque, cela ne le rendait pas si populaire. À la hauteur des attentes, il a passé avec succès l’examen final du C 17 par Oulu. Avec lui, C peut facilement compiler certains blocs d'instructions si, lors de la compilation, un constexpr est évalué à true :

Cet exemple explicitement Comme indiqué, constexpr doit être jugé vrai lors de la compilation, mais cela n'a aucun effet sur static_assert. Les static_asserts non sélectionnés dans le bloc d'instructions se déclencheront toujours. Ceci est inapproprié pour la norme.

if constexpr (std::is_integer ...) 
{ //integerstuff }
else if constexpr (std::is_floating_point ...) 
{ //floatingpointstuff }
else { // NaN ;) }

Autre chose intéressante : cette fonctionnalité s'écrit comme if constexpr, mais l'orthographe standard la nomme toujours constexpr if, mais la définit comme if constexpr.

Utiliser auto dans les modèles

Pour C 14, les expressions anonymes peuvent utiliser auto pour définir des paramètres génériques. Actuellement, auto peut également être utilisé pour définir des paramètres de modèle (non-type). Cela facilite l'écriture du code du modèle car auto est plus court que class ou typename. Vous pouvez également utiliser auto pour définir des paramètres de modèle de longueur variable, par exemple : template6b4b5c6a4dca2aea2d2f974ee580bfa1.

Reliure structurée

Jusqu'à présent, une astuce célèbre est encore utilisée, qui consiste à utiliser std librement : :tie pour attribuer directement un tuple ou une paire de variables distinctes sans avoir à gérer manuellement le type de résultat. C'est une astuce, et la variable doit exister. Vous pouvez maintenant déclarer la variable et l'initialiser sur une seule ligne :

Les crochets ne doivent pas manquer, et getvalues ​​​​renvoie un tuple. Il n'y a aucune mention de std::pair dans la recommandation, il n'est donc pas clair si l'utilisation de pair fonctionnera également correctement, elle est renvoyée par STL dans certaines méthodes d'insertion.

auto [a , b , c] = getvalues();

if et switch avec initialisation

Maintenant, les variables peuvent être définies dans l'instruction if : if(int x = 42; true != false), qui peut être combinée avec les suggestions précédentes. Les variables définies dans une instruction if sont également valides dans sa partie else. Je me souviens que la conception C moderne suggérait une astuce comme des accolades pour y parvenir, mais ce n'était que pour une seule variable.

Il est intéressant d'utiliser ce cas, comme le verrouillage d'un if ou d'un switch, tous les codes d'état renvoyés par ces fonctions peuvent désormais être gérés à l'intérieur du if. Essentiellement, cela équivaut à écrire { var x = value; if(...){}else{}} .

Plus

Ce n'est pas tout, par exemple, pour l'amélioration de l'ellision de copie, l'espace de noms de std[0-9] est réservé aux futurs standards. Il existe également de nombreuses discussions et opinions intéressantes sur Reddit.

La norme C 17 se développe et s'améliore progressivement, et des outils standardisés ont également mûri et ont été mis en service. C'est le plus gros gain pour C. Ceux qui souhaitent contribuer à la prochaine norme C voudront peut-être commencer à planifier dès maintenant. La normalisation du C a toujours été promue par des bénévoles. Il n'y a pas d'argent pour le faire, et tout le monde est essentiellement quelqu'un dont le travail quotidien est lié au C. Je vous suggère de consulter isocpp.org. Il contient une introduction très intéressante et détaillée. Il propose également diverses listes de diffusion et groupes de travail auxquels vous pouvez participer.

Ce qui précède est le contenu des fonctionnalités finales de C 17. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !