Приложение win32 не настолько объектно-ориентировано, и почему существует так много указателей? - PullRequest
8 голосов
/ 25 февраля 2010

Это может быть глупый вопрос для некоторых из вас, и, возможно, я задал этот вопрос неправильно, потому что я новичок в c ++. Но я замечаю, что при работе во многих приложениях win32 вы используете много ресурсов, которые являются указателями. Почему вы всегда должны получить указатель на объекты? почему бы не инициировать новый экземпляр класса. и говоря об этом, я замечаю, что в большинстве случаев вы никогда не инициируете новый объект, но всегда вызываете методы, которые возвращают этот указатель. Что делать, если этот указатель используется где-то еще. не могли бы вы что-то испортить, если вы измените этот указатель, и он используется где-то еще.

Ответы [ 9 ]

25 голосов
/ 25 февраля 2010

Windows API были разработаны для C, который был и остается наиболее используемым языком для системного программирования; API C являются де-факто стандартом для системных API, и для этого почти во всех других языках есть и есть способ вызывать внешние функции C, поэтому написание C API помогает быть совместимым с другими языками.

API C требуется простой ABI, состоящий почти из определения соглашения о вызовах для использования в функциях (и кое-что о структуре структур). C ++ и другие объектно-ориентированные языки, напротив, требуют сложного ABI, который должен определять, как объекты размещаются в памяти, как обрабатывать наследование, как планировать виртуальную таблицу, как распространять исключения, куда помещать данные RTTI, ... Более того, не все языки являются объектно-ориентированными, и использование API-интерфейсов, предназначенных для C ++, с другими необъектно-ориентированными языками может быть настоящей болью (если вы когда-либо использовали COM из C, вы понимаете, о чем я).

Кроме того, когда изначально Windows разрабатывался, C ++ не был так широко распространен на ПК, а также C не использовался , поэтому много: на самом деле, большая часть Windows 3.11 и многие приложения все еще были написано на ассемблере, так как ограничения памяти и процессора в эпоху были очень жесткими; компиляторы также были менее умными, чем сейчас, особенно C ++. На машинах, где ручная сборка часто была единственным решением, накладные расходы C ++ были действительно неприемлемы.

Что касается указателей: в Windows API почти всегда используются дескрипторы , то есть непрозрачные указатели, чтобы иметь возможность изменять базовый характер каждого ресурса, не затрагивая существующие приложения, и не допускать, чтобы приложения возились с внутренними структур. Не имеет значения, если структура, используемая диспетчером окон для внутреннего представления окна, изменена: все приложения используют просто HWND, который всегда имеет размер указателя. Вы можете думать об этом как о какой-то идиоме PIMPL.

Однако Windows в некотором роде объектно-ориентирована (см., Например, всю концепцию "класса окна" или, на более глубоком уровне, внутреннюю работу ядра NT, которая в значительной степени основана на концепции "объекта"). ), однако его основные API, будучи простыми функциями C, каким-то образом скрывают эту ОО-природу. С другой стороны, оболочка, разработанная много лет спустя, написана в основном на C ++ и предоставляет действительно объектно-ориентированный COM-интерфейс.

Интересно, что в COM вы можете увидеть все компромиссы, с которыми вам придется столкнуться при построении кросс-языкового, но все еще смещенного объектно-ориентированного интерфейса в C ++: результат довольно сложный, в некоторых отношениях уродливый и не очень простой в использовании из любых язык. API-интерфейсы Windows, будучи простыми функциями, обычно легче вызывать.

Если вас интересует система, основанная на C ++ API, вы можете взглянуть на Haiku ; лично это один из аспектов, из-за которого я очень заинтересован в этом проекте.

Кстати, если вы собираетесь заниматься программированием на Win32 только с помощью API, вам лучше получить хорошую книгу, чтобы привыкнуть к этим «особенностям» и другим идиомам Win32. Двумя известными из них являются Ректор-новичок и Петжольд .

7 голосов
/ 25 февраля 2010

Потому что Win32 Api написаны на простом C, а не C ++.Таким образом, любая программа практически на любом языке может вызывать эти API.

Кроме того, не существует простого механизма использования объектов в разных модулях, а есть разные языки.Т.е. вы не можете экспортировать класс C ++ в python.Конечно, есть технологии, такие как OLE / COM, но они все еще написаны на простом C. И их немного сложно использовать.

С другой стороны - вызовы простых функций C стандартизированы.Таким образом, вы можете вызывать подпрограммы из DLL или статической библиотеки на любом языке.

5 голосов
/ 25 февраля 2010

Win32 был разработан для работы с языком C, а не C ++.
Вот почему вы увидите типы возвращаемых значений, например, BOOL вместо bool.
bool относится к C ++ и не существует в C.

Для объектно-ориентированной оболочки Microsoft Win32 см. MFC .

Более новой платформой от Microsoft с тех пор является .Net Framework.
Платформа .Net основана на управляемом коде, хотя и не работает изначально. Самый современный способ программирования GUI в Windows - это WPF или даже Silverlight.

Самый современный способ неуправляемого программирования с использованием графического интерфейса пользователя по-прежнему заключается в использовании MFC, хотя некоторые люди все еще предпочитают использовать прямой Win32.

Обратите внимание, что работа с указателями не является специфической для C, она все еще очень распространена в C ++.

4 голосов
/ 25 февраля 2010

Первая причина в том, что указатели обходятся дешево. Указатели имеют размер 4 байта на x86 и 8 байтов на x64. Хотя структура или класс, на которые он указывает, могут занимать намного больше памяти. Таким образом, создание экземпляра класса означает резервирование новой памяти снова и снова. Это не эффективно с точки зрения скорости и потребления памяти.

Другой способ - передать ссылки на объекты, умные указатели или аналогичные конструкции. Но Win32 API был разработан в эпоху C, так что это то, где он до сих пор;)

Что касается возможной путаницы с указателями - конечно, это возможно. Но в большинстве случаев их время жизни явно указано в API (если не очевидно).

1 голос
/ 25 февраля 2010

Вероятно, потому что Win32 API "старше", чем основное объектно-ориентированное программирование, это не API C ++ по своей сути.

0 голосов
/ 25 февраля 2010
  • Наличие функций C в качестве API позволяет программистам на C и C ++ использовать его.
  • Windows API уходят в далекое прошлое - в те дни С был знаменит.

Все HWND, HANDLE, HDC - лишь слабая попытка создать фиксированные объектно-подобные типы данных (используя struct). C FAQ есть вопрос по этому вопросу -> http://c -faq.com / struct / oop.html .

0 голосов
/ 25 февраля 2010

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

0 голосов
/ 25 февраля 2010

Это почти как вы должны попробовать один из множества OO-оболочек. Как MFC или .net.

0 голосов
/ 25 февраля 2010

Чтобы понять указатели, вы можете прочитать руководство по CPlusPlus.com по указателям .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...