Чому сучасні бібліотеки не використовують OOP

20

Я програміст на рівні початківців C ++, але поняття мови я досить добре розумію. Коли я почав вивчати зовнішні бібліотеки C ++, як-от SDL, OpenGL (можливо, ще щось), на моє велике здивування я виявив, що вони взагалі не використовують поняття C ++.

Наприклад, ні SDL, ні OpenGL не використовують класи або винятки, віддаючи перевагу функціям та кодам помилок. У OpenGL я бачив такі функції, як glVertex2f, який приймає 2 вхідних змінних у якості вхідних даних і, ймовірно, буде кращим як шаблон. Більше того, ці бібліотеки іноді використовують marcos, хоча, мабуть, є загальною згодою, що використання макрозів погано.

Загалом вони, здається, написані більше у стилі C, ніж у стилі C ++. Але вони абсолютно різні незрівнянні мови, чи не так?

Питання: чому сучасні бібліотеки не використовують переваг мови, на якій вони написані?

— Saage
джерело

1

Я думаю, що Тімо добре відповів на ваше запитання. Іншими причинами (для інших бібліотек) може бути бібліотека, яка була створена в C, а потім перенесена. Або розробники C написали це.

— Жанна Боярський

5

Крім того, ні OpenGL, ні «сучасні» в тому сенсі, що вони молоді, або, принаймні, здатні прийняти нові фантазії. Обидва мають тривалу історію (OpenGL 1.1: 1997; SDL: 1998) та обмеження сумісності ззаду назад.

1

Просто так сказано: DirectX набагато об'єктивніший (якщо ще й трохи нижчий).

— cHao

1

Рідні C ++ бібліотеки, такі як stl та Boost, також не використовують хитрі, застарілі, непотрібні концепції OOP.

— SK-логіка

5

Я думаю, що ваше помилкове уявлення тут полягає в тому, що SDL і OpenGL є репрезентативними для багатьох "сучасних бібліотек". Наприклад, дуже популярна бібліотека Qt повністю орієнтована на об'єкти. Назви вашого питання краще мати "Чому SDL і OpenGL не використовують OOP"?

— Док Браун

31

І OpenGL, і SDL - це бібліотеки C і відкривають інтерфейс C для решти країн світу (як і майже кожна мова там, може працювати з C, але не обов'язково з C ++). Таким чином, вони обмежені процедурним інтерфейсом, який C дає вам та способу декларування та використання структур даних.

Окрім аспекту "взаємодії з іншими мовами", який пропонує інтерфейс C, C, як правило, є трохи більш портативним, ніж C ++, що, в свою чергу, полегшує отримання не залежної від платформи частини коду бібліотек як, наприклад, що працюють в іншій ОС або архітектурі обладнання. Практично на кожній платформі є гідний компілятор C, але все ж є такі, які обмежили компілятори C ++ або такі, які просто не дуже хороші.

Хоча C і C ++ є дуже різними мовами, вони не є "несумісними", насправді значною мірою C ++ є сукупністю C. Є деякі несумісності, але не багато, тому використовувати інтерфейс C від C ++ - дуже легка річ зробити.

— Тімо Геш
джерело

О Я бачу. Ну, наступне питання: чи є, скажімо, бібліотека графіки для C ++ настільки ефективною, як OpenGL? Чи, можливо, обгортка над OpenGL, яка використовує всі переваги C ++ та забезпечує гарне управління ресурсами? API виглядатимуть набагато чистіше, і я не думаю, що накладні витрати на пам'ять / процесор будуть занадто високими.

— Саге

Ефективна чи ефективна? У будь-якому випадку, слід досить легко знайти обгортку C ++ для SDL або OpenGL. Швидкий Google підніс цю обгортку для OpenGL: oglplus.org - не маю уявлення, наскільки це добре, я не використовував його.

— Тімо Геш

1

Так, є досить багато проектів, які намагаються обернути OpenGL більше інтерфейсів C ++ ish (у мене навіть є сам, хоча я утримуюсь від багатьох функцій і в основному додаю перевантаження і подібне). Моє враження, що більшість додають багато багажу, що ускладнює переклад чистих фрагментів OpenGL і складніше застосовувати стандартні оптимізації (шукайте Дизайн, орієнтований на дані; деякі ігрові розробники клянуться ним). Але в жодному разі не дозволяйте цьому стримувати вас. Крім того, ви можете мати більше шансів використовувати цілий ігровий механізм (наприклад, Irrlicht або Ogre), а не просто графічний API з голими кістками.

Добре, я думаю, що у мене є всі відповіді, які я шукав. Дякую всім!

— Саге

Слід також зазначити, що графічне обладнання не розуміє і не виконує обчислень на заняттях. У вас є float3s, тому що все обладнання, що стосується, це масиви поплавків. Структура "класу" (поняття про те, що вектор дорівнює 2, 3 або 4 плаває) - це все мається на увазі в тому, як картці пропонується отримати доступ до своєї маси пам'яті. Можливо, приємно спробувати і подумати на заняттях при програмуванні графіки, але, на мій погляд, така робота досить близька до апаратних засобів, що це більше клопоту, ніж допомоги для вилучення брудних деталей реалізації.

— Девід Кауден

10

Думаю, ви плутаєте "написання бібліотеки" проти "експонування API зовні". Я не знаю багато конкретно про згадані вами бібліотеки (вони можуть бути написані внутрішньо на C), але я знаю, що багато інших, в тому числі я, написали бібліотеки / рамки С ++, які повністю використовували всі види фантазійних практик / моделей OOP , але все-таки піддаються API стилю C у зовнішньому світі.

C і C ++ - не зовсім різні системи. C ++ був побудований поверх C і a) може легко споживати код C і b) повністю здатний надати apis у стилі C.
Перевагою інтерфейсу С є те, що він дуже легко витрачається рештою світу. Є шари interop, які дозволяють використовувати API API майже з будь-якої мови (python, java, c #, php ...), де інтерфейс C ++ є споживчим з ..... ну, можливо, C ++ і все ще не завжди ( різні компілятори, різні версії одного компілятора спричинять проблеми)

Раніше, в якості експерименту в одному з робочих проектів, я вирішив відкрити інтерфейс "OO" з DLL C ++. Щоб приховати внутрішні деталі та уникнути купу інших речей, я майже закінчив винаходити Windows COM (компонентну об’єктну модель). Після цього проекту я зрозумів, що COM не такий вже й поганий, як це роблять люди, тому що а) він відкриває інтерфейси OOP, б) піклується про всі проблеми, в які я зіткнувся, і в) достатньо стандартний, щоб витрачати його на ряд інші мови.

Але COM все ще не обходиться без багажу. У багатьох випадках регулярний API в стилі C все ще є значно кращою альтернативою.

— DXM
джерело

7

І OpenGL, і SDL - це бібліотеки C, а не C ++. Ви можете використовувати їх із C ++, але вони написані на C та мають API API (який також доступний з інших мов; C ++ - це біль для доступу через FFI). Погляньте на Boost для великого масиву бібліотек C ++ загального призначення (та деяких спеціалізованих) бібліотек C ++ та SFML для мультимедійної бібліотеки C ++.

3

Якщо говорити саме про OpenGL, OpenGL спочатку був частиною стеку API - OpenGL забезпечував API низького рівня, орієнтований на продуктивність, доступний з C (або навіть Fortran), тоді як OpenInventor забезпечує об'єктно-орієнтований API високого рівня, розроблений використовувати з C ++ і надавати як графічний інтерфейс API високого рівня, так і абстракції для збереження / читання сцен у / з файлів та інтеграцію графічного інтерфейсу.

Нарешті, OpenGL пішов набагато далі, ніж OpenInventor (це наполягало на більш гострій потребі, даючи виробникам відео обладнання, для чого можна оптимізувати, і надаючи звичайним API низького рівня, щоб люди могли орієнтуватися замість того, щоб безпосередньо займатися обладнанням для прискорення 3D). Але OpenInventor все ще є там, і є хороша реалізація з відкритим кодом - Coin3D - з підтримкою Unix / X11, Windows та MacOS X / Cocoa.

— jimwise
джерело

-2

Ці бібліотеки зовсім не сучасні. Вони є API API і погані. Ваше приміщення є недоліком.

— DeadMG
джерело

Як OpenGL не є сучасним?

— Джеймс

1

Я б насправді мав би з цим погодитися. OpenGL не є сучасною, оскільки його модель доступу та маніпулювання станом, яким він керує, базується на апаратних засобах початку 1990-х. Виконувати такі речі, як прив’язання текстури до певної цілі на певному блоці, і лише обмежена кількість доступних незалежно від того, скільки текстур у вас в VRAM, не дуже сучасно.

— користувач1118321