Ist es praktisch, STL in der C ++ - Entwicklung aufzugeben? [geschlossen]

Ich weiß, dass STL in einigen Bereichen (z. B. in der Spieleindustrie) nicht empfohlen wird. Meine Frage ist also: Ist es wirklich eine gute Praxis, STL in einigen Fällen nicht zu verwenden? Wenn ja, was sind die Hauptgründe dafür, die STL des modernen C ++ nicht zu verwenden?

• Ich kann mir nur einen gültigen Grund vorstellen und es ist wirklich selten: Harte Echtzeit. Viele Dinge in der Standardbibliothek weisen Speicher intern zu, und dies ist für harte Echtzeitanwendungen nicht deterministisch genug, sodass sie vermieden werden müssen. Diese Anwendungen sind normalerweise recht einfach, obwohl ihre Entwicklung aufgrund der sehr strengen Überprüfung und Prüfung unverhältnismäßig viel Zeit in Anspruch nimmt.

• Ich kann mir einen ungültigen, aber sehr häufigen Grund vorstellen: Entwickler, die die Komplexität der Berechnungen nicht verstehen, missbrauchen STL und geben dann der Bibliothek die Schuld.

  STL ist normalerweise zur Laufzeit schneller als C-Lösungen mit Callback-Zeigern oder polymorphismusbasierte Lösungen mit virtuellen Methoden ( siehe auch die Keynote von Bjarne Stroustrup ). Wenn der Entwickler jedoch die angegebenen Komplexitätsspezifikationen nicht versteht und die Bibliothek missbraucht, indem er so etwas wie einen Vektor von Vektoren einiger komplexer Objekte erstellt (in C ++ 11 ist dies jedoch kein Problem mehr!), Kann er ein Leistungsproblem verursachen und sich dann selbst verteidigen "Sie sehen, die Vektoren sind ziemlich langsam" kann die Wahrnehmung hervorrufen, dass die Standardbibliothek langsam ist. Und sobald Manager eine solche Wahrnehmung haben, kann sie sehr lange in der Organisation leben.

• Offensichtlich können Sie nichts verwenden, was die Plattform, auf die Sie abzielen, nicht unterstützt. Wir haben jedoch derzeit vier gängige mobile Plattformen im Visier (Android, iOS, Bada und altes WinCE) und verwenden die Standardbibliothek und einige Teile von Boost auf allen .

  Ein Großteil der Standardbibliothek wurde von Microsoft zu Beginn von WinCE nicht unterstützt (IIRC-iostreams wurden nur mit Visual Studio 2005 veröffentlicht), STLport konnte jedoch verwendet werden lange vorher zu verwenden. Und normalerweise kann man damit alles kompilieren. Deshalb würde ich diesen Grund auch als ungültig bezeichnen.

  Außerdem ist es lange nicht "STL", sondern ANSI C ++ Standard Library. Es wird durch dasselbe Standarddokument definiert, das die Sprache selbst definiert. Alles, was es nicht unterstützt, verdient es nicht, C ++ genannt zu werden.

Ich benutze STL und Boost schon seit vielen Jahren. Wenn ich es aufgeben und meine benutzerdefinierten Tools verwenden möchte, wäre die Motivation:

1. Reduzierung der Kompilierzeit (75%). Allein durch das Einbeziehen von iostreams kann Ihr Modul um 1 Million Codezeilen erweitert werden. Ja, vorkompilierte Header helfen viel, aber sie verlangsamen die Kompilierung in großen Projekten immer noch sehr. Auf lange Sicht verschwendet es viel Zeit, wenn jemand daran arbeitet.
2. Performance. (25%) STL ist so geschrieben, dass sie im Allgemeinen funktioniert. Sie können Ihre Strukturen jedoch so optimieren, dass sie genau so funktionieren, wie Sie es möchten. Beispielsweise könnten Sie Datenstrukturen mit Millionen von kurzen Zeichenfolgen haben. Die Verwendung einer benutzerdefinierten Zeichenfolgenklasse basierend auf dem Prinzip von boost :: small_vector (kleiner statischer lokaler Datenvektor, dynamische Zuweisung nur für größere Zeichenfolgen) ist möglicherweise viel schneller. Durch diese Art von Änderungen können wichtige Codeabschnitte um ein Vielfaches schneller ausgeführt werden.

Es gibt einen wichtigen Grund, die C ++ - Standardvorlagenbibliothek nicht zu verwenden: Eine Ihrer Zielplattformen verfügt nicht über eine vollständig konforme Implementierung (oder überhaupt keine Implementierung), und Sie wissen, dass es keine gibt innerhalb der nächsten Jahre.

Ich kenne die Komplexität (Effizienz der Implementierung) nicht, aber ich verwende häufig Qt-Container und -Strings anstelle der Standard-Container und sie funktionieren einwandfrei. Ich finde auch die Qt-Implementierung von Mengen und Listen einfacher zu bedienen.

Es kann daher praktisch sein, die STL zu verlassen, wenn Sie eine andere Bibliothek verwenden können, die Ihren Anforderungen entspricht.

Patrick hat den Grund genannt, warum nicht die gesamte STL verwendet werden soll, und zwar, dass Ihre Plattform (en) keine Plattform (en) haben.

Alles in allem denke ich, dass die Frage den Punkt verfehlt. Es ist meistens keine Alles-oder-Nichts-Entscheidung, sondern eine Wahl. Möglicherweise entscheiden Sie sich für die Container und Algorithmen, entscheiden sich jedoch für die Verwendung von etwas außerhalb der Standardbibliothek für Zeichenfolgen und E / A.

Es ist nicht praktikabel, es sei denn, es gibt einen schwerwiegenden Grund dafür. Einige dieser Gründe, die mir einfallen, sind die teilweise oder fehlende Implementierung von STL (oder eines anderen Teils der Standardbibliothek) oder eine Ressourcenbeschränkung (Speicher, CPU-Geschwindigkeit, Speicher, ...), die Sie umgehen müssen Rollen Sie Ihre eigenen Werkzeuge, die genau dem entsprechen, was Sie tun müssen.

In der Spielebranche haben die meisten (in gewissem Maße auch kleineren) Studios ihre internen Bibliotheken und Implementierungen vieler Standardbibliotheksteile, die in hohem Maße auf die Zielplattform und in einigen Fällen auf die Zielengine oder sogar das Spiel selbst zugeschnitten sind. Einfach ausgedrückt, wenn ein Spiel für Konsolen entwickelt wird, ist die Hardware nach heutigen Standards sehr begrenzt. Aus einem bestimmten Grund gibt es Tausende und Abertausende von handgefertigten Montagelinien. Es ist sehr wichtig, alle Arten von Ressourcen in Ihrem Code so gering wie möglich zu halten, damit das Spiel schneller läuft und mehr Inhalte in der Spielwelt (oder einer größeren Welt zum Beispiel) verfügbar sind, was hoffentlich zu einem besseren Produkt führt.

"Jedes erfolgreiche Spiel beginnt mit der Implementierung einer eigenen verknüpften Liste."