Perché le librerie moderne non usano OOP

Sia OpenGL che SDL sono librerie C ed espongono un'interfaccia C al resto del mondo (dato che praticamente tutte le lingue là fuori possono interfacciarsi con C ma non necessariamente con C ++). Pertanto, sono limitati all'interfaccia procedurale fornita da C e al modo C di dichiarare e utilizzare strutture di dati.

Oltre all'aspetto "interfacciamento con altri linguaggi" che offre un'interfaccia C, C in generale tende ad essere un po 'più portatile del C ++, che a sua volta rende più facile ottenere la parte non dipendente dalla piattaforma del codice di librerie come queste che lavorano su un altro OS o architettura hardware. Praticamente tutte le piattaforme là fuori hanno un compilatore C decente, ma ce ne sono ancora alcune che hanno dei compilatori C ++ ristretti o che non sono proprio ottimi.

Mentre C e C ++ sono linguaggi molto diversi, non sono "incompatibili", infatti, in gran parte C ++ è un superset di C. Ci sono alcune incompatibilità ma non molte, quindi usare un'interfaccia C da C ++ è un cosa molto semplice da fare.

Penso che tu stia confondendo "scrivere una biblioteca" contro "esponendo le API all'esterno". Non conosco molto specificamente le librerie che hai menzionato (potrebbero essere scritte internamente in C), ma so che molti altri, me compreso, hanno scritto librerie / framework C ++ che hanno utilizzato completamente tutti i tipi di pratiche / schemi OOP di fantasia , ma ha comunque esposto le API in stile C al mondo esterno.

1. C e C ++ non sono sistemi completamente diversi. C ++ è stato costruito sopra C e a) può facilmente consumare codice C e b) è pienamente in grado di fornire apis C-style.
2. Il vantaggio dell'interfaccia C è che è facilmente consumabile dal resto del mondo. Esistono livelli di interoperabilità che consentono l'utilizzo dell'API C praticamente da qualsiasi linguaggio (python, java, c #, php ...), dove l'interfaccia C ++ è consumabile da ..... beh, forse C ++ e ancora non sempre ( compilatori diversi, versioni diverse dello stesso compilatore causeranno problemi)

In passato, come esperimento in uno dei progetti in corso, ho deciso di esporre l'interfaccia "OO" da una DLL C ++. Per nascondere i dettagli interni ed evitare un sacco di altre cose, ho quasi finito per reinventare la COM di Windows (modello di oggetti componente). Dopo questo progetto, mi sono reso conto che COM non è così male come la gente lo dimostra perché a) espone interfacce OOP, b) si prende cura di tutti i problemi che ho incontrato e c) è abbastanza standard per essere consumabile da un numero di altre lingue.

Ma COM non è ancora senza il suo bagaglio. In molti casi, l'API regolare in stile C è ancora un'alternativa molto migliore.

Sia OpenGL che SDL sono librerie C, non librerie C ++. Puoi usarli da C ++, ma sono scritti in C e hanno un'API C (che è accessibile anche da altre lingue; C ++ è un problema per accedere tramite una FFI). Dai un'occhiata a Boost per una vasta gamma di librerie C ++ generiche (e alcune specializzate) e SFML per una libreria multimediale C ++.

Parlando specificamente con OpenGL, OpenGL era originariamente parte di una serie di API - OpenGL forniva un'API orientata alle prestazioni di basso livello, accessibile da C (o anche da Fortran), mentre OpenInventor fornisce un oggetto di alto livello orientato agli oggetti API, progettata per essere utilizzata da C ++ e che fornisce sia un'API grafico di scena di alto livello, sia astrazioni per il salvataggio / la lettura di scene da / verso file e l'integrazione della GUI.

OpenGL ha finito per andare molto più lontano di OpenInventor (rispondeva a un'esigenza più pressante, dando ai produttori di hardware video qualcosa da ottimizzare e fornendo una comune API a basso livello che le persone potevano indirizzare invece di gestire direttamente l'hardware di accelerazione 3D). Ma OpenInventor è ancora là fuori, e c'è una buona implementazione open source - Coin3D - con supporto per Unix / X11, Windows e MacOS X / Cocoa.

Queste librerie non sono affatto moderne. Sono API C e cattive. La tua premessa è imperfetta.