Mengapa perpustakaan modern tidak menggunakan OOP


20

Saya seorang programmer C ++ tingkat pemula, tapi saya mengerti konsep bahasa dengan cukup baik. Ketika saya mulai belajar perpustakaan C ++ eksternal, seperti SDL, OpenGL (mungkin sesuatu yang lain juga), saya sangat terkejut ketika mengetahui bahwa mereka tidak menggunakan konsep C ++ sama sekali.

Misalnya, SDL, atau OpenGL tidak menggunakan kelas atau pengecualian, lebih memilih fungsi dan kode kesalahan. Di OpenGL saya telah melihat fungsi seperti glVertex2f, yang mengambil 2 variabel float sebagai input dan mungkin akan lebih baik sebagai templat. Selain itu, pustaka-pustaka ini terkadang menggunakan marcos, sementara itu tampaknya menjadi kesepakatan umum bahwa menggunakan macroses adalah buruk.

Semua dalam semua, mereka tampaknya lebih ditulis dalam gaya C, daripada dalam gaya C ++. Tapi mereka benar-benar bahasa yang tidak dapat ditoleransi, bukan?

Pertanyaannya adalah: mengapa perpustakaan modern tidak menggunakan kelebihan dari bahasa yang mereka tulis?


1
Saya pikir Timo menjawab pertanyaan Anda dengan baik. Alasan lain (untuk pustaka lain) bisa menjadi pustaka yang dibuat di C dan kemudian porting. Atau pengembang C menulisnya.
Jeanne Boyarsky

5
Selain itu, baik OpenGL maupun "modern" dalam arti bahwa mereka masih muda, atau setidaknya mampu mengadopsi faetures baru yang mewah. Keduanya memiliki sejarah panjang (OpenGL 1.1: 1997; SDL: 1998) dan kendala kompatibilitas ke belakang.

1
Begitulah katanya: DirectX jauh lebih objektif (jika juga sedikit lebih rendah tingkat).
cao

1
Pustaka C ++ asli, seperti stl dan Boost, tidak menggunakan konsep OOP yang jelek, ketinggalan jaman, tidak berguna juga.
SK-logic

5
Saya pikir kesalahpahaman Anda di sini adalah bahwa SDL dan OpenGL mewakili banyak "perpustakaan modern". Pustaka Qt yang sangat populer, misalnya, sepenuhnya berorientasi objek. Judul pertanyaan Anda sebaiknya "Mengapa tidak SDL dan OpenGL menggunakan OOP"?
Doc Brown

Jawaban:


31

Baik OpenGL dan SDL adalah pustaka C dan mengekspos antarmuka C ke seluruh dunia (karena hampir semua bahasa di luar sana dapat berinteraksi dengan C tetapi tidak harus dengan C ++). Dengan demikian, mereka terbatas pada antarmuka prosedural yang C berikan kepada Anda dan cara C untuk mendeklarasikan dan menggunakan struktur data.

Di atas dan di atas "berinteraksi dengan bahasa lain" yang ditawarkan oleh antarmuka C, C secara umum cenderung sedikit lebih portabel daripada C ++, yang pada gilirannya membuatnya lebih mudah untuk mendapatkan bagian yang tidak tergantung platform dari kode perpustakaan. seperti ini bekerja pada OS lain atau arsitektur perangkat keras. Hampir semua platform di luar sana memiliki kompiler C yang layak, tetapi masih ada beberapa yang telah membatasi kompiler C ++ atau yang tidak begitu bagus.

Sementara C dan C ++ adalah bahasa yang sangat berbeda, mereka bukan "tidak kompatibel", pada kenyataannya, sebagian besar C ++ adalah superset dari C. Ada beberapa ketidakcocokan tetapi tidak banyak, jadi menggunakan antarmuka C dari C ++ adalah hal yang sangat mudah melakukan.


Oh begitu. Nah, pertanyaan selanjutnya kemudian: apakah ada, katakanlah, perpustakaan grafis untuk C ++ seefektif OpenGL? Atau mungkin pembungkus OpenGL yang menggunakan semua keunggulan C ++ dan menyediakan manajemen sumber daya yang baik? API akan terlihat jauh lebih bersih, dan saya tidak berpikir memori / cpu overhead akan terlalu tinggi.
Penghematan

Efektif atau efisien? Either way, itu seharusnya cukup mudah untuk menemukan pembungkus C ++ untuk SDL atau OpenGL. Google cepat membuka pembungkus ini untuk OpenGL: oglplus.org - tidak tahu seberapa bagus itu, saya belum menggunakannya.
Timo Geusch

1
Ya, ada beberapa proyek yang mencoba untuk membungkus OpenGL dengan lebih banyak antarmuka C ++ ish (saya bahkan punya satu, meskipun saya menahan diri dari banyak fitur dan kebanyakan menambahkan kelebihan beban dan semacamnya). Kesan saya adalah bahwa kebanyakan menambahkan banyak bagasi yang membuatnya lebih sulit untuk menerjemahkan cuplikan OpenGL murni dan lebih sulit untuk menerapkan optimasi standar (lihat Desain Berorientasi Data; beberapa game bersumpah dengan itu). Tapi jangan biarkan itu menghalangi Anda. Sebagai alternatif, Anda mungkin lebih beruntung menggunakan seluruh mesin permainan (seperti Irrlicht atau Ogre) daripada hanya menggunakan API grafis sederhana.

Baiklah, saya pikir saya memiliki semua jawaban yang saya cari. Terimakasih semuanya!
Penghematan

Juga harus dicatat bahwa perangkat keras grafis tidak mengerti atau melakukan perhitungan pada kelas. Anda memiliki float3s karena semua perangkat keras yang bersangkutan adalah array float. Struktur "kelas" (gagasan bahwa vektor adalah 2, 3, atau 4 mengapung) semuanya tersirat dalam cara kartu diperintahkan untuk mengakses tumpukan memori. Mungkin menyenangkan untuk mencoba dan berpikir di kelas ketika memprogram grafik, tetapi menurut saya, jenis pekerjaan itu cukup dekat dengan perangkat keras sehingga lebih merepotkan daripada membantu untuk menghilangkan detail kotor dari implementasi.
David Cowden

10

Saya pikir Anda bingung "menulis perpustakaan" vs. "mengekspos API ke luar". Saya tidak tahu banyak tentang perpustakaan yang Anda sebutkan (mungkin ditulis secara internal dalam bahasa C), tetapi saya tahu banyak yang lain, termasuk saya sendiri, telah menulis perpustakaan C ++ / kerangka kerja yang sepenuhnya memanfaatkan semua jenis praktik / pola OOP yang mewah , tetapi masih mengekspos API gaya-C ke dunia luar.

  1. C dan C ++ bukan sistem yang sepenuhnya berbeda. C ++ dibangun di atas C dan a) dapat dengan mudah mengkonsumsi kode C dan b) sepenuhnya mampu menyediakan apis C-style.
  2. Keuntungan dari antarmuka C adalah sangat mudah dikonsumsi oleh seluruh dunia. Ada lapisan interop yang memungkinkan C API untuk dikonsumsi dari hampir semua bahasa (python, java, c #, php ...), di mana sebagai antarmuka C ++ dapat dikonsumsi dari ..... well, mungkin C ++ dan masih tidak selalu ( kompiler berbeda, versi berbeda dari kompiler yang sama akan menyebabkan masalah)

Di masa lalu, sebagai percobaan di salah satu proyek di tempat kerja, saya memutuskan untuk mengekspos antarmuka "OO" dari C ++ DLL. Untuk menyembunyikan detail internal dan menghindari banyak hal lain, saya hampir akhirnya menemukan kembali COM Windows (model objek komponen). Setelah proyek itu, saya menyadari COM tidak seburuk orang yang melakukannya karena a) memperlihatkan antarmuka OOP, b) mengurus semua masalah yang saya hadapi dan c) cukup standar untuk dapat dikonsumsi dari sejumlah bahasa lainnya.

Tapi COM masih tidak tanpa bagasi. Dalam banyak kasus, reguler, paket C-style API masih merupakan alternatif yang jauh lebih baik.


7

OpenGL dan SDL keduanya adalah pustaka C, bukan pustaka C ++. Anda dapat menggunakannya dari C ++, tetapi ditulis dalam C dan memiliki API C (yang juga dapat diakses dari bahasa lain; C ++ sulit diakses melalui FFI). Lihatlah Boost untuk sejumlah besar pustaka C ++ tujuan umum (dan beberapa khusus) dan SFML untuk pustaka multimedia C ++.


3

Berbicara kepada OpenGL secara khusus, OpenGL pada awalnya adalah bagian dari setumpuk API - OpenGL menyediakan API tingkat rendah, berorientasi kinerja, dapat diakses dari C (atau bahkan Fortran), sementara OpenInventor menyediakan API berorientasi objek tingkat tinggi, dirancang untuk digunakan dari C ++, dan menyediakan API adegan-grafik tingkat tinggi, dan abstraksi untuk menyimpan / membaca adegan ke / dari file, dan integrasi GUI.

OpenGL akhirnya menjadi lebih jauh daripada OpenInventor (ini memenuhi kebutuhan yang lebih mendesak, memberi pembuat perangkat keras video sesuatu untuk dioptimalkan, dan memberikan API umum tingkat rendah yang bisa ditargetkan orang daripada berurusan dengan perangkat keras akselerasi 3D secara langsung). Tetapi OpenInventor masih ada di sana, dan ada implementasi open source yang bagus - Coin3D - dengan dukungan untuk Unix / X11, Windows, dan MacOS X / Cocoa.


-2

Perpustakaan-perpustakaan itu sama sekali tidak modern sama sekali. Mereka adalah API C, dan yang buruk itu. Premis Anda cacat.


Bagaimana OpenGL tidak modern?
James

1
Saya sebenarnya harus setuju dengan ini. OpenGL tidak modern dalam hal modelnya untuk mengakses dan memanipulasi keadaan yang dikelolanya didasarkan pada perangkat keras sejak awal 1990-an. Harus melakukan hal-hal seperti mengikat tekstur ke target tertentu pada unit tertentu, dan hanya memiliki jumlah terbatas yang tersedia terlepas dari berapa banyak tekstur yang Anda miliki di VRAM tidak terlalu modern.
user1118321
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.