Warum verwenden moderne Bibliotheken kein OOP?

20

Ich bin ein Anfänger-C ++ - Programmierer, aber ich verstehe die Konzepte der Sprache ziemlich gut. Als ich anfing, externe C ++ - Bibliotheken wie SDL, OpenGL (vielleicht auch etwas anderes) zu lernen, stellte ich zu meiner großen Überraschung fest, dass sie überhaupt keine C ++ - Konzepte verwenden.

Beispielsweise verwenden weder SDL noch OpenGL Klassen oder Ausnahmen, die Funktionen und Fehlercodes bevorzugen. In OpenGL habe ich Funktionen wie glVertex2f gesehen, die 2 Float-Variablen als Eingabe nehmen und wahrscheinlich besser als Vorlage wären. Darüber hinaus verwenden diese Bibliotheken manchmal Markos, während es allgemein üblich zu sein scheint, dass die Verwendung von Makros schlecht ist.

Alles in allem scheinen sie eher im C-Stil als im C ++ - Stil geschrieben zu sein. Aber es sind ganz andere, inkompatible Sprachen, nicht wahr?

Die Frage ist: Warum nutzen moderne Bibliotheken nicht die Vorteile der Sprache, in der sie geschrieben sind?

— Saage
quelle

1

Ich denke, Timo hat Ihre Frage gut beantwortet. Andere Gründe (für andere Bibliotheken) können eine Bibliothek sein, die in C erstellt und anschließend portiert wurde. Oder C-Entwickler haben es geschrieben.

— Jeanne Boyarsky

5

Abgesehen davon sind weder OpenGL noch "modern" in dem Sinne, dass sie jung sind oder zumindest in der Lage sind, ausgefallene neue Funktionen zu übernehmen. Beide haben eine lange Geschichte (OpenGL 1.1: 1997; SDL: 1998) und Abwärtskompatibilitätsbeschränkungen.

1

Nur so heißt es: DirectX ist viel objektiver (wenn auch einiges niedriger).

— cHao

1

Native C ++ - Bibliotheken wie stl und Boost verwenden auch nicht die beschissenen, veralteten, nutzlosen OOP-Konzepte.

— SK-logic

5

Ich denke, Ihr Missverständnis hier ist, dass SDL und OpenGL für viele "moderne Bibliotheken" repräsentativ sind. Die sehr beliebte Qt-Bibliothek beispielsweise ist vollständig objektorientiert. Ihr Fragentitel sollte besser "Warum verwenden SDL und OpenGL kein OOP" sein?

— Doc Brown

31

Sowohl OpenGL als auch SDL sind C-Bibliotheken und stellen eine C-Schnittstelle für den Rest der Welt zur Verfügung (da so ziemlich jede Sprache auf dem Markt mit C kommunizieren kann, aber nicht unbedingt mit C ++). Sie sind daher auf die von C bereitgestellte prozedurale Schnittstelle und die C-Methode zum Deklarieren und Verwenden von Datenstrukturen beschränkt.

Abgesehen von dem Aspekt der "Schnittstelle mit anderen Sprachen", den eine C-Schnittstelle bietet, ist C im Allgemeinen ein bisschen portabler als C ++, was es wiederum einfacher macht, den nicht plattformabhängigen Teil des Bibliothekscodes abzurufen wie diese auf einem anderen Betriebssystem oder einer anderen Hardwarearchitektur arbeiten. So ziemlich jede Plattform hat einen anständigen C-Compiler, aber es gibt immer noch einige, die eingeschränkte C ++ - Compiler haben oder solche, die einfach nicht sehr gut sind.

Während C und C ++ sehr unterschiedliche Sprachen sind, sind sie in der Tat nicht "inkompatibel". C ++ ist eine Obermenge von C. Es gibt einige Inkompatibilitäten, aber nicht viele. Daher ist die Verwendung einer C-Schnittstelle von C ++ eine sehr einfache Sache machen.

— Timo Geusch
quelle

Oh, ich verstehe. Nun, die nächste Frage: Gibt es beispielsweise eine Grafikbibliothek für C ++, die so effektiv ist wie OpenGL? Oder vielleicht ein Wrapper über OpenGL, der alle Vorteile von C ++ nutzt und eine gute Ressourcenverwaltung bietet? Die APIs würden viel sauberer aussehen, und ich denke nicht, dass der Speicher- / CPU-Overhead zu hoch wäre.

— Saage

Effektiv oder effizient? In beiden Fällen sollte es ziemlich einfach sein, einen C ++ - Wrapper für SDL oder OpenGL zu finden. Ein schnelles Google brachte diesen Wrapper für OpenGL: oglplus.org - keine Ahnung, wie gut es ist, ich habe es nicht verwendet.

— Timo Geusch

1

Ja, es gibt eine ganze Reihe von Projekten, die versuchen, OpenGL mit mehr C ++ - Schnittstellen zu versehen (ich habe sogar eine, obwohl ich auf viele Funktionen verzichte und meistens Überladungen und ähnliches hinzufüge). Mein Eindruck ist, dass die meisten eine Menge Gepäck hinzufügen, was es sowohl schwieriger macht, reine OpenGL-Snippets zu übersetzen, als auch Standardoptimierungen (siehe Datenorientiertes Design; manche Spieleentwickler schwören darauf). Aber lass dich auf keinen Fall davon abhalten. Alternativ kann es sein, dass Sie mehr Glück haben, wenn Sie eine ganze Spiel-Engine (wie Irrlicht oder Ogre) verwenden, als nur eine Bare-Bones-Grafik-API.

Okay, ich glaube, ich habe alle Antworten, die ich gesucht habe. Vielen Dank an alle!

— Saage

Es sollte auch beachtet werden, dass Grafikhardware keine Berechnungen für Klassen versteht oder durchführt. Sie haben float3s, weil die gesamte Hardware mit Arrays von Floats befasst ist. Die "Klassen" -Struktur (die Vorstellung, dass ein Vektor 2, 3 oder 4 Floats ist) ist alles implizit in der Art und Weise, wie die Karte angewiesen wird, auf ihren Speicherhaufen zuzugreifen. Es mag schön sein, beim Programmieren von Grafiken in Klassen nachzudenken, aber meiner Meinung nach ist diese Art von Arbeit der Hardware nahe genug, dass es eher ein Ärger ist, als die schmutzigen Details der Implementierung zu abstrahieren.

— David Cowden

10

Ich denke, Sie sind verwirrend, "eine Bibliothek zu schreiben" gegen "API nach außen auszusetzen". Ich weiß nicht viel über die Bibliotheken, die Sie erwähnt haben (sie sind möglicherweise intern in C geschrieben), aber ich weiß, dass viele andere, auch ich, C ++ - Bibliotheken / Frameworks geschrieben haben, die alle Arten von ausgefallenen OOP-Praktiken / Mustern voll ausnutzen , aber immer noch C-API nach außen ausgesetzt.

C und C ++ sind keine völlig unterschiedlichen Systeme. C ++ wurde auf C aufgebaut und a) kann problemlos C-Code konsumieren und b) ist in der Lage, Apis im C-Stil bereitzustellen.
Der Vorteil der C-Schnittstelle besteht darin, dass sie vom Rest der Welt sehr leicht konsumiert werden kann. Es gibt Interop-Layer, mit denen C API aus nahezu jeder Sprache (Python, Java, C #, PHP ...) verwendet werden kann, von der aus C ++ als Schnittstelle verwendet werden kann. verschiedene Compiler, verschiedene Versionen desselben Compilers verursachen Probleme)

In der Vergangenheit habe ich mich als Experiment in einem der Projekte bei der Arbeit entschieden, "OO" -Schnittstelle aus einer C ++ - DLL verfügbar zu machen. Um interne Details zu verbergen und viele andere Dinge zu vermeiden, habe ich Windows COM (Komponentenobjektmodell) fast neu erfunden. Nach diesem Projekt wurde mir klar, dass COM nicht so schlimm ist, wie die Leute glauben, weil a) es OOP-Schnittstellen offenlegt, b) sich um alle Probleme kümmert, auf die ich gestoßen bin, und c) Standard genug ist, um von einer Reihe von Konsumenten konsumiert zu werden andere Sprachen.

Aber COM ist immer noch nicht ohne Gepäck. In vielen Fällen ist die reguläre Plan-C-API immer noch eine viel bessere Alternative.

— DXM
quelle

7

Sowohl OpenGL als auch SDL sind C-Bibliotheken, keine C ++ - Bibliotheken. Sie können sie von C ++ aus verwenden, aber sie sind in C geschrieben und verfügen über eine C-API (auf die auch in anderen Sprachen zugegriffen werden kann; C ++ ist ein Problem für den Zugriff über ein FFI). Werfen Sie einen Blick auf Boost für eine große Anzahl allgemeiner (und einiger spezialisierter) C ++ - Bibliotheken und auf SFML für eine C ++ - Multimediabibliothek.

3

OpenGL war ursprünglich Teil eines Stapels von APIs - OpenGL bot eine leistungsorientierte API auf niedriger Ebene, auf die über C (oder Fortran) zugegriffen werden konnte, während OpenInventor eine objektorientierte API auf hoher Ebene bereitstellte Es kann in C ++ verwendet werden und bietet sowohl eine hochrangige API für Szenendiagramme als auch Abstraktionen zum Speichern / Lesen von Szenen in / aus Dateien und zur GUI-Integration.

OpenGL ging viel weiter als OpenInventor (es erfüllte ein dringenderes Bedürfnis, gab Videohardwareherstellern Optimierungsbedarf und stellte ein allgemeines Low-Level-API-Ziel bereit, anstatt sich direkt mit 3D-Beschleunigungshardware zu befassen). Aber OpenInventor ist immer noch da und es gibt eine gute Open-Source-Implementierung - Coin3D - mit Unterstützung für Unix / X11, Windows und MacOS X / Cocoa.

— im uhrzeigersinn
quelle

-2

Diese Bibliotheken sind überhaupt nicht entfernt modern. Sie sind C-APIs und auch schlechte. Ihre Prämisse ist fehlerhaft.

— DeadMG
quelle

Wie ist OpenGL nicht modern?

— James

1

Dem müsste ich eigentlich zustimmen. OpenGL ist insofern nicht modern, als sein Modell für den Zugriff und die Manipulation des von ihm verwalteten Zustands auf Hardware aus den frühen neunziger Jahren basiert. Es ist nicht sehr modern, eine Textur an ein bestimmtes Ziel auf einer bestimmten Einheit binden zu müssen und nur eine begrenzte Anzahl davon zur Verfügung zu haben, unabhängig davon, wie viele Texturen Sie in VRAM haben.

— user1118321