Почему современные библиотеки не используют ООП

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 гораздо более объектный (хотя и немного более низкоуровневый).

— Чао

1

Собственные библиотеки C ++, такие как stl и Boost, также не используют дрянные, устаревшие и бесполезные концепции ООП.

— SK-logic

5

Я думаю, что вы ошибаетесь в том, что SDL и OpenGL являются репрезентативными для многих "современных библиотек". Например, очень популярная библиотека Qt полностью объектно-ориентирована. Название вашего вопроса должно быть лучше «Почему SDL и OpenGL не используют ООП»?

— Док Браун

31

И OpenGL, и SDL являются библиотеками C и предоставляют интерфейс 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 ++ (у меня даже есть один, хотя я воздерживаюсь от многих функций и в основном добавляю перегрузки и тому подобное). У меня сложилось впечатление, что большинство из них добавляет много багажа, что затрудняет как перевод чистых фрагментов OpenGL, так и применение стандартных оптимизаций (посмотрите на Data-Oriented Design; некоторые разработчики игр клянутся этим). Но ни в коем случае не позволяйте этому сдерживать вас. В качестве альтернативы вам может повезти больше, если использовать весь игровой движок (например, Irrlicht или Ogre), а не просто графический API-интерфейс.

Хорошо, я думаю, что у меня есть все ответы, которые я искал. Спасибо всем!

— Саж

Следует также отметить, что графическое оборудование не понимает и не выполняет вычисления на классах. У вас есть float3s, потому что все, что касается оборудования, это массивы с плавающей точкой. Структура «класс» (представление о том, что вектор равен 2, 3 или 4 числам с плавающей запятой) неявно связана с тем, как карта получает доступ к своей памяти. Возможно, было бы неплохо подумать на уроках при программировании графики, но, на мой взгляд, такая работа достаточно близка к аппаратному обеспечению, так что это скорее хлопот, чем помощь для отвлечения грязных деталей реализации.

— Дэвид Кауден

10

Я думаю, что вы путаете «написание библиотеки» с «разоблачением API извне». Я не особо разбираюсь в библиотеках, о которых вы упомянули (они могут быть написаны для внутреннего использования в C), но я знаю, что многие другие, включая меня, написали библиотеки / фреймворки C ++, в которых в полной мере использовались все виды причудливых практик / шаблонов ООП. , но все же выставил API в стиле C для внешнего мира.

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

В прошлом, в качестве эксперимента в одном из проектов на работе, я решил выставить «OO» интерфейс из C ++ DLL. Чтобы скрыть внутренние детали и избежать множества других вещей, я чуть не перестроил Windows COM (компонентную объектную модель). После этого проекта я понял, что COM не так плох, как это делают люди, потому что а) он предоставляет интерфейсы ООП, б) заботится обо всех проблемах, с которыми я столкнулся, и в) является достаточно стандартным, чтобы его можно было использовать из ряда Другие языки.

Но COM все еще не без своего багажа. Во многих случаях обычный API плана в стиле C все еще является гораздо лучшей альтернативой.

— DXM
источник

7

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

3

Говоря конкретно об OpenGL, OpenGL изначально был частью стека API - OpenGL предоставлял низкоуровневый, ориентированный на производительность API, доступный из C (или даже Fortran), в то время как OpenInventor предоставляет высокоуровневый объектно-ориентированный API, разработанный для использования с C ++, предоставляя как высокоуровневый API графов сцен, так и абстракции для сохранения / чтения сцен в / из файлов, а также интеграцию с GUI.

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

— jimwise
источник

-2

Эти библиотеки совсем не современны. Это API-интерфейсы C, причем плохие. Ваша предпосылка ошибочна.

— DeadMG
источник

Чем OpenGL не современен?

— Джеймс

1

Я бы на самом деле должен был согласиться с этим. OpenGL не является современным в том, что его модель доступа и управления состоянием, которым он управляет, основана на аппаратных средствах с начала 1990-х годов. Необходимость делать такие вещи, как привязка текстуры к определенной цели на определенном юните, и иметь только ограниченное количество доступных вне зависимости от того, сколько текстур у вас в VRAM, не очень современно.

— user1118321