Nachdem ich mehrere Jahre in anderen Sprachen entwickelt habe, komme ich zurück zu C ++, weil einige der netten Features mit ISO C ++ 11 eingeführt wurden. Gibt es Bibliotheken (auf DirectX / OpenGL-Basis), die diese neuen Funktionen in ihrer öffentlichen API verwenden (Shared Ptrs, Lambda-freundlich usw.)?
BEARBEITEN: Die Bibliothek kann auch im Beta-Status sein, da ich nicht davon ausgehe, dass eine Bibliothek auf einer noch nicht vollständig freigegebenen Spezifikation kommerziell verfügbar ist.
Soweit ich weiß, gibt es noch immer keinen vollständigen C ++ 11-Compiler. G ++ ist ziemlich nahe , ist aber noch nicht da. Ich würde vorschlagen, zu warten. Es macht Sinn, die Sprache zu studieren (auch wenn sie nicht verfügbar ist), aber ich denke, es wird einige Jahre dauern, bis sich der Staub beruhigt hat.
Soweit ich weiß, gibt es wenig Platz, um irgendwelche "fortgeschrittenen" Sprachfunktionen (die sogar alles enthalten, was in c ++ 03 vorhanden war) in irgendeiner Grafikbibliothek zu verwenden. Der Versuch, Hardware-Ressourcen vollständig zu nutzen, ist nicht der Ort, an dem es sinnvoll ist, "Programming Kung-Fu" zu verwenden - am Ende macht man sich Sorgen um andere Dinge, und das KISS-Prinzip hat Priorität. Entweder das, oder man taucht ein in einen sehr spezifischen, den Verstand zerstörenden trigonometrischen Albtraum, wo das KISS-Prinzip wieder Priorität hat.
Soweit ich weiß, ist eine Änderung der grafischen API wegen der einzelnen Sprache nicht sinnvoll, weil die Verfügbarkeit in mehreren Sprachen wichtiger ist. Das gilt insbesondere für OpenGL, aber selbst DirectX hatte einige "fan-made" -Bindungen.
Im Moment steht es Ihnen frei, die gewünschten Funktionen zu verwenden, während Sie benutzerdefinierte Frameworks entwickeln, die auf der bestehenden 3D-API aufsetzen. Geteilte / schwache Zeiger sind bei der Ressourcenverwaltung nützlich. Es gibt jedoch keinen Grund, C ++ 11 dafür zu verwenden, da die Funktionalität in Boost verfügbar ist.
- BEARBEITEN -
Qt 5 ist zu haben C ++ 11 Unterstützung. Es ist technisch eine grafische Bibliothek, die OpenGL verwendet ...
Aus der README:
Magnum ist eine 2D / 3D-Grafik-Engine, die in C ++ 11 / C ++ 14 und modern geschrieben wurde OpenGL. Sein Ziel ist es, Low-Level-Grafik-Entwicklung und zu vereinfachen Interaktion mit OpenGL mit den letzten C ++ 11 / C ++ 14 Features und zu plattformspezifische Probleme abstrahieren.
Nichts hindert Sie daran, z. Lambda-, Auto- und Initialisierungslisten in jedem Code.
Gtkmm und Verwandte (Sie können Kairo C ++ - Bindungen genießen) haben saubere C ++ - Schnittstellen, mit denen Sie lambdas und Autos verwenden können wenn du es für richtig hältst. Es ist sehr nützlich, ein Lambda als Signal-Handler zu verwenden und Auto zu verwenden, wenn eine Variable von einem Gtk-Smart-Zeiger initialisiert wird.
Außerdem ist grafischer Code oft ein recht kleiner Teil einer Anwendung, und für die anderen Teile können Sie C ++ mit seiner vollständigen Standardbibliothek verwenden.
Ansonsten ist die Unterstützung für C ++ 11 noch nicht ganz da (Visual Studio ist weit entfernt, die Unterstützung von g ++ ist noch nicht abgeschlossen), und daher sind Bibliotheken für C ++ 11 nicht geeignet noch hier.
Nichts hindert Sie daran, es zu versuchen und zu machen:)
Was Ihnen am nächsten kommt, ist wahrscheinlich SFML . Dies ist ein ziemlich sauberer Objekt-Wrapper OpenGL, das mehr oder weniger durchgängig moderne C ++ - Idiome verwendet.
Es verwendet jedoch nicht C ++ 11, und es ist viel zu groß, um nur portiert zu werden (es enthält Sound, Netzwerk und vieles mehr zusätzlich zu Grafiken).
Ich denke, es könnte als gute Grundlage für ein inkrementelles API-Update für C ++ 11 dienen.
Nun, nein zu OpenGL, weil es eine C-kompatible API ist.
Was DirectX betrifft, werden sie sicherlich nicht überall hin wechseln und die API ändern, nur um Sprachfunktionen wie Lambda zu integrieren, wenn es nicht notwendig ist. C ++ 11-Compiler werden im Vergleich zu früheren Versionen des Standards immer noch nicht verwendet. Daher wäre es sehr dumm, eine API zu erstellen, die nur ein kleiner Teil der Entwickler verwenden kann.
Es gibt weitreichende Auswirkungen auf die Änderung Ihrer API, wenn Tausende / Millionen von Benutzern sie verwenden. Es wäre sehr verantwortungslos von ihnen, Lambda API-Funktionen hinzuzufügen, nur weil sie ordentlich und glänzend sind. Darüber hinaus ist es nicht so, dass Sie Ihre API mit jeder neuen Version brechen können, wenn Sie sich um die Leute kümmern, die sie tatsächlich verwenden.
EJDIT:
Ich habe die Frage zunächst missverstanden. C ++ 11 ist so neu, dass es wahrscheinlich noch keine API - Änderungen an bestehenden Bibliotheken gibt, da dies ihre Benutzerbasis stark einschränken würde (es gibt zu diesem Zeitpunkt keinen voll funktionsfähigen C ++ 11 - Compiler, soweit ich weiß) selbst wenn es die meisten von uns noch nicht benutzen würden).
Wie einige der Kommentatoren zu Recht angemerkt haben, war meine anfängliche Antwort zu eng. Sie haben hinzugefügt, dass eine Beta-Version akzeptabel wäre. Mir sind noch immer keine Bibliotheken bekannt, die ihre APIs drastisch geändert haben, um neue Funktionen in C ++ 11 zu integrieren, und mein vorheriger Punkt steht immer noch.
Das Ändern der API-Funktionssignaturen ist gefährlich, weil Sie die Rückwärtskompatibilität brechen. Wenn diese Änderungen eintreten, erwarte ich, dass sie Ergänzungen zur API sind, keine Änderungen. Vielleicht kennt jemand in der Umgebung sehr aktuelle Änderungen an bestehenden Bibliotheken, die mir nicht bekannt sind.