Gibt es einen "Haken" bei FastFormat?

Question

Ich habe gerade über den FastFormat C++ E/A-Formatierungsbibliothek und es scheint zu schön, um wahr zu sein: Schneller als printf, typsicher und mit einer, wie ich finde, ansprechenden Schnittstelle:

// prints: "This formats the remaining arguments based on their order - in this case we put 1 before zero, followed by 1 again"
fastformat::fmt(std::cout, "This formats the remaining arguments based on their order - in this case we put {1} before {0}, followed by {1} again", "zero", 1);

// prints: "This writes each argument in the order, so first zero followed by 1"
fastformat::write(std::cout, "This writes each argument in the order, so first ", "zero", " followed by ", 1);

Das sieht fast zu schön aus, um wahr zu sein. Gibt es einen Haken? Haben Sie gute, schlechte oder gleichgültige Erfahrungen damit gemacht?

Answer 1

Gibt es einen "Haken" bei FastFormat?

Als ich das letzte Mal nachgesehen habe, gab es einen ärgerlichen Haken:

Sie können nur verwenden entweder die schmale String-Version o die breite String-Version dieser Bibliothek. (Die Funktionen für wchar_t y char sind identisch - welcher Typ verwendet wird, ist eine Umschaltung zur Kompilierzeit).

Mit iostreams, stdio oder Boost.Format können Sie beides verwenden.

Answer 2

Ich habe einen "Haken" gefunden, der allerdings für die meisten Menschen niemals manifestieren. Auf der Projektseite:

Atomare Operation. Er schreibt die Anweisungselemente nicht einzeln aus, wie die IOStreams, hat also keine Probleme mit der Atomizität.

Die einzige Möglichkeit, wie ich mir das vorstellen kann, ist, dass der gesamte Prozess gepuffert wird. write() Aufrufs selbst und schreibt sie dann in den ostream in einem Schritt. Das bedeutet, dass Speicher zugewiesen werden muss, und wenn ein Objekt, das an die write() Aufruf eine große Menge an Ausgabe erzeugt (mehrere Megabyte oder mehr), kann er bis zu doppelt so viel Speicher in den internen Puffern verbrauchen (vorausgesetzt, er verwendet den Trick "grow-a-buffer-by-doubling-it-size-each-time").

Wenn Sie es nur für die Protokollierung verwenden und nicht, sagen wir, große Mengen an XML dumpen, werden Sie dieses Problem nie sehen.

Der einzige andere "Haken", den ich sehe, ist:

Äußerst tragbar. Es funktioniert mit allen guten modernen C++-Compilern; es funktioniert sogar mit Visual C++ 6!

Es wird also nicht mit einem alten C++-Compiler funktionieren, wie cfront in der Erwägung, dass iostreams ist rückwärtskompatibel bis in die späten 80er Jahre. Auch hier wäre ich überrascht, wenn jemand jemals ein Problem damit gehabt hätte.

Answer 3

Obwohl FastFormat eine gute Bibliothek ist, gibt es eine Reihe von Problemen mit ihr:

• Eingeschränkte Formatierungsunterstützung, insbesondere werden die folgenden Funktionen nicht unterstützt:
  • Führende Nullen (oder andere Auffüllungen ohne Leerzeichen)
  • Oktal/Hexadezimal-Kodierung
  • Angabe der Laufzeitbreite/-ausrichtung
• Die Bibliothek ist ziemlich groß für eine relativ kleine Aufgabe der Formatierung und hat sogar noch größere Abhängigkeiten (STLSoft).

Answer 4

Das sieht in der Tat sehr interessant aus! Trotzdem ein guter Tipp, und +1 dafür!

Ich habe ein bisschen damit herumgespielt. Der größte Nachteil, den ich sehe, ist, dass FastFormat weniger Formatierungsoptionen für die Ausgabe unterstützt. Dies ist meiner Meinung nach eine direkte Folge der Art und Weise, wie die höhere Schriftsicherheit erreicht wird, und ein guter Kompromiss je nach Ihren Umständen.

Answer 5

Wenn Sie sich seine Leistungsvergleichsseite genauer ansehen, werden Sie feststellen, dass das gute alte C printf -Familienfunktionen sind unter Linux immer noch erfolgreich. Tatsächlich ist der einzige Testfall, in dem sie schlecht abschneiden, der Testfall, der statische String-Verkettungen sein sollte, bei dem ich erwarten würde printf verschwenderisch zu sein. Außerdem bietet der GCC statische Typüberprüfung für printf -Funktionsaufrufe, so dass der Nutzen der Typsicherheit geringer ist. Also: もし Sie arbeiten unter Linux und もし Sie die absolut beste Leistung benötigen, ist FastFormat wahrscheinlich nicht die optimale Lösung.