Perché le biblioteche moderne non usano OOP

20

Sono un programmatore C ++ di livello principiante, ma capisco abbastanza bene i concetti del linguaggio. Quando ho iniziato a studiare librerie C ++ esterne, come SDL, OpenGL (forse anche qualcos'altro), con mia grande sorpresa ho scoperto che non usano affatto concetti C ++.

Ad esempio, né SDL, né OpenGL utilizzano classi o eccezioni, preferendo funzioni e codici di errore. In OpenGL ho visto funzioni come glVertex2f, che accetta 2 variabili float come input e probabilmente sarebbe meglio come modello. Inoltre, queste librerie a volte usano marcos, mentre sembra essere un accordo comune sul fatto che usare le macro sia male.

Tutto sommato, sembrano essere scritti più in stile C che in stile C ++. Ma sono lingue incomprensibili completamente diverse, no?

La domanda è: perché le biblioteche moderne non usano i vantaggi della lingua in cui sono scritte?

— Saage
fonte

1

Penso che Timo abbia risposto bene alla tua domanda. Altri motivi (per altre librerie) potrebbero essere una libreria creata in C e quindi trasferita. O gli sviluppatori C lo hanno scritto.

— Jeanne Boyarsky,

5

A parte questo, né OpenGL né sono "moderni" nel senso che sono giovani, o almeno in grado di adottare nuove fantasiose fiere. Entrambi hanno una lunga storia (OpenGL 1.1: 1997; SDL: 1998) e vincoli di retrocompatibilità.

1

Proprio così si dice: DirectX è molto più oggettivo (anche se un po 'più basso livello).

— cHao,

1

Le librerie C ++ native, come stl e Boost, non usano anche i concetti OOP scadenti, obsoleti e inutili.

— SK-logic,

5

Penso che il tuo malinteso qui sia che SDL e OpenGL siano rappresentativi di molte "librerie moderne". La libreria Qt molto popolare, ad esempio, è completamente orientata agli oggetti. Il titolo della tua domanda dovrebbe essere "Perché SDL e OpenGL non usano OOP"?

— Doc Brown,

31

Sia OpenGL che SDL sono librerie C ed espongono un'interfaccia C al resto del mondo (come praticamente ogni lingua là fuori può interfacciarsi con C ma non necessariamente con C ++). Pertanto, sono limitati all'interfaccia procedurale che C offre a te e al modo C di dichiarare e utilizzare le strutture di dati.

Oltre all'aspetto "interfacciamento con altre lingue" che ti offre un'interfaccia C, C in generale tende ad essere un po 'più portabile di C ++, il che a sua volta rende più facile ottenere la parte non dipendente dalla piattaforma del codice delle librerie come questi che funzionano su un altro sistema operativo o architettura hardware. Praticamente ogni piattaforma là fuori ha un compilatore C decente, ma ce ne sono ancora alcuni che hanno compilatori C ++ limitati o quelli che non sono proprio buoni.

Sebbene C e C ++ siano linguaggi molto diversi, non sono "incompatibili", in realtà in larga misura C ++ è un superset di C. Ci sono alcune incompatibilità ma non molte, quindi usare un'interfaccia C da C ++ è una cosa molto semplice fare.

— Timo Geusch
fonte

Oh, capisco. Bene, la prossima domanda allora: esiste, diciamo, una libreria grafica per C ++ efficace come OpenGL? O forse un wrapper su OpenGL che utilizza tutti i vantaggi di C ++ e offre una buona gestione delle risorse? Le API sembrerebbero molto più pulite e non penso che il sovraccarico di memoria / CPU sia troppo elevato.

— Saage

Efficace o efficiente? In entrambi i casi, dovrebbe essere abbastanza facile trovare un wrapper C ++ per SDL o OpenGL. Un rapido Google ha introdotto questo wrapper per OpenGL: oglplus.org - non ho idea di quanto sia bello, non l'ho usato.

— Timo Geusch,

1

Sì, ci sono alcuni progetti che tentano di impacchettare OpenGL con più interfacce ish C ++ (ne ho anche una me stessa, anche se mi astengo da molte funzionalità e per lo più aggiungo sovraccarico e simili). La mia impressione è che la maggior parte aggiunga molto bagaglio, il che rende sia più difficile tradurre snippet OpenGL puri sia più difficile applicare ottimizzazioni standard (cercare Design orientato ai dati; alcuni sviluppatori di giochi lo giurano). Ma non lasciare che ciò ti scoraggi. In alternativa, potresti avere più fortuna utilizzando un intero motore di gioco (come Irrlicht o Ogre) anziché solo un'API grafica a ossa nude.

Va bene, penso di avere tutte le risposte che cercavo. Grazie a tutti!

— Saage

Va inoltre notato che l'hardware grafico non comprende o esegue calcoli sulle classi. Hai float3s perché tutto l'hardware è interessato da array di float. La struttura di "classe" (l'idea che un vettore sia 2, 3 o 4 float) è implicita nel modo in cui viene detto alla carta di accedere al suo mucchio di memoria. Può essere bello provare a pensare in classe durante la programmazione della grafica, ma secondo me quel tipo di lavoro è abbastanza vicino all'hardware che è più una seccatura che aiutare a sottrarre i dettagli sporchi dell'implementazione.

— David Cowden,

10

Penso che tu stia confondendo "la scrittura di una libreria" contro "l'esposizione dell'API all'esterno". Non conosco molto specificamente le librerie che hai citato (potrebbero essere scritte internamente in C), ma so che molte altre, me compreso, hanno scritto librerie / framework C ++ che hanno pienamente utilizzato tutti i tipi di pratiche / schemi OOP fantasiosi , ma ancora esposto API in stile C al mondo esterno.

C e C ++ non sono sistemi completamente diversi. Il C ++ è stato costruito sopra C e a) può facilmente consumare codice C eb) è pienamente in grado di fornire API in stile C.
Il vantaggio dell'interfaccia C è che è facilmente consumabile dal resto del mondo. Esistono livelli di interoperabilità che consentono di consumare l'API C da qualsiasi linguaggio (python, java, c #, php ...), dove l'interfaccia C ++ è utilizzabile da ..... beh, forse C ++ e 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 ++. Al fine di nascondere i dettagli interni ed evitare un sacco di altre cose, ho quasi finito per reinventare Windows COM (modello a oggetti componente). Dopo quel progetto, mi sono reso conto che COM non è così male come lo fanno le persone perché a) espone le interfacce OOP, b) si occupa di tutti i problemi che ho incontrato ec) è abbastanza standard da poter essere consumato da un numero di altre lingue.

Ma COM non è ancora senza il suo bagaglio. In molti casi, l'API C-style normale e pianificata è ancora un'alternativa molto migliore.

— DXM
fonte

7

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

3

Parlando in particolare di OpenGL, OpenGL faceva parte originariamente di una serie di API: OpenGL forniva un'API di basso livello e orientata alle prestazioni, accessibile da C (o persino Fortran), mentre OpenInventor fornisce un'API di alto livello orientata agli oggetti, progettata da utilizzare da C ++ e fornire sia un'API di alto livello per grafici di scena, sia astrazioni per il salvataggio / lettura di scene da / verso file e l'integrazione della GUI.

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

— jimwise
fonte

-2

Quelle librerie non sono per niente moderne. Sono API C e cattive. La tua premessa è difettosa.

— DeadMG
fonte

In che modo OpenGL non è moderno?

— James,

1

Dovrei davvero essere d'accordo con questo. OpenGL non è moderno in quanto il suo modello per l'accesso e la manipolazione dello stato che gestisce è basato sull'hardware dei primi anni '90. Dover fare cose come legare una trama a un obiettivo particolare su una determinata unità e avere solo un numero limitato di quelli disponibili indipendentemente da quante trame hai in VRAM non è molto moderno.

— user1118321