Sind die experimentellen features, die von modernen C++ zuverlässig für langfristige Projekte?

Ich habe ein Projekt, das derzeit verwendet C++11/14, aber es erfordert etwas wie std::filesystem, die es nur in C++17, und damit ich nicht die chance haben, derzeit verwenden. Ich sehe allerdings, dass es in meiner aktuellen compiler wie std::experimental::filesystem. Ist es eine gute Idee, um die Verwendung von experimentellen Funktionen, vorausgesetzt, ich könnte in der Zukunft hinzufügen, so etwas wie:

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

Meine Bedenken sind:

1. Ist es garantiert, dass alle konformen Compiler haben den gleichen experimentellen features?

2. Sind experimentelle features anfällig, um große Veränderungen zu machen, dass Sie unzuverlässig?

Vielleicht gibt es mehr Dinge zu Fragen. Warum sollte ich oder sollte ich nicht verwenden? Ich bin verwirrt mit einem neuen Projekt und wissen nicht, was Sie entscheiden.

  • nicht das Wort experimental Ihre Fragen beantworten?
  • Nicht wirklich. Es ist ein wenig mehrdeutig. Alle, die ich finden konnte ist, dass es "möglicherweise" Hinzugefügt werden in der Zukunft standard oder entfernt werden kann. Aber ich weiß, es ist Hinzugefügt. Die Frage ist also über den Unterschied.
  • Vor allem eine Frage des Geschmacks, aber ich möchte vermeiden, überladen Sie den code mit #idef CXX17. IMHO, ist die tragbare Weg ist, um alle filesystem-code in einer einzigen Zusammenstellung Gerät (kann eine Klasse sein), verwenden Sie es, während die übrigen Teile des Codes, code ist es mit dem aktuellen C++11/14 Standards. Dokumentieren, wie ein Grund, warum Sie schreiben es so, und schließlich ist die Portierung auf C++17 später während einer Erhaltungsphase, wenn es Sinn macht. (Kommentar auf die ursprüngliche Frage)
  • Es war nur "experimentell", als ein Kandidat zur Eingabe des standard. Es ist nicht ein Spiegelbild der Qualität des code.
  • Das ist genau der Grund, warum ich denke, es ist mehrdeutig (also 101010 Erklärung in den Kommentaren).
  • Ehrlich gesagt ist das, wie mache ich es jetzt 🙂 , aber ich bin versucht, um zu sehen, ob ich einfachere Optionen.
  • Es gab durchaus ein paar änderungen zwischen den "experimentellen" und der Letzte C++ - 17-version finden Sie unter Dokument P0492R1
  • Im Fall von filesystem verursachen Sie weit weniger Gefahr, es zu benutzen als andere Dinge, wie Sie bereits wissen, dass es wird standardisiert in C++17, und die genaue C++17 Spezifikation ist öffentlich verfügbar. So alle Sie tun müssen ist, stellen Sie sicher, dass Sie nur die experimental::filesystem Funktionen, die in C++17 Spezifikation. Und natürlich muss man wissen, dass alle Ihre gezielte Plattformen unterstützen experimental::filesystem oder C++17 std::filesystem.
  • müssen Sie Globale suchen-und-ersetzen - std::experimental::filesystem --> std::filesystem wenn es nicht standardisiert !
  • Eine Sache zu prüfen ist, dass, während die Antworten hier sind gut, die wichtigste Frage bei diesen Entscheidungen ist "was ist Ihre Entwicklungsumgebung wie?" Wenn Ihre Umgebung hat eine Gewohnheit des habens von anämischen wartungsbudgets, dass kaum halten, Essen auf den Tisch und bits auf der Festplatte, werden Sie wahrscheinlich nicht wollen, zu satteln Ihre Zukunft Entwickler mit experimentellen Sachen. Auf der anderen Seite, wenn Sie auf eine langfristige agilen Projekt, das ständig darum, neue Energie in das system, die Vorteile können die Kosten überwiegen.
  • Als weiteres Beispiel, wenn Sie mission-kritische Sachen wie der nuklearen Triebwerk-management, oder auch nur die ABS-Bremse-management-Systeme, werden Sie wahrscheinlich haben, einen Körper, welcher verantwortlich für die Segnung, die ein Bibliotheks-feature, das Sie verwenden. Dass EZB-Körper haben etwas zu sagen über einen flüchtigen namespace!
  • Moderator-Hinweis: ich habe entfernt die langwierige und oft sehr Konstruktive Diskussion über die Vorzüge von diesem post. Bitte nehmen Sie solche Diskussionen zu Meta-Stack Overflow oder Stack-Overflow-Chat das nächste mal. Dies ist nicht der Ort den Menschen zu sagen, wie Sie Ihre Stimmen oder zu sehen, der die Beweggründe für die anderen.
  • +1 @HowardHinnant ' s Kommentar oben. Wieder Lesen dass. Eine weitere alternative ist die Suche nach der Quelle des experimental Bibliothek -- im Fall von filesystem, optional usw., das ist Boost. Wenn Sie sind berechtigt, die Nutzung zu Steigern, konnte man eine halbwegs stabile, tragbare interface gibt es, die sollte in etwa so einfach, den port zu C++17 als std::experimental.
  • Ich bin damit einverstanden. Eigentlich bin ich mit boost derzeit mit einer abstrakten Schnittstelle, die ich gemacht habe, aber hatte gehofft, ich könnte verlassen sich auf die standard nur.
  • Bitte beachten Sie, dass (1) es gibt bugs im Boost.Dateisystem noch fixiert werden (z.B., diese eine, die ich gemeldet und wurde vor kurzem behoben) und (2) die C++17 Bande gedacht haben, dass noch härter um die Ecke-Fälle wie nicht-POSIX-Dateisystemen wie Windows, welches ist der wahrscheinlichste Ort für die änderungen (siehe MSalters Antwort unten).
  • Auf der positiven Seite, der Autor von Boost.Dateisystem ist auch die gleiche person, die hat führte std::filesystem obwohl der Normung. 🙂

InformationsquelleAutor The Quantum Physicist | 2017-04-10
  1. 79
    1. Ist es garantiert, dass alle konformen Compiler haben den gleichen experimentellen features?

    Nein, experimentellen Funktionen sind optional.

    1. Sind experimentelle features anfällig, um große Veränderungen zu machen, dass Sie unzuverlässig?

    Ja, das C++ - Komitee könnte sogar entscheiden, verlassen einer Funktion oder in der Prozess-Standardisierung in einem Mangel kommen könnte, die würde zwingen, ein feature zu ändern.

    Generell ist es keine gute Idee ist, hängt von experimentellen Funktionen. Experimentelle features sind genau das, was das Wort sagt (d.h., zu Experimentieren).

    • Bezogen auf den zweiten Punkt, bitte beachten Sie, dass ich Rede von features, die bereits angenommen, aber könnte anders sein.
    • angenommen" ist ein schwieriges Konzept. Alles kann jederzeit wieder entfernt werden, durch die später die Annahme einer änderung, um es zu entfernen, und das passiert jeden standard. Sie würde wahrscheinlich wollen, zu warten, bis zumindest der Entwurf einer Internationalen Norm, bevor das feature-set ist einigermaßen zuverlässig.
    • Ich sehe!
    • Nicht du meinst der Letzten Draft International Standard aka FDIS. ? Drafting ist eine ziemlich permanenter Prozess.
    • Nein, die DIS ist wohl gut genug, wenn man in Eile ist. Und wir verfügen nicht über eine FDIS dieser Zeit sowieso.
    • Ich glaube nicht, können Sie überspringen die FDIS Schritt. FDIS ist das Dokument, das die ISO-sendet zur Genehmigung an die Nationalen Stellen.
    • Ah OK, du mehr darüber wissen als ich 🙂
    • Ich ziemlich viel war, ist die Nationale Stelle für die Niederlande um C++03 ;). Wir hatten ein nationaler Sekretär für SC22, die wusste über ISO-Verfahren und wie in einer Antwort auf eine FDIS, aber nicht was. Andere als unsere WG14 delegieren Randy Marques) keiner unserer SC22 Delegierten wusste nichts über C++. Und Randy war einfach nur lustig machen über die Tatsache, dass C++ brauchen würde, weitere Seiten zu definieren, die alle UB als C benötigt für die Definierten Verhalten - würden nicht wollen, ihm zu Antworten, dass FDIS 😉
    • Eigentlich kann man überspringen FDIS wenn es keine "Nein" Stimmen auf die DIS (oder so ähnlich); C++14 übersprungen FDIS und C++17 ist die Planung auch zu tun.
    • Ich denke, das ist, warum wir hatten eine Sekretärin, um die Dinge richtig. ISO ist vielleicht etwas bürokratisch, aber es funktioniert.

    InformationsquelleAutor 101010
  2. 50

    Jemand aus dem Publikum eine Frage gestellt, die während der "C++ Standard-Bibliothek-Panel" Vortrag auf CppCon 2016 (YouTube) über das Potenzial für den Namen experimental Benutzer zu erschrecken Sie Weg von alles, was innerhalb des namespace:

    Jungs betrachten [die Inhalte der std::experimental namespace] die Produktion bereit und ist das ein argument, die gemacht werden können, [dass] es ist effektiv die Produktion bereit für die nächsten 3 Jahre, und haben Sie vielleicht den code ändern 3 Jahre später, vielleicht?

    Michael Wong (Vorsitz der SG5 und SG14 und Herausgeber der Parallelität TS) beantwortete die Frage zunächst:

    Ich denke, es gibt starke Konsens im Ausschuss, dass es praktisch die Produktion bereit. Wie ich schon sagte, in den meisten Fällen zu 99% wird es der Luft-fiel in. Wir wollen sicherstellen, dass es nicht ein Hindernis für Sie, es zu benutzen. Können Sie verstehen, warum wir wollen, große Funktionen, große Gruppen von Funktionen, die in einem solchen Kontext, so dass es nicht stört, den rest des gesamten Bibliothekssystems, aber es macht es auch einfacher für Sie, es zu benutzen. Nun kann man wiederum auf GCC mit einem bestimmten flag für Konzepte, Sie wissen, dass die eigentlich macht es einfacher für Sie, um das segment it out.

    Alisdair Meredith (ehemaliger Vorsitzender des LWG -), dann folgten:

    Werde ich das Gegenteil Stellung hier. Eines der Dinge, Kraut [Sutter] Sprach als Veranstalter von WG21, die standard-Gruppe, wenn wir uns dann auf den Weg der TSE ist, er glaube nicht, dass die TSE wird es geschafft haben, bis wir es versäumt haben, bringen etwas nach vorne, denn es bedeutet, dass wir nicht gerade experimentell genug, wir sind nicht ehrgeizig genug in dem, was wir über die TSE für. Wir wirklich wollen, dass experimental ein Hinweis, dass, ja, diese Dinge sind FREIBLEIBEND, wir sind nicht bindend, und wir können Dinge falsch. Dies ist auf die Reduzierung der Sperre für die Dinge, die wir betrachten werden, wie ehrgeizig und erreichen, wie können wir [...] Jetzt der standard zu sein scheint, auf einem drei-Jahres-release-Zyklus, wir sollten viel mehr Ehrgeiz bei der Umsetzung wirklich experimentellen features in den TS, und vielleicht schreitet die Dinge schneller in den Haupt-standard selbst. Aber noch einmal, das wird ein lustiges Thema für uns zu diskutieren, am nächsten [C++ standard committee] treffen.

    Stephan T. Lavavej (maintainer von Microsoft STL-Implementierung) war zuletzt zu reagieren:

    Es ist wichtig zu unterscheiden zwischen der experimentalness der Schnittstelle und die experimentalness der Umsetzung, denn wenn Sie sagen, "production ready", was bedeutet das? In der Regel, "production ready", würden Sie denken, dass das sprechen über die Umsetzung. Es ist durchaus möglich, für eine Umsetzung [von etwas in std::experimental] absolut [...] bulletproof. [...] So etwas wie [...] die <random> header in TR1, [es war] wirklich, wirklich schön in TR1, und Sie hätten ein absolut bullet-proof-Implementierung, aber es stellte sich heraus, dass die Schnittstelle aufgewühlt wesentlich [vor dem release] C++11-und [...] wenn wir damals gewußt, was wir jetzt tun, indem Sie eine experimental wäre ein besseres signal an die Menschen: "Hey, vielleicht haben Sie nicht verwenden möchten std::experimental::variate_generator da, ha-ha, es wird verschwinden in C++11".

    So es scheint, dass es einige Wunsch zu den standard-library-Entwickler und Mitglieder des Ausschusses, dass es in Zukunft zumindest den Inhalt der std::experimental namespace sollte wirklich "experimentell" in der Natur, und es sollte nicht für selbstverständlich genommen werden, dass etwas in std::experimental wird es in der C++ - standard.

    Und Nein, soweit ich das verstanden habe, ist es bis zu standard-Bibliothek-Anbieter, ob Sie bieten Implementierungen für die verschiedenen Funktionen innerhalb std::experimental.

    • 10 Jahre nach meinem ersten Lesen der Namen, die Tatsache, dass Microsoft ' s STL-Betreuer namens STL macht mich immer noch schmunzeln.
    • lernen Sie Ihre compiler-Betreuer Michael Sam Victor Collins
    InformationsquelleAutor Joseph Thomson
  3. 28

    "Experimentelle" ist ein etwas übertriebener Begriff. Die filesystem Bibliothek entstand im Boost und ging durch ein paar Iterationen gibt, bevor Sie eingereicht ISO.

    Jedoch, ISO-standards sind absichtlich sehr konservativ. Nennt es experimentell bedeutet ISO explizit nicht Versprechen, dass die Nennung stabil sein; es ist völlig klar, dass Sie benötigen, um re-Adresse, Ihren code irgendwann in der Zukunft. Aber zu wissen, ISO, es ist wahrscheinlich, dass es Anleitungen wie.

    Als für die Kompatibilität zwischen Compilern, erwarten, dass es vernünftig zu sein. Aber es gibt Ausnahmefälle (denke Windows-Laufwerk-relative Pfade für Beispiel), und das ist genau der Grund, warum ein zukünftiger standard könnte brechen Sie den vorhandenen code. Ideal wäre es, brechen Sie den code, wenn, und nur wenn Sie davon abhing, dass die Ecke Fall, aber das ist keine Garantie.

    InformationsquelleAutor MSalters
  4. 8

    Vielleicht gibt es mehr Dinge zu Fragen.

    Ein paar Punkte zu beachten:

    • Wie Multiplattform ist Ihr Projekt? Wenn es nur einen compiler beteiligt, dann Sie können prüfen, Ihre Umsetzung und Erfolgsbilanz zu entscheiden. Oder Fragen Sie Sie!

    • Wie groß ist die codebase? Wie groß wären die Auswirkungen der änderungen?

    • Wie grundlegend zu Ihrem Projekt sind die features der API/library/feature?

    • Was sind die alternativen?

      • Verwenden experimentelles feature, passen Sie das code-änderungen, wenn/falls es standardisierte wird. Vielleicht so einfach wie das löschen experimental:: oder so hart wie zwingen workarounds.
      • Hinzufügen eines abstraction layer (Serge Ballesta Kommentar). Wenn die experimentelle Funktion verpasst Ihr neu schreibt, sind isoliert. Für ein standard-feature, es wäre des guten zuviel (std::filesystem ist bereits eine Abstraktionsebene,...).
      • Verwendung einer anderen API/- Bibliothek. Gleiche Fragen: Reife? Robustheit? mit der Stabilität aus? Portabilität? Benutzerfreundlichkeit? features?
    • Im Fall von std::filesystem (oder die Vernetzung TS), es ist boost::filesystem (resp. boost::asio) als alternative oder fallback, falls die experimental einer ausfällt oder desappears.
    InformationsquelleAutor Pablo H
Schreibe einen Kommentar