Dlaczego współczesne biblioteki nie używają OOP

20

Jestem programistą C ++ na poziomie początkującym, ale rozumiem pojęcia języka dość dobrze. Kiedy zacząłem uczyć się zewnętrznych bibliotek C ++, takich jak SDL, OpenGL (może też coś innego), ku mojemu wielkiemu zaskoczeniu odkryłem, że w ogóle nie używają pojęć C ++.

Na przykład ani SDL, ani OpenGL nie używają klas ani wyjątków, preferując funkcje i kody błędów. W OpenGL widziałem takie funkcje jak glVertex2f, który przyjmuje 2 zmienne zmiennoprzecinkowe jako dane wejściowe i prawdopodobnie byłby lepszy jako szablon. Co więcej, biblioteki te czasami używają marcos, podczas gdy wydaje się, że powszechna zgoda, że ​​używanie makr jest złe.

Podsumowując, wydają się być napisane bardziej w stylu C niż w stylu C ++. Ale to zupełnie inne nieporównywalne języki, prawda?

Pytanie brzmi: dlaczego współczesne biblioteki nie korzystają z zalet języka, w którym są napisane?

c++ object-oriented libraries opengl Saage
źródło
1
Myślę, że Timo dobrze odpowiedział na twoje pytanie. Innymi powodami (dla innych bibliotek) może być biblioteka, która została utworzona w C, a następnie przeniesiona. Lub napisali to programiści C.
Jeanne Boyarsky
5
Poza tym ani OpenGL, ani nie są „nowocześni” w tym sensie, że są młodzi, a przynajmniej potrafią przyjmować nowe fantazyjne kształty. Oba mają długą historię (OpenGL 1.1: 1997; SDL: 1998) i ograniczenia kompatybilności wstecznej.
1
Tak tylko powiedziano: DirectX jest znacznie bardziej oczywisty (jeśli również nieco niższy poziom).
cHao
1
Natywne biblioteki C ++, takie jak stl i Boost, również nie używają marnych, przestarzałych, bezużytecznych koncepcji OOP.
SK-logic
5
Myślę, że waszym błędnym przekonaniem jest to, że SDL i OpenGL są reprezentatywne dla wielu „nowoczesnych bibliotek”. Na przykład bardzo popularna biblioteka Qt jest w pełni zorientowana obiektowo. Twój tytuł pytania powinien brzmieć „Dlaczego SDL i OpenGL nie używają OOP”?
Doc Brown,

Odpowiedzi:

31

Zarówno OpenGL, jak i SDL są bibliotekami C i udostępniają interfejs C reszcie świata (ponieważ prawie każdy język na rynku może się komunikować z C, ale niekoniecznie z C ++). W związku z tym są ograniczone do interfejsu proceduralnego, który daje Ci C i sposobu C deklarowania i używania struktur danych.

Oprócz aspektu „interfejsu z innymi językami” oferowanego przez interfejs C, ogólnie C jest nieco bardziej przenośny niż C ++, co z kolei ułatwia uzyskanie niezależnej od platformy części kodu bibliotek takie jak te działające na innym systemie operacyjnym lub architekturze sprzętowej. Prawie każda platforma ma przyzwoity kompilator C, ale wciąż istnieją takie, które mają ograniczone kompilatory C ++ lub te, które nie są zbyt dobre.

Chociaż C i C ++ są bardzo różnymi językami, nie są „niekompatybilne”, w rzeczywistości w dużym stopniu C ++ jest nadzbiorem C. Jest kilka niezgodności, ale nie wiele, więc używanie interfejsu C z C ++ jest bardzo łatwe do zrobienia.

Timo Geusch
źródło
Rozumiem. Cóż, następne pytanie: czy istnieje, powiedzmy, biblioteka graficzna dla C ++ tak skuteczna jak OpenGL? A może opakowanie nad OpenGL, które wykorzystuje wszystkie zalety C ++ i zapewnia dobre zarządzanie zasobami? Interfejsy API wyglądałyby znacznie czystsze i nie sądzę, aby narzut pamięci / procesora byłby zbyt wysoki.
Saage
Skuteczny czy wydajny? Tak czy inaczej, znalezienie opakowania C ++ dla SDL lub OpenGL powinno być dość łatwe. Szybkie Google przyniosło to opakowanie dla OpenGL: oglplus.org - nie mam pojęcia, jak dobre jest, nie użyłem go.
Timo Geusch
1
Tak, jest całkiem sporo projektów, które próbują owijać OpenGL w więcej interfejsów ish C ++ (nawet ja mam jeden, chociaż powstrzymuję się od wielu funkcji i przeważnie dodajemy przeciążenie itp.). Mam wrażenie, że większość dodaje dużo bagażu, co sprawia, że ​​zarówno trudniej jest przetłumaczyć czyste fragmenty OpenGL, jak i trudniej zastosować standardowe optymalizacje (patrz Projektowanie zorientowane na dane; niektórzy twórcy gry przysięgają). Ale na pewno nie pozwól, aby cię to powstrzymało. Alternatywnie, możesz mieć więcej szczęścia, używając całego silnika gry (takiego jak Irrlicht lub Ogre), a nie tylko graficznego interfejsu API.
Dobra, chyba mam wszystkie odpowiedzi, których szukałem. Dziękuję wszystkim!
Saage
Należy również zauważyć, że sprzęt graficzny nie rozumie ani nie wykonuje obliczeń na klasach. Masz float3s, ponieważ cały sprzęt dotyczy macierzy liczb zmiennoprzecinkowych. Struktura „klasy” (pojęcie, że wektor ma 2, 3 lub 4 zmiennoprzecinkowe) jest domyślna w sposobie, w jaki karta ma uzyskać dostęp do stosu pamięci. Przyjemnie jest próbować myśleć na zajęciach podczas programowania grafiki, ale moim zdaniem ten rodzaj pracy jest wystarczająco blisko sprzętu, że jest bardziej kłopotliwy niż pomoc w usuwaniu brudnych szczegółów implementacji.
David Cowden,
10

Myślę, że mylisz „pisanie biblioteki” z „eksponowaniem API na zewnątrz”. Nie wiem zbyt wiele o bibliotekach, o których wspomniałeś (mogą być wewnętrznie napisane w C), ale wiem, że wiele innych, łącznie ze mną, napisało biblioteki / frameworki C ++, które w pełni wykorzystywały wszelkiego rodzaju fantazyjne praktyki / wzorce OOP , ale nadal udostępnia interfejs API w stylu C światu zewnętrznemu.

  1. C i C ++ nie są całkowicie różnymi systemami. C ++ został zbudowany na C i a) może z łatwością zużywać kod C, a b) jest w pełni zdolny do obsługi api w stylu C.
  2. Zaletą interfejsu C jest to, że jest bardzo łatwo konsumowany przez resztę świata. Istnieją warstwy interop, które pozwalają na używanie C API z dowolnego języka (python, java, c #, php ...), gdzie jako interfejs C ++ można korzystać z ..... cóż, być może C ++ i wciąż nie zawsze ( różne kompilatory, różne wersje tego samego kompilatora powodują problemy)

W przeszłości, jako eksperyment w jednym z działających projektów, postanowiłem udostępnić interfejs „OO” z biblioteki DLL C ++. Aby ukryć wewnętrzne szczegóły i uniknąć wielu innych rzeczy, prawie skończyłem na nowo opracowywać system Windows COM (model obiektowy). Po tym projekcie zdałem sobie sprawę, że COM nie jest tak zły, jak się wydaje, ponieważ a) ujawnia interfejsy OOP, b) zajmuje się wszystkimi problemami, na które natknąłem się, c) jest wystarczająco standardowy, aby można go było wykorzystać z wielu inne języki.

Ale COM wciąż nie jest pozbawiony bagażu. W wielu przypadkach zwykły, planowy interfejs API w stylu C jest nadal znacznie lepszą alternatywą.

DXM
źródło
7

Zarówno OpenGL, jak i SDL są bibliotekami C, a nie bibliotekami C ++. Możesz używać ich z C ++, ale są napisane w C i mają C API (który jest również dostępny z innych języków; C ++ jest trudny w dostępie przez FFI). Spójrz na Boost dla szerokiej gamy uniwersalnych (i niektórych specjalistycznych) bibliotek C ++ i SFML dla biblioteki multimedialnej C ++.


źródło
3

Mówiąc konkretnie do OpenGL, OpenGL był pierwotnie częścią stosu API - OpenGL dostarczył API zorientowane na wydajność niskiego poziomu, dostępne z C (lub nawet Fortran), podczas gdy OpenInventor zapewnia obiektowe API wysokiego poziomu, zaprojektowane do użycia z C ++, zapewniając zarówno interfejs API wysokiego poziomu wykresów, jak i abstrakcje do zapisywania / czytania scen do / z plików oraz integrację GUI.

OpenGL skończył znacznie dalej niż OpenInventor (zaspokoił bardziej palącą potrzebę, dając twórcom sprzętu wideo coś do zoptymalizowania i zapewniając wspólny interfejs API niskiego poziomu, na który ludzie mogliby celować zamiast bezpośrednio zajmować się sprzętem przyspieszającym 3D). Ale OpenInventor nadal istnieje i istnieje dobra implementacja open source - Coin3D - z obsługą Unix / X11, Windows i MacOS X / Cocoa.

jimwise
źródło
-2

Te biblioteki wcale nie są wcale nowoczesne. Są to interfejsy API typu C i złe. Twoja przesłanka jest wadliwa.

DeadMG
źródło
Jak OpenGL nie jest nowoczesny?
James
1
Właściwie musiałbym się z tym zgodzić. OpenGL nie jest nowoczesny, ponieważ jego model dostępu i zarządzania stanem, którym zarządza, oparty jest na sprzęcie z początku lat 90. Robienie rzeczy takich jak wiązanie tekstury z konkretnym celem na konkretnej jednostce i posiadanie ograniczonej liczby dostępnych bez względu na to, ile tekstur masz w VRAM, nie jest zbyt nowoczesne.
user1118321