Почему многие оконные менеджеры не поддерживают ориентацию объектов?

0

Примечание. Я сделал короткий поиск, который появился с небольшим количеством результатов, единственным действительно важным результатом является этот, поэтому я не думаю, что это было полностью задано раньше.

В последнее время я занимаюсь разработкой ОС, и обнаружил, что большинство, если не все, не имеют полностью объектно-ориентированных интерфейсов оконных приложений, включая Windows. Это, конечно, с заметным исключением интерпретируемых байткодом языков, таких как С# (или CLI вообще) и Java. (Чтобы уточнить, я имею в виду, что они имеют тенденцию создавать окно через функцию, а не через создание класса).

Я могу понять меньших менеджеров, сделанных для простоты, таких как tinywm, но даже более крупные оконные менеджеры, такие как MetaCity, Fluxbox и Openbox, по-прежнему не из объектов, а скорее из функций, несмотря на то, что некоторые из них написаны в C++ до чистого C (по крайней мере, насколько я понимаю).

Это может быть наивный вопрос, но почему это делается так? Я понимаю, что важно реализовать не-объектно-ориентированный ABI для языков, не поддерживающих ориентацию объектов, но почему он не может также обеспечить крючки более высокого уровня для языков, поддерживающих ориентацию объектов?

Не было бы легче, если программист, в конце концов, имел бы такие крючки, потому что это облегчило бы разработку программного обеспечения? Учитывая прогресс в оборудовании, потеря производительности не была бы минимальной по сравнению с преимуществами того, насколько проще было бы разработать?

Это было просто что-то, что меня било, и я надеюсь, что у кого-то будет ответ.

PS: Если мое понимание в корне неверно, не стесняйтесь меня исправлять.

  • 3
    Хех, Win32 API был написан на чистом C, а затем были предоставлены объектно-ориентированные хуки. Теперь эта библиотека на основе хуков называется «MFC», и если вы когда-либо делали MFC, то вы, сэр, знаете, что это за ошибка.
  • 0
    Я не знал, что MFC считается объектно-ориентированным, потому что он содержит так много макросов и необъектных функций
Показать ещё 2 комментария
Теги:
operating-system
window-managers

2 ответа

3

Это не просто окно. Не существует операционных систем, которые имеют object- ориентированные API в терминах методов, вызываемых через объекты, как в myObject->method() или myObject.method(). Большинство из тех, которые мы используем, теперь имеют API-интерфейсы окон, разработанные в начале 1980-х годов (например, Windows X Window System и т.д.). Есть вопросы, касающиеся языка и ABI. Единственное исключение, о котором я могу думать, это OS/2 независимая от языка OO вещь, называемая System Object Model.

Формально говоря, нет никакой разницы между method(object,...) и object.method(...) или object->method(...), просто синтаксической разницей.

Поделиться
1

Я думаю, что вы можете быть в чем-то принципиально неправильным, но это неловкий способ сказать это. :)

Менеджеры окон обычно ориентированы на объекты, но они не предназначены для классов и объектов, как вы можете найти в C++. То, что у вас есть, - это нечто вроде:

struct Object {
  ...
};

void DoSomething(Object* obj, ...);

Все функции, предоставляемые диспетчером окон, управляют внутренними элементами объекта, будь то кнопка, окно или какой-либо другой виджет. В большинстве случаев программист должен обрабатывать эти объекты непрозрачно и позволить API управлять своим содержимым. Как программист, вы все еще работаете с объектами и методами на этих объектах. Это просто то, что большая часть мутации сломана, и не похоже, что люди ожидают, что объектно-ориентированное программирование будет выглядеть, потому что объекты являются параметрами функций, а не функциями, являющимися свойствами объектов.

Поделиться
  • 0
    Я думал, что структуры не рассматриваются объектами так же, как структуры классов, потому что они не могут содержать методы? Возможно, я просто слишком сильно сравниваю генерацию / создание окон с Java-разработкой, но я считаю, что создание приложений из классов намного более интуитивно понятно, чем наличие ряда функций / дескрипторов / макросов для их обработки.
  • 0
    В C ++ единственное различие между struct и class состоит в том, что видимость struct умолчанию является public а class private . В структурах C вы не получаете функции-члены. Функции-члены C ++ обычно в конечном итоге вызывают что-то для myobj->DoSomething(...) которое будет выглядеть как MyObject::DoSomething(myobj, ...) , с переменными класса, связанными в локальной области видимости. Фактическое расположение данных в памяти для структур и классов в значительной степени идентично. Нет никакой реальной причины говорить, что вещь типа структуры не является объектом. Все сводится к синтаксису вызова.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню