Modern kütüphaneler neden OOP kullanmıyor?

20

Başlangıç seviyesi C ++ programcısıyım, ancak dil kavramlarını oldukça iyi anlıyorum. SDL, OpenGL (belki de başka bir şey) gibi harici C ++ kütüphanelerini öğrenmeye başladığımda, büyük bir sürpriz için C ++ kavramlarını kullanmadığını öğrendim.

Örneğin, ne SDL ne de OpenGL sınıfları veya özel durumları kullanmaz, işlevleri ve hata kodlarını tercih eder. OpenGL'de, giriş olarak 2 değişken değişken alan ve muhtemelen bir şablon olarak daha iyi olacak glVertex2f gibi işlevleri gördüm. Dahası, bu kütüphaneler bazen marcos kullanıyor, ancak makro kullanımının kötü olduğu konusunda ortak bir anlaşma gibi görünüyor.

Sonuçta, C ++ stilinden daha fazla C stilinde yazılmış gibi görünüyorlar. Ama onlar tamamen farklı uyumsuz diller, değil mi?

Soru şu: modern kütüphaneler neden yazıldıkları dilin avantajlarını kullanmıyor?

— SAAGE
kaynak

1

Bence Timo sorunuzu iyi yanıtladı. Diğer nedenler (diğer kütüphaneler için) C'de oluşturulan ve sonra taşınan bir kütüphane olabilir. Ya da C geliştiricileri yazdı.

— Jeanne Boyarsky

5

Bunun dışında, ne OpenGL ne de genç olmaları anlamında "modern" değiller ya da en azından yeni fetihleri benimseyebiliyorlar. Her ikisinin de uzun bir geçmişi (OpenGL 1.1: 1997; SDL: 1998) ve geriye dönük uyumluluk kısıtlamaları vardır.

1

Sadece şöyle denir: DirectX çok daha nesneldir (eğer biraz daha düşük seviyeli ise).

— cHao

1

Stl ve Boost gibi yerel C ++ kütüphaneleri de berbat, modası geçmiş, işe yaramaz OOP kavramlarını kullanmaz.

— SK-logic

5

Sanırım buradaki yanılgı, SDL ve OpenGL'nin bir çok "modern kütüphaneyi" temsil ettiği. Örneğin çok popüler Qt kütüphanesi tamamen nesne yönelimlidir. Soru başlığınız daha iyi olmalıdır: "SDL ve OpenGL neden OOP kullanmıyor?"

— Doc Brown

31

Hem OpenGL hem de SDL, C kütüphaneleridir ve bir C arayüzünü dünyanın geri kalanına maruz bırakır (hemen hemen her dil C ile arayüz oluşturabilir, ancak C ++ ile zorunlu olmayabilir). Bu nedenle, C'nin size ve C'nin veri yapılarını bildirme ve kullanma yöntemini verdiği prosedürel arayüzle sınırlıdırlar.

C arayüzünün size sunduğu "diğer dillerle arayüz" yönünün üzerinde ve üstünde, C genellikle C ++ 'dan biraz daha taşınabilir olma eğilimindedir ve bu da kütüphane kodunun platforma bağımlı olmayan bir parçasını almayı kolaylaştırır bunlar başka bir işletim sisteminde veya donanım mimarisinde çalışıyor gibi Hemen hemen her platformun iyi bir C derleyicisi var, ancak hala C ++ derleyicilerini veya çok iyi olmayanları kısıtlayan bazı var.

C ve C ++ çok farklı diller olsa da, aslında "uyumsuz" değildir, aslında C ++, C'nin bir üst kümesidir. Bazı uyumsuzluklar vardır, ancak çok fazla değildir, bu yüzden C ++ 'dan bir C arayüzü kullanmak çok kolay bir şeydir yapmak.

— Timo Geusch
kaynak

Ah anlıyorum. Peki, bir sonraki soru: C ++ için OpenGL kadar etkili bir grafik kütüphanesi var mı? Ya da C ++ 'ın tüm avantajlarını kullanan ve kaynakların iyi yönetimini sağlayan OpenGL üzerinde bir paketleyici? API'lar çok daha temiz görünüyordu ve bellek / işlemci yükünün çok yüksek olacağını düşünmüyorum.

— Saage

Etkili mi, verimli mi? Her iki durumda da, SDL veya OpenGL için bir C ++ sarıcı bulmak oldukça kolay olmalıdır. Hızlı bir Google bu sarmalayıcıyı OpenGL için getirdi: oglplus.org - ne kadar iyi olduğu hakkında hiçbir fikrim yok, onu kullanmadım.

— Timo Geusch

1

Evet, OpenGL'yi daha fazla C ++ ish arayüzleri ile sarmaya çalışan birkaç proje var (birçok özellikten kaçınmam ve çoğunlukla aşırı yükleme ve bu tür şeyler eklememe rağmen) kendim bile var. Benim izlenimim çoğu, hem saf OpenGL snippet'lerini çevirmeyi hem de standart optimizasyonları uygulamayı daha zor hale getiren çok fazla bagaj ekliyor (Veri Odaklı Tasarım konusuna bakın; bazı oyun geliştiricileri buna yemin ediyor). Ama elbette bunun sizi caydırmasına izin vermeyin. Alternatif olarak, çıplak kemikli grafik API'sinden ziyade, tüm oyun motorunu (Irrlicht veya Ogre gibi) kullanarak daha fazla şansınız olabilir.

Tamam, sanırım aradığım tüm cevaplara sahibim. Herkese teşekkürler!

— Saage

Grafik donanımının sınıfları hesaplamadığını veya hesaplamaları yapmadığını da belirtmek gerekir. You have float3tüm donanım yüzen diziler olduğu ile ilgilidir, çünkü s. "Sınıf" yapısı (bir vektörün 2, 3 veya 4 yüzer olduğu fikri), kartın bellek yığınına nasıl erişeceği söylenir. Grafikleri programlarken sınıflarda denemek ve düşünmek güzel olabilir, ancak bence, bu tür bir çalışma, uygulamanın kirli ayrıntılarını soyutlamaya yardımcı olmaktan çok daha zor olduğu için donanıma yeterince yakındır.

— David Cowden

10

"Bir kitaplık yazma" vs "API'yi dışarıya açığa çıkarmak" gibi kafa karıştırıcı olduğunu düşünüyorum. Bahsettiğiniz kütüphaneler hakkında çok fazla şey bilmiyorum (dahili olarak C ile yazılmış olabilirler), ancak kendim de dahil olmak üzere birçok başka, her türlü süslü OOP uygulamasını / desenini tamamen kullanan C ++ kütüphaneleri / çerçeveleri yazdı. , ancak yine de dış dünyaya C stili API uyguladı.

C ve C ++ tamamen farklı sistemler değildir. C ++, C üzerine inşa edilmiştir ve a) C kodunu kolayca tüketebilir ve b) C tarzı apis sağlama yeteneğine sahiptir.
C arayüzünün avantajı, dünyanın geri kalanı tarafından kolayca tüketilebilmesidir. C API'nin hemen hemen her dilden (python, java, c #, php ...) tüketilmesine izin veren birlikte çalışma katmanları vardır, burada C ++ arayüzü ..... gibi sarf edilebilir, belki de C ++ ve hala her zaman değil ( farklı derleyiciler, aynı derleyicinin farklı sürümleri sorunlara neden olur)

Geçmişte, iş yerinde projelerden birinde bir deney olarak, bir C ++ DLL "OO" arayüzü ortaya koymaya karar verdi. Dahili ayrıntıları gizlemek ve bir sürü şeyden kaçınmak için neredeyse Windows COM'u (bileşen nesne modeli) yeniden keşfettim. Bu projeden sonra, COM'un insanlar bunu yapmak kadar kötü olmadığını fark ettim, çünkü a) OOP arayüzlerini ortaya koyuyor, b) karşılaştığım tüm sorunları hallediyor ve c) bir dizi malzemeden tüketilebilecek kadar standart Diğer diller.

Ancak COM hala bagajı olmadan değil. Çoğu durumda, düzenli, plan C tarzı API hala çok daha iyi bir alternatiftir.

— DXM
kaynak

7

Hem OpenGL hem de SDL C kütüphaneleridir, C ++ kütüphaneleridir. Onları C ++ 'dan kullanabilirsiniz, ancak C dilinde yazılmıştır ve C API'sine sahiptir (diğer dillerden de erişilebilir; C ++, bir FFI aracılığıyla erişmek için bir acıdır). Göz at Boost genel amaçlı geniş bir dizi (ve bazı özel) C ++ kütüphaneleri ve için SFML'de bir C ++ multimedya kütüphanesi için.

3

Özellikle OpenGL ile konuşan OpenGL başlangıçta bir API yığınının bir parçasıydı - OpenGL, C'den (hatta Fortran'dan) erişilebilen düşük seviyeli, performans odaklı bir API sağladı, OpenInventor ise tasarlanmış yüksek seviyeli bir nesne odaklı API sağladı C ++ 'dan kullanılmalı ve hem üst düzey bir sahne grafiği API'sı hem de sahneleri dosyalara / dosyalardan kaydetme / okuma için soyutlamalar ve GUI entegrasyonu sunmalıdır.

OpenGL, OpenInventor'dan çok daha ileri gitti (daha acil bir ihtiyacı karşıladı, video donanım üreticilerine optimize edilecek bir şey verdi ve doğrudan 3D hızlandırma donanımıyla uğraşmak yerine hedefleyebilecekleri ortak bir düşük düzey API sağladı). Ancak OpenInventor hala orada ve Unix / X11, Windows ve MacOS X / Cocoa desteğiyle iyi bir açık kaynak uygulaması - Coin3D - var.

— jimwise
kaynak

-2

Bu kütüphaneler hiç de modern değil. Bunlar C API'ları ve kötü olanları. Öncülünüz kusurlu.

— DeadMG
kaynak

OpenGL nasıl modern değil?

— James

1

Aslında buna katılıyorum. OpenGL, yönettiği duruma erişim ve manipülasyon modelinin 1990'ların başlarındaki donanıma dayandığı için modern değildir. Belirli bir ünitedeki belirli bir hedefe bir doku bağlamak gibi şeyler yapmak ve VRAM'de kaç dokuya sahip olduğunuzdan bağımsız olarak mevcut olanların sınırlı sayıda olması çok modern değildir.

— user1118321