Les fonctionnalités expérimentales du C ++ moderne sont-elles fiables pour les projets à long terme?

Question

J'ai un projet qui utilise actuellement le C++11/14, mais il faut quelque chose comme std::filesystem, qui est seulement disponible en C++17, et donc je n'ai pas de chance en ce moment à l'utiliser. Je vois, cependant, qu'il est disponible dans mon compilateur std::experimental::filesystem. Est-ce une bonne idée d'utiliser les fonctionnalités expérimentales, en supposant que je pourrais ajouter quelque chose comme:

#ifdef CXX17 //if this is C++17
std::filesystem::something ...;
#else
std::experimental::filesystem::something ...;
#endif

Mes préoccupations sont les suivantes:

1. Est-il garanti que tous conformes à la norme compilateurs ont les mêmes fonctions expérimentales?

2. Sont expérimentales caractéristiques sujettes à de grands changements qui les rendent peu fiables?

Peut-être il n'y a plus de choses à s'interroger sur. Pourquoi devrais-je ou ne dois-je pas les utiliser? Je suis perplexe avec un nouveau projet et ne sais pas quoi décider.

Answer 1

1. Est-il garanti que tous conformes à la norme compilateurs ont les mêmes fonctions expérimentales?

Non, les fonctionnalités expérimentales sont en option.

2. Sont expérimentales caractéristiques sujettes à de grands changements qui les rendent peu fiables?

Oui, le C++ comité pourrait même décider de renoncer à une fonction ou dans le processus de standardisation d'un défaut peut venir ce serait forcer une fonction pour changer.

En général, ce n'est pas une bonne idée de dépendre sur les fonctionnalités expérimentales. Les fonctionnalités expérimentales sont exactement ce que la parole dit (c'est à dire, à expérimenter).

Answer 2

Quelqu'un de l'auditoire a demandé une question lors de la "C++ de la Bibliothèque Standard du Panneau de" parler à CppCon 2016 (YouTube) sur le potentiel pour le nom experimental pour effrayer les utilisateurs à l'écart de l'utilisation de tout objet dans l'espace de noms:

Les gars, vous ne considérer [le contenu de l' std::experimental de l'espace de noms] la production de prêt et est-ce un argument qui peut être fait, [que] c'est en effet la production de prêts pour les 3 prochaines années, et peut-être que vous devez modifier votre code 3 ans plus tard, peut-être?

Michael Wong (président de SG5 et SG14 et rédacteur en chef de la Simultanéité TS) a répondu à la question première:

Je pense qu'il y a un très fort consensus au sein du comité, il est pratiquement prêt pour la production. Comme je l'ai dit avant, dans la plupart des cas de 99%, il pénètre à l'air abandonné. Nous voulons nous assurer que ce n'est pas un obstacle pour vous de l'utiliser. Vous pouvez comprendre pourquoi nous voulons mettre les grandes fonctionnalités, de grands groupes de fonctions, dans un tel contexte, afin de ne pas déranger le reste de l'ensemble du système de la bibliothèque, mais il rend également plus facile pour vous de l'utiliser. Maintenant, vous pouvez activer la GCC avec un drapeau spécifique pour les Concepts, vous le savez, qui le rend effectivement plus facile pour vous de segment.

Alisdair Meredith (ancien président confiées au groupe de travail) puis suivi:

Je vais prendre une position contraire ici. L'une des choses Herbe [Sutter] dit comme organisateur de WG21, la norme du groupe, lorsque nous partons sur le chemin de l'Est, c'est qu'il ne pense pas que les Est avons réussi jusqu'à ce que nous n'avons pas réussi à apporter quelque chose, parce que cela signifie que nous ne sommes pas d'être assez expérimental, nous ne sommes pas d'être assez ambitieux en ce qu'on utilise le les Est pour. Nous voulons vraiment que experimental à être une allusion au fait que, oui, ces choses sont susceptibles de changer, nous ne sommes pas de liaison, et on peut se tromper. C'est à la baisse de notre barrière pour les choses que nous considérons être de l'ambition et de la portée que nous pouvons [...] Maintenant, la norme semble être sur trois ans de la libération du cycle, nous devrions être beaucoup plus ambitieux en mettre vraiment les fonctionnalités expérimentales dans le TS, et peut-être faire avancer les choses plus rapidement dans la norme elle-même. Mais encore une fois, ce sera un sujet amusant pour nous d'en discuter lors de la prochaine quelques [C++ standard comité] réunions.

Stephan T. Lavavej (responsable de Microsoft STL mise en œuvre) a été le dernier à répondre:

Il est important d'établir une distinction entre les experimentalness de l'interface et la experimentalness de la mise en œuvre, parce que quand vous dites "prêt pour la production", ça veut dire quoi? Généralement, la "production ready", vous pensez que parler de la mise en œuvre. C'est tout à fait possible pour une mise en œuvre [de quelque chose en std::experimental] pour être absolument [...] l'épreuve des balles. [...] Quelque chose comme [...] l' <random> - tête dans TR1, [c'était] vraiment, vraiment sympa dans TR1, et vous pourriez avoir eu absolument à l'épreuve des balles de mise en œuvre de cette, mais il s'est avéré que l'interface de concocter considérablement [avant la sortie de] C++11 et [...] si l'on savait à l'époque ce que nous faisons maintenant, de mettre dans un experimental aurait été un meilleur signal pour les gens qui, "Hey, peut-être que vous ne voulez pas utiliser std::experimental::variate_generator parce que, ha-ha, il va disparaître en C++11".

Il semble donc qu'il y a une certaine volonté parmi la bibliothèque standard, les développeurs et les membres du comité que, dans l'avenir, au moins, le contenu de l' std::experimental espace de noms doit être vraiment "expérimental" dans la nature, et il ne doit pas être pris pour acquis que quelque chose en std::experimental fera dans la norme C++.

Et non, comme je le comprends, c'est à la bibliothèque standard vendeurs pour savoir si elles fournissent des implémentations pour les différentes fonctions au sein d' std::experimental.

Answer 3

"Expérimentale" est un peu exagérée terme. L' filesystem bibliothèque originaire de Boost et est allé par le biais de quelques itérations, avant d'être soumis à l'ISO.

Cependant, les normes ISO sont volontairement très conservateur. Appelant les moyens d'expérimentation ISO explicitement ne promet pas que le nom sera stable; il est évident que vous aurez besoin de re-adresse votre code un certain temps dans l'avenir. Mais la connaissance de l'ISO, il est probable qu'il y aura des conseils comment.

Comme pour la compatibilité entre les compilateurs, s'attendre à être raisonnable. Mais il y aura des cas de coin (pensez lecteur Windows chemins relatifs par exemple), et c'est exactement pourquoi une nouvelle norme qui pourraient casser votre code existant. Idéalement, il serait en mesure de vous briser le code si et seulement si vous dépendait que le cas de coin, mais ce n'est pas une garantie.

Answer 4

Peut-être il n'y a plus de choses à s'interroger sur.

Quelques points à considérer:

• Comment multiplateforme est votre projet? Si il y a un seul compilateur, vous pouvez inspecter sa mise en œuvre et la feuille de route pour décider. Ou leur demander!

• Quelle est la taille de votre base de code? Combien grande serait l'impact de changements?

• Comment fondamentale de votre projet sont les caractéristiques fournies par l'API/bibliothèque/fonction?

• Quelles sont les alternatives?

  • Utiliser la fonctionnalité expérimentale, puis adapter le code aux modifications si/si elle devient standardisé. Peut être aussi facile que de supprimer experimental::, ou aussi dur que de forcer des solutions de contournement.
  • Ajouter une couche d'abstraction (Serge Ballesta commentaire). Si la fonctionnalité expérimentale des changements de votre ré-écrit sont isolés. Pour une fonction standard, il serait peut-être exagéré (std::le système de fichiers est déjà une couche d'abstraction...).
  • Utiliser une autre API/bibliothèque. Mêmes questions: la maturité? la robustesse? la stabilité? la portabilité? la facilité d'utilisation? fonctionnalités?
• Dans le cas de std::le système de fichiers (ou de la mise en réseau TS), il est boost::filesystem (resp. boost::asio) comme une alternative ou de secours, dans le cas où l' experimental d'échec ou desappears.