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 dieexperimental::filesystem
Funktionen, die in C++17 Spezifikation. Und natürlich muss man wissen, dass alle Ihre gezielte Plattformen unterstützenexperimental::filesystem
oder C++17std::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 vonfilesystem
,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 alsstd::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. 🙂
Du musst angemeldet sein, um einen Kommentar abzugeben.
Nein, experimentellen Funktionen sind optional.
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).
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:Michael Wong (Vorsitz der SG5 und SG14 und Herausgeber der Parallelität TS) beantwortete die Frage zunächst:
Alisdair Meredith (ehemaliger Vorsitzender des LWG -), dann folgten:
Stephan T. Lavavej (maintainer von Microsoft STL-Implementierung) war zuletzt zu reagieren:
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 instd::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
."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.
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?
experimental::
oder so hart wie zwingen workarounds.experimental
einer ausfällt oder desappears.