Gedanken zur modernen C ++ - und Spieleentwicklung

Das neue Jahr für Spieleentwickler begann mit einer Welle von Kritik, die nach der Veröffentlichung von Aras Prankevichus 'Beschwerden über modernes C ++ auf das C ++ - Standardisierungskomitee fiel. Es stellte sich eine ernste Frage: Hat das Standardkomitee wirklich den Kontakt zur Realität verloren oder ist es umgekehrt, und brechen diese Spieleentwickler vom Rest der C ++ - Community ab?

Wir bieten Ihnen eine Übersetzung des beliebten Postens von Ben Dean, einem Veteranen der Spielebranche , der lange Zeit als C ++ - Entwickler und Teamleiter bei Blizzard, Electronic Arts und Bullfrog gearbeitet hat und in dem er auf Kritik aus seiner eigenen Erfahrung reagiert.

TL; DR: Das C ++ Standardization Committee hat nicht das versteckte Ziel, die Bedürfnisse von Spieleentwicklern zu ignorieren, und "modernes" C ++ wird keine "debuggte" Sprache.

In der vergangenen Woche gab es auf Twitter eine aktive Diskussion , in der viele Programmierer - insbesondere diejenigen, die auf dem Gebiet der Spieleentwicklung arbeiten - darauf hinwiesen, dass der aktuelle Entwicklungsvektor von „modernem C ++“ nicht ihren Anforderungen entspricht . Insbesondere vom Standpunkt eines gewöhnlichen Spieleentwicklers sieht alles so aus, als würde die Debugging-Leistung in der Sprache ignoriert, und Codeoptimierung wird erwartet und notwendig.

Aufgrund der Tatsache, dass ich 2019 mehr als 23 Jahre in der Spielebranche gearbeitet habe, habe ich meine eigene Meinung, die auf Beobachtungen zu diesem Thema in Bezug auf die Spieleentwicklung basiert, die ich gerne teilen möchte. Ist das Debuggen für Spieleentwickler wichtig und warum? Was sind die damit verbundenen Probleme?

Zunächst einmal - ein kleiner Exkurs in die Geschichte.

Viele C ++ - Spieleentwickler arbeiten in Microsoft Visual C ++. In der Vergangenheit hat sich um Microsoft-Plattformen ein riesiger Markt für Spiele gebildet, der die typische Erfahrung eines normalen Spieleprogrammierers beeinträchtigt hat. In den 90er und 2000er Jahren wurden die meisten Spiele unter diesen Umständen geschrieben. Selbst mit dem Aufkommen von Konsolen anderer Hersteller und der wachsenden Beliebtheit von Handyspielen sind das Eigentum vieler AAA-Studios und zahlreicher Spieleprogrammierer heute Tools von Microsoft.

Visual Studio ist wohl der beste Debugger für C ++ der Welt. Darüber hinaus sticht Visual Studio beim Debuggen von Programmen am meisten hervor - mehr als beim Front-End, Back-End, der STL-Implementierung oder anderen Dingen. In den letzten fünf Jahren hat Microsoft erhebliche Fortschritte bei der Entwicklung von C ++ - Entwicklungstools erzielt, aber schon vorher war der Debugger in Visual Studio immer sehr cool. Wenn Sie also auf einem Windows-PC entwickeln, haben Sie immer einen erstklassigen Debugger zur Hand.

Schauen wir uns vor diesem Hintergrund den Prozess zum Abrufen von Code an, bei dem keine Fehler auftreten. Möglichkeiten, die wir aus der Sicht eines Programmierers haben, der sich nicht mit Spielen befasst; sowie die Einschränkungen, mit denen Spieleentwickler konfrontiert sind. Wenn Sie das Hauptargument zugunsten des "Entwicklungsvektors von modernem C ++" umformulieren, wird es auf Typen, Tools und Tests reduziert. Nach diesem Gedanken sollte der Debugger die letzte Verteidigungslinie sein . Bevor wir es erreichen, haben wir die folgenden Optionen.

Gelegenheit Nr. 1: Typen

Wir können so viel starke Typisierung wie nötig verwenden, um ganze Fehlerklassen beim Kompilieren zu beseitigen. Starkes Tippen ist ohne Zweifel eine Chance, die uns die jüngste Entwicklung von C ++ geboten hat. Ab C ++ 11 haben wir beispielsweise Folgendes erreicht:

• signifikante Erweiterung der type traits ;
• Innovationen wie nullptr und scoped enum zur Bekämpfung des C-Erbes - schwache Typisierung;
• GSL und Hilfswerkzeuge;
• Konzepte in C ++ 20.

Einige von Ihnen mögen möglicherweise keine Metaprogrammierung für Vorlagen. Andere mögen den Codierungsstil, der auto fast universell verwendet, möglicherweise nicht. Unabhängig von diesen Einstellungen wird hier das Hauptmotiv für die Verwendung der aufgelisteten Stile in C ++ klar nachgezeichnet - dies ist der Wunsch, dem Compiler zu helfen, damit er uns wiederum helfen kann, indem er gleichzeitig das verwendet, was er am besten weiß: das Typsystem.

Wenn wir über Spieleprogrammierung sprechen, ist das starke Tippen hier ein weites Forschungsfeld und wird von mir bekannten Spielprogrammierern aktiv genutzt, die daran interessiert sind, ihre Fähigkeiten im Umgang mit C ++ in der Praxis zu verbessern. Zwei wichtige Dinge sind hier von Belang: die Auswirkung auf die Kompilierungszeit und die Auswirkung auf die Lesbarkeit des Codes.

Ehrlich gesagt können Sie die Kompilierungszeit leicht ignorieren - aber nur unter der Bedingung, dass Sie Programmierer in einem sehr großen Unternehmen sind, das keine Spiele spielt und über eine etablierte interne Infrastruktur und endlose Rechenleistung verfügt, um jeden Code zu kompilieren, den Sie schreiben können . Solche großen Unternehmen sind besorgt über die Kosten für die Kompilierung - daher verwenden sie Module -, aber dies verursacht in der Regel keine Schmerzen für einzelne Entwickler. Gleichzeitig ist dies für die meisten Spielprogrammierer nicht der Fall. Indie-Entwickler müssen keine Farmen bauen. AAA-Spieleentwickler verwenden häufig so etwas wie Incredibuild . Angesichts der Tatsache, dass sie problemlos mit einer Codebasis arbeiten können, die 10 Jahre oder älter ist, kann der Erstellungsprozess dennoch 15 bis 20 Minuten dauern.

Wir können über die relativen Kosten für das Hinzufügen von Hardware im Vergleich zu den Kosten für die Zeit des Programmierers streiten, und ich stimme der Ansicht zu, dass Hardware jedoch billiger ist:

• Hardware ist eine echte einmalige Ausgabe, die dem Budget des laufenden Quartals zugewiesen wird, im Gegensatz zu nicht so greifbaren Ausgaben in Bezug auf Zeit / Einstellung / und dergleichen, die über einen längeren Zeitraum verteilt werden. Die Entscheidung für einen solchen Kompromiss kommt den Menschen nicht gut, und Unternehmen sind speziell so aufgebaut, dass sie den kurzfristigen Gewinn optimieren.
• Die Infrastruktur benötigt Unterstützung, und fast niemand steigt in die Spielebranche ein, um Release-Ingenieur zu werden. Im Vergleich zu anderen Bereichen, in denen C ++ verwendet wird, ist das Gehalt der Spieleentwickler nicht so hoch - und Nicht-Spieleingenieure werden hier noch weniger bezahlt.

Man kann auch darüber spekulieren, dass die Kompilierungszeit niemals einen solchen Zustand hätte erreichen dürfen; und wieder stimme ich dir zu. Der Preis hierfür ist ständige Wachsamkeit - wiederum von einem Release-Ingenieur - und im Idealfall ein automatisiertes Tool, mit dem Sie Änderungen in der für die Erstellung des Builds erforderlichen Zeit verfolgen können. Glücklicherweise kann dieses Ziel mit dem Aufkommen von CI-Systemen heute viel einfacher erreicht werden.

Gelegenheit Nr. 2: Werkzeuge

Wir sollten das Maximum der uns zur Verfügung stehenden Tools verwenden - Warnungen, statische Analysen, Desinfektionsmittel, Tools für dynamische Analysen, Profiler und andere.

Ich habe die Erfahrung gemacht, dass Spieleentwickler diese Tools verwenden, wo immer dies möglich ist, aber hier hat die gesamte Branche mehrere Probleme:

• Diese Tools funktionieren in der Regel besser auf Nicht-Microsoft- Plattformen - und wie bereits erwähnt, ist dies kein typisches Spielentwicklungsszenario.
• Die meisten dieser Tools sind auf die Arbeit mit "Standard" C ++ ausgerichtet. Sie unterstützen CStaticVector std::vector , aber nicht meine selbstgeschriebene Klasse CStaticVector aus einer hypothetischen Engine. Natürlich ist es nutzlos, die Tools zu beschuldigen, aber dies ist immer noch eines der Hindernisse für ihre Verwendung, die Entwickler überwinden müssen.
• Das Erstellen und Verwalten einer CI-Kette, in der alle diese Tools ausgeführt werden, erfordert die Anwesenheit von Release-Ingenieuren. Wie bereits erwähnt, ist die Einstellung von Mitarbeitern für Ingenieurjobs, die nicht direkt mit Spielen zusammenhängen, ein systemisches Problem für die Spielebranche.

Warum verwenden Spieleentwickler STL nicht, da diese Tools mit Standard-C ++ so gut funktionieren?

Wo soll die Antwort auf diese Frage beginnen? Vielleicht vom nächsten Ausflug in die Geschichte der Spieleentwicklung:

• Bis in die frühen 90er Jahre vertrauten wir C-Compilern nicht und schrieben Spiele in Assembler.
• Von Anfang bis Mitte der 90er Jahre vertrauten wir C-Compilern, aber wir vertrauten C ++ - Compilern immer noch nicht. Unser Code war C, der Kommentare im C ++ - Stil verwendete, und wir mussten nicht mehr ständig Typedefs für unsere Strukturen schreiben.
• Um das Jahr 2000 fand die C ++ - Revolution in der Welt der Spieleentwicklung statt. Es war eine Ära von Designmustern und großen Klassenhierarchien . Zu dieser Zeit ließ die STL-Unterstützung auf Konsolen zu wünschen übrig, und Konsolen beherrschten damals die Welt. Auf PS2 bleiben wir für immer bei GCC 2.95.
• Um 2010 wurden zwei weitere Revolutionen gestartet. Der Schmerz, große Klassenhierarchien zu verwenden, stimulierte die Entwicklung eines Komponentenansatzes für Code. Diese Änderung setzt ihre heutige Entwicklung in Form von Entity-Component-System-Architekturen fort. Hand in Hand damit war die zweite Revolution - ein Versuch, Multiprozessor-Architekturen zu nutzen.

Während dieser Paradigmenwechsel änderten sich die Spieleentwicklungsplattformen selbst ständig und sie änderten sich ernsthaft. Der segmentierte Speicher ist einem flachen Adressraum gewichen. Die Plattformen sind Multiprozessor geworden, symmetrisch und nicht sehr. Spieleentwickler, die an die Arbeit mit Intel-Architekturen gewöhnt waren, mussten sich an MIPS (Playstation) gewöhnen, dann an eine spezielle Hardware mit heterogenen CPUs (PS2), dann an PowerPC (XBox 360), dann an noch größere Heterogenität (PS3) ... Die neue Plattform verfügt über neue Leistungsmerkmale für Prozessoren, Speicher und Laufwerke. Wenn Sie eine optimale Leistung erzielen wollten, mussten Sie Ihren alten Code häufig und häufig neu schreiben. Ich werde nicht einmal erwähnen, wie sehr die Spiele durch die Entstehung und das Wachstum der Popularität des Internets sowie durch die Einschränkungen beeinflusst wurden, die Plattforminhaber den Entwicklern auferlegt haben.

In der Vergangenheit waren STL-Implementierungen auf Spieleplattformen unbefriedigend. Es ist kein Geheimnis, dass STL-Container für Spiele schlecht geeignet sind. Wenn Sie den Spieleentwickler an die Wand schieben, gibt er vielleicht zu, dass std::string ganz in Ordnung ist und std::vector eine vernünftige Standardoption ist. Alle in der STL enthaltenen Container haben jedoch ein Problem mit der Kontrolle der Zuordnung und Initialisierung. Viele Spiele müssen sich über Speicherbeschränkungen für verschiedene Aufgaben Gedanken machen - und für Objekte, für die der Speicher während des Spiels höchstwahrscheinlich dynamisch zugewiesen werden muss, werden häufig Platten- oder Arena- Allokatoren verwendet. Amortisierte konstante Zeit ist kein gutes Ergebnis, da die Zuweisung möglicherweise eines der „teuersten“ Dinge ist, die während der Programmausführung passieren können, und ich möchte keinen Frame überspringen, nur weil es passiert ist, als ich es nicht erwartet habe . Als Spieleentwickler muss ich meinen Speicherbedarf im Voraus verwalten.

Eine ähnliche Geschichte wird für andere Abhängigkeiten im Allgemeinen erhalten. Spieleentwickler möchten wissen, was jeder Prozessorzyklus benötigt, wo und wann und wofür jedes Byte Speicher verantwortlich ist und wo und wann jeder Ausführungsthread gesteuert wird. Bis vor kurzem haben Microsoft-Compiler ABI mit jedem Update geändert. Wenn Sie also viele Abhängigkeiten hatten, kann das Wiederherstellen aller Abhängigkeiten ein schmerzhafter Prozess sein. Spieleentwickler bevorzugen normalerweise kleine Abhängigkeiten, die einfach zu integrieren sind, nur eines tun und gut funktionieren - vorzugsweise mit einer API im C-Stil - und von vielen Unternehmen verwendet werden, gemeinfrei sind oder eine kostenlose Lizenz haben, die dies nicht tut erfordert eine Angabe des Autors. SQLite und zlib sind gute Beispiele dafür, was Spieleentwickler bevorzugen.

Darüber hinaus hat die C ++ - Spielebranche eine reiche Geschichte von Patienten mit dem Syndrom „Hier nicht erfunden“. Dies sollte von der Branche erwartet werden, die mit einzelnen Enthusiasten begann, die ihre eigenen Sachen mit völlig neuen Geräten herstellten und keine anderen Optionen hatten. Die Spielebranche ist unter anderem die einzige, in der Programmierer in keiner bestimmten Reihenfolge im Abspann angegeben sind. Das Schreiben einer Vielzahl von Dingen macht Spaß und hilft Ihrer Karriere! Es ist viel besser, etwas Eigenes zu bauen, als fertige zu kaufen! Und da wir uns so große Sorgen um die Leistung machen, können wir unsere Lösung so anpassen, dass sie speziell für unser Projekt geeignet ist - anstatt eine allgemeine Lösung zu wählen, die die verfügbaren Ressourcen sinnlos verschwendet. Die Feindseligkeit gegenüber Boost ist das Hauptbeispiel dafür, wie sich ein solches Denken in der Spieleentwicklung manifestiert. Ich habe an Projekten gearbeitet, die folgendermaßen abliefen:

• Um ein bestimmtes Problem zu lösen, verbinden wir zunächst eine Bibliothek von Boost mit dem Projekt.
• Alles funktioniert sehr gut. Wenn Sie ein Update durchführen müssen, treten einige Schmerzen auf, jedoch nicht mehr als beim Aktualisieren einer anderen Abhängigkeit.
• Ein anderes Spiel möchte unseren Code verwenden, aber der Stolperstein ist, dass wir Boost verwenden - trotz der Tatsache, dass unsere Erfahrung mit Boost ganz gut gelaufen ist.
• Wir entfernen den Code mit Boost, aber jetzt stehen wir vor einem neuen Problem: Wir müssen das Problem lösen, das die Bibliothek von Boost anstelle unserer zuvor gelöst hat.
• Wir kopieren im Wesentlichen die Teile des Boost-Codes, die wir benötigen, in unsere eigenen Namespaces.
• Später stoßen wir unweigerlich und immer wieder auf die Tatsache, dass wir zusätzliche Funktionen benötigen, die bereits im Originalcode enthalten wären, wenn wir sie nicht weggeworfen hätten. Aber jetzt sind wir die Eigentümer dieses Codes, also müssen wir ihn weiterhin unterstützen.

Wir mögen nichts Großes, das versucht, zu viele Dinge gleichzeitig zu tun, oder das die Kompilierungszeit beeinflussen kann - und das ist durchaus vernünftig. Was Menschen immer wieder Fehler machen, ist, dass sie es ablehnen, den vermeintlichen Schmerz heute zu akzeptieren - während sie aufgrund dieser Entscheidung mit der Unterstützung von etwas auf Kosten von jemandem einem sehr realen und viel größeren Schmerz gegenüberstehen werden - das Budget, das sie in den nächsten drei Jahren haben müssen. Leider kann das Vorhandensein von Beweisen in Form von Spielen, die ein Gericht von STL und Boost erfolgreich verwenden, die menschliche Psychologie in keiner Weise beeinflussen und Spieleentwickler überzeugen.

Aus all diesen Gründen haben viele Spielefirmen ihre eigenen Bibliotheken erstellt, die die Funktionen von STL - und noch mehr - abdecken und gleichzeitig spielspezifische Anwendungsfälle unterstützen. Einige große Spielefirmen konnten sogar die Entwicklung ihres eigenen, vollwertigen, fast vollständig API-kompatiblen STL-Ersatzes meistern, was in der Folge enorme Kosten für die Unterstützung dieses Projekts mit sich brachte.

Es ist ratsam, eine verbesserte Alternative zu std::map finden oder die Optimierung kleiner Puffer in std::vector anzuwenden. Es ist viel weniger akzeptabel, zum Scheitern verurteilt zu sein, um Ihre eigenen Implementierungen von algorithms oder Typmerkmalen zu unterstützen, was wenig nützt. Für mich ist es bedauerlich, dass STLs für die meisten Entwickler nur Container sind. Da ihnen beim Erlernen von STL zu Beginn genau das beigebracht wird, implizieren die meisten von STL std::vector - obwohl sie eigentlich über std::find_if nachdenken std::find_if .

Gelegenheit Nr. 3: Tests

Es wird argumentiert, dass umfangreiche Tests durchgeführt werden sollten, TDD und / oder BDD den gesamten Code abdecken sollten, der abgedeckt werden kann, und Fehler sollten durch Schreiben neuer Tests behoben werden.

Lassen Sie uns daher das Thema Testen diskutieren.

Nach meiner Erfahrung werden automatisierte Tests in der Spielebranche praktisch nicht eingesetzt. Warum?

1. Weil Korrektheit nicht so wichtig ist, aber es keine wirkliche Spezifikation gibt

Als junger Programmierer in der Spielebranche wurde ich schnell von der Idee befreit, dass ich mich bemühen sollte, etwas realistisch zu simulieren. Spiele sind Rauch und Spiegel und die Suche nach kurzen Wegen. Es interessiert niemanden, wie realistisch Ihre Simulation ist. Hauptsache, es macht Spaß. Wenn Sie keine andere Spezifikation als "Das Spiel sollte sich richtig anfühlen" haben, fehlt das Thema Test. Dank Bugs kann das Gameplay sogar noch besser werden. Sehr oft kommt ein Fehler in die Veröffentlichung und gewinnt sogar die Liebe der Benutzer ( erinnern Sie sich an denselben Gandhi aus Civilization ). Spiele unterscheiden sich von anderen Bereichen, die C ++ verwenden. hier führt ein Mangel an Korrektheit nicht dazu, dass jemand irgendwann seine Ersparnisse verliert.

2. Weil es schwer ist

Natürlich möchten Sie automatisierte Tests erstellen, wo immer Sie können. Dies kann für einige Subsysteme durchgeführt werden, für die eindeutig festgelegte Endergebnisse vorliegen. Unit-Tests in der Spielebranche sind natürlich vorhanden, aber in der Regel sind sie auf Low-Level-Code beschränkt - die zuvor erwähnten STL-Analoga, String-Konvertierungsverfahren, physikalische Engine-Methoden usw. Die Fälle, in denen der ausführbare Abschnitt des Codes vorhersehbare Ergebnisse aufweist, werden normalerweise durch Komponententests getestet, obwohl TDD hier nicht verwendet wird - da Spielprogrammierer es vorziehen, ihr Leben zu vereinfachen und nicht umgekehrt. Aber wie testest du den Gameplay-Code (siehe Punkt eins)? Sobald Sie über Unit-Tests hinausgehen, stoßen Sie sofort auf einen anderen Grund, warum das Testen von Spielen so schwierig ist.

3. Weil der Inhalt beteiligt ist

Das Testen nicht trivialer Systeme wird wahrscheinlich die Bereitstellung von Inhalten umfassen, mit denen es implementiert wird. Die meisten Ingenieure sind nicht sehr gut darin, diese Inhalte selbst zu erstellen. Um einen aussagekräftigen Test zu erhalten, müssen Sie jemanden mit den richtigen Fähigkeiten für die Erstellung der Inhalte gewinnen. Danach stoßen Sie auf das Problem, zu messen, was Sie auf der Ausgabe erhalten - schließlich handelt es sich nicht mehr um eine Linie oder eine Zahl, sondern um ein Bild auf dem Bildschirm oder einen Ton, der sich im Laufe der Zeit ändert.

4. Weil wir es nicht praktizieren

Unit Testing ist eine Funktion, für die ich die möglichen Ein- und Ausgänge kenne. Das Gameplay ist jedoch ein unvorhersehbares, sich dynamisch entwickelndes Verhalten, und ich weiß nicht, wie ein solches Phänomen richtig getestet werden könnte. Was kann ich testen - wenn ich natürlich von meinem Manager die Erlaubnis bekomme, genügend Zeit dafür aufzuwenden - dies sind zum Beispiel Leistung oder hochrangige Funktionen wie Matchmaking, die ich analysieren kann. Eine solche Infrastrukturarbeit mag für einige Spielprogrammierer aufregend sein, ist aber für die meisten einfach nicht interessant und erfordert außerdem die Genehmigung und Unterstützung des Besitzers der Brieftasche. Als Spielprogrammierer habe ich nie die Möglichkeit, das Schreiben von Tests auf hohem Niveau zu üben.

5. Da [Unternehmen] keine Notwendigkeit für automatisierte Tests sieht

Unser Hauptziel ist es, das Spiel zu veröffentlichen. Wir leben in einer Ära der Industrie, die mit Hits voranschreitet, die im ersten Verkaufsmonat das Beste aus ihrem Geld machen, wenn die Marketingkosten dieser Hits maximiert werden. Der Lebenszyklus von Konsolen hat uns gelehrt, dass der Code auf keinen Fall so lange leben wird. Wenn wir an einem Online-Spiel arbeiten, erhalten wir höchstwahrscheinlich zusätzliche Zeit zum Testen des Matchmaking oder der Serverlast. Da für die Veröffentlichung des Spiels die Leistung in Ordnung sein muss, sollten wir zumindest Leistungstests durchführen, diesen Prozess jedoch nicht automatisieren. Für das Management in der Spielebranche ist automatisiertes Testen nichts anderes als Zeit- und Geldverschwendung. Für die Implementierung müssen erfahrene Ingenieure eingestellt werden, die die Arbeiten ausführen, deren Ergebnis kaum wahrnehmbar ist. Die gleiche Zeit könnte für die Entwicklung neuer Funktionen aufgewendet werden. Kurzfristig ist es viel rentabler, QA-Mitarbeiter zum Testen des Spiels einzusetzen, was uns zum nächsten Punkt bringt.

6. Weil das Testen in Spielen im Allgemeinen als zweitklassige Aktivität eingestuft wird

Ich liebe gute QS-Profis. Für mich sind sie Gold wert. Sie wissen, wie Sie Ihr Spiel verbessern können, indem Sie es auf eine Weise brechen, die Ihnen nie in den Sinn gekommen wäre. Sie sind spezialisierte Experten in Ihrem Gameplay in dieser Hinsicht, die Sie nicht verstehen und kaum jemals verstehen. Sie sind besser als ein Team von hochqualifizierten Compilern, die Ihnen helfen, alles richtig zu machen. Ich bin froh, dass ich im Laufe der Jahre die Gelegenheit hatte, mit mehreren wunderbaren QS-Spezialisten zusammenzuarbeiten.

Ich musste fast immer kämpfen, um sicherzustellen, dass sie in meinem Team blieben.

AAA-, , QA — , . , . , .

, , , . «» , , QA , , , .

. , . QA-, , API , « ». , , .

. , , , — .

. . , , « .» « Y.». QA- — , , .

, , ; , — , , — QA , , , , QA .

, , , QA-, . . . , , .

— , API , , ( ) — , .

, , C++.

, . , , , , , . , - , , .

, , , , . , , — , . , ( data breakpoints ) , , — , , ? , , , , , , , , , ( soak testing )?

. , . , ; ; ; ; ; , ; , , .

, «», . , , , — . , — , . - , .

« ++» , . ; , ; , . « C++» , — , , STL _ _, STL . , STL « », ; , , , .

, , « C++» — , . — , .

, C++ , . , . , . copy elision ( ) , . . , , NRVO , , . , C++ .

: ++

, C++, .

1.

, C++, , . , . , , — .

, . C++98, , - , .

, , , . , C++-, «» C++. — , C C++98. , , , – , . ?

2.

, GDC, CppCon , , . ; ; . , , — , .

C++ . , SG14, SG7, SG15 — , — isocpp.org . — , , 200 ? «» «» .

, , , , Twitter Reddit. , — .