wake-up-neo.net

Sind die experimentellen Eigenschaften von modernem C ++ für Langzeitprojekte zuverlässig?

Ich habe ein Projekt, das derzeit C++ 11/14 verwendet, aber es erfordert etwas wie std::filesystem, Das nur in C++ 17 verfügbar ist, und daher habe ich derzeit keine Chance, es zu verwenden. Ich sehe jedoch, dass es in meinem aktuellen Compiler als std::experimental::filesystem Verfügbar ist. Ist es eine gute Idee, experimentelle Funktionen zu verwenden, vorausgesetzt, ich könnte in Zukunft Folgendes hinzufügen:

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

Meine Anliegen sind:

1. Wird garantiert, dass alle kompatiblen Compiler die gleichen experimentellen Funktionen haben?

2. Sind experimentelle Features anfällig für große Änderungen, die sie unzuverlässig machen?

Vielleicht gibt es noch mehr Dinge, über die man sich wundern kann. Warum soll ich sie benutzen oder nicht? Ich bin mit einem neuen Projekt verwirrt und weiß nicht, was ich entscheiden soll.

82
  1. Ist garantiert, dass alle kompatiblen Compiler die gleichen experimentellen Funktionen haben?

Nein, experimentelle Funktionen sind optional.

  1. Sind experimentelle Features anfällig für große Änderungen, die sie unzuverlässig machen?

Ja, das C++ - Komitee könnte sogar beschließen, ein Feature aufzugeben, oder im Zuge der Standardisierung könnte ein Defekt auftreten, der ein Feature zum Ändern zwingt.

Im Allgemeinen ist es keine gute Idee, sich auf experimentelle Funktionen zu verlassen. Experimentelle Merkmale sind genau das, was das Wort sagt (d. H. Zum Experimentieren).

79
101010

Jemand aus dem Publikum stellte während des Vortrags "C++ Standard Library Panel" auf der CppCon 2016 ( YouTube ) eine Frage zu dem Potenzial des Namens experimental, Benutzer davon abzuhalten, irgendetwas innerhalb der zu verwenden Namespace:

Halten Sie [den Inhalt des std::experimental - Namespace] für produktionsbereit und ist dies ein Argument, das für die nächsten 3 Jahre [das] produktionsbereit ist und möglicherweise müssen Sie Ihren Code ändern? 3 Jahre später vielleicht?

Michael Wong (Vorsitzender von SG5 und SG14 und Herausgeber des Concurrency TS) stellte zunächst die Frage:

Ich denke, es besteht ein starker Konsens innerhalb des Komitees, dass es praktisch produktionsbereit ist. Wie ich bereits sagte, werden in den meisten Fällen 99% davon in die Luft abgegeben. Wir möchten sicherstellen, dass die Verwendung für Sie kein Hindernis darstellt. Sie können verstehen, warum wir große Features, große Gruppen von Features, in einen solchen Kontext stellen möchten, damit der Rest des gesamten Bibliothekssystems nicht gestört wird, es aber auch für Sie einfacher wird, es zu verwenden. Jetzt können Sie GCC mit einem bestimmten Flag für Concepts aktivieren, damit Sie es einfacher segmentieren können.

Alisdair Meredith (ehemaliger Vorsitzender der LWG) folgte dann:

Ich werde hier die gegenteilige Position einnehmen. Eines der Dinge, die Herb [Sutter] als Versammler von WG21, der Standardgruppe, sagte, als wir uns auf den Weg zu TSes machten, war, dass er nicht glaubte, dass TSes erfolgreich waren, bis wir etwas nicht vorgebracht hatten, weil es fehlschlug Das heißt, wir sind nicht experimentierfreudig genug, und wir sind nicht ehrgeizig genug, wofür wir die TS verwenden. Wir möchten wirklich, dass experimental ein Hinweis darauf ist, dass sich diese Dinge ändern können, dass wir nicht daran gebunden sind und dass wir etwas falsch machen können. Dies soll unsere Barriere für die Dinge senken, die wir als so ehrgeizig und umfassend betrachten, wie wir können. [...] Jetzt, da der Standard einen dreijährigen Veröffentlichungszyklus zu haben scheint, sollten wir viel ehrgeiziger sein, wenn wir wirklich experimentelle Funktionen bereitstellen in den TS, und vielleicht Dinge schneller in den Hauptstandard selbst voranzutreiben. Aber auch dies wird ein unterhaltsames Thema für uns sein, das wir auf den nächsten Treffen des [C++ Standard Committee] diskutieren werden.

Stephan T. Lavavej (Betreuer der STL-Implementierung von Microsoft) antwortete zuletzt:

Es ist wichtig, zwischen der Experimentierfreudigkeit der Schnittstelle und der Experimentierfreudigkeit der Implementierung zu unterscheiden, denn was bedeutet es, wenn Sie "produktionsbereit" sagen? Normalerweise würde man "produktionsbereit" denken, wenn man von der Implementierung spricht. Es ist durchaus möglich, dass eine Implementierung [von etwas in std::experimental] Absolut [...] kugelsicher ist. [...] Etwas wie [...] der <random> - Header in TR1, [es war] wirklich, wirklich nett in TR1, und Sie hätten eine absolut kugelsichere Implementierung davon haben können, aber es Es stellte sich heraus, dass sich die Benutzeroberfläche [vor der Veröffentlichung] von C++ 11 erheblich verändert hatte und [...] wenn wir damals wüssten, was wir jetzt tun, wäre die Eingabe von experimental ein besseres Signal für die Menschen gewesen "Hey, vielleicht möchten Sie nicht std::experimental::variate_generator verwenden, weil es in C++ 11 verschwinden wird.".

Es scheint also unter den Standard-Bibliotheksentwicklern und Komiteemitgliedern ein gewisser Wunsch zu bestehen, dass der Inhalt des Namespaces std::experimental In Zukunft wirklich "experimenteller" Natur sein sollte und nicht übernommen werden sollte Selbstverständlich schafft es etwas in std::experimental in den C++ - Standard.

Und nein, soweit ich weiß, liegt es an den Anbietern von Standardbibliotheken, ob sie Implementierungen für die verschiedenen Funktionen in std::experimental Bereitstellen.

50
Joseph Thomson

"Experimentell" ist ein etwas übertriebener Begriff. Die Bibliothek filesystem hat ihren Ursprung in Boost und durchlief dort einige Iterationen, bevor sie an ISO übergeben wurde.

ISO-Standards sind jedoch absichtlich sehr konservativ. Wenn man es experimentell nennt, verspricht ISO ausdrücklich nicht, dass die Benennung stabil sein wird. Es ist völlig klar, dass Sie Ihren Code irgendwann in Zukunft neu adressieren müssen. Wenn Sie ISO kennen, wird es wahrscheinlich Anleitungen geben, wie.

Erwarten Sie, dass die Kompatibilität zwischen Compilern angemessen ist. Aber es wird Eckfälle geben (denken Sie beispielsweise an Windows-Laufwerkspfade), und genau deshalb könnte ein zukünftiger Standard Ihren vorhandenen Code beschädigen. Im Idealfall wird der Code nur dann beschädigt, wenn Sie sich auf diesen Eckfall verlassen, aber das ist keine Garantie.

28
MSalters

Vielleicht gibt es noch mehr Dinge, über die man sich wundern muss.

Ein paar Punkte zu beachten:

  • Wie plattformübergreifend ist Ihr Projekt? Wenn nur ein Compiler beteiligt ist, können Sie dessen Implementierung überprüfen und nachverfolgen, um zu entscheiden. Oder frag sie!

  • Wie groß ist deine Codebasis? Wie groß wären die Auswirkungen von Änderungen?

  • Wie grundlegend für Ihr Projekt sind die Funktionen, die von der API/Bibliothek/Funktion bereitgestellt werden?

  • Was sind die Alternativen?

    • Verwenden Sie die experimentelle Funktion und passen Sie den Code dann an Änderungen an, wenn er standardisiert wird. Könnte so einfach sein wie das Löschen von experimental:: oder so schwer wie Workarounds erzwingen.
    • Fügen Sie eine Abstraktionsebene hinzu (Kommentar von Serge Ballesta). Wenn sich die experimentelle Funktion ändert, werden Ihre erneuten Schreibvorgänge isoliert. Bei einem Standardfeature kann es zu einem Overkill kommen (std :: filesystem ist bereits eine Abstraktionsebene ...).
    • Verwenden Sie eine andere API/Bibliothek. Gleiche Fragen: Reife? Robustheit? Stabilität? Portabilität? Benutzerfreundlichkeit? Eigenschaften?
  • Im Falle von std :: filesystem (oder dem Netzwerk-TS) gibt es boost :: filesystem (bzw. boost :: asio) als Alternative oder Fallback, falls das experimental ausfällt oder verschwindet.
8
Pablo H