приложение win32 не так объектно-ориентировано и почему существует столько указателей?
Это могло бы быть немым вопросом некоторым из Вас, и возможно я задал этот вопрос неправильно, потому что я плохо знаком с C++. Но я замечаю при работе в большом количестве win32 приложений, Вы используете много ресурсов, которые являются указателями. Почему необходимо всегда получать указатель объектов? почему бы не инициировать новый экземпляр класса. и говоря об этом, я замечаю в большинстве случаев, что Вы никогда не инициируете новый объект, но всегда обращаетесь к методам тот возврат тот указатель. Что, если тот указатель используется где-то в другом месте. не могли Вы портить что-то, если Вы изменяете тот указатель, и он используется где-то в другом месте.
9 ответов
Windows API были разработаны для языка C, который был и остается самым используемым языком для системного программирования; C API являются стандартом де-факто для системных API, и по этому почти все другие языки имели и имеют какой-то способ вызова внешних функций C, поэтому написание C API помогает быть совместимым с другими языками.
Для C API нужен простой ABI, который состоит практически только из определения соглашения о вызове функций (и кое-что о компоновке структур). C++ и другие объектно-ориентированные языки, напротив, требуют сложных ABI, которые должны определять, как объекты размещаются в памяти, как обрабатывать наследование, как размещать vtable, как распространять исключения, куда помещать данные RTTI, .... Более того, не все языки являются объектно-ориентированными, и использование API, разработанных для C++, с другими, не объектно-ориентированными языками может оказаться настоящей проблемой (если вы когда-нибудь использовали COM из C, вы понимаете, о чем я).
В качестве отступления, когда Windows была первоначально разработана, C++ не был так широко распространен на ПК, а также C не использовался так много: фактически, большая часть Windows 3.11 и многие приложения все еще были написаны на ассемблере, поскольку ограничения памяти и процессора в ту эпоху были очень жесткими; компиляторы также были менее умными, чем сейчас, особенно C++. На машинах, где ручной ассемблер часто был единственным решением, накладные расходы на C++ были действительно неприемлемы.
По поводу указателей: Windows API почти всегда используют handles, т.е. непрозрачные указатели, чтобы иметь возможность изменять базовую природу каждого ресурса без ущерба для существующих приложений и не давать приложениям возиться с внутренними структурами. Не имеет значения, изменена ли структура, используемая оконным менеджером для внутреннего представления окна: все приложения используют просто HWND, который всегда имеет размер указателя. Вы можете подумать, что это какая-то идиома PIMPL.
Однако Windows в какой-то мере объектно-ориентирована (см., например, всю концепцию "класса окна", или, на более глубоком уровне, внутреннюю работу ядра NT, которая в значительной степени основана на концепции "объекта"), однако ее самые базовые API, будучи простыми функциями C, каким-то образом скрывают эту OO-природу. С другой стороны, оболочка, разработанная много лет спустя, написана в основном на C++ и предоставляет действительно объектно-ориентированный COM-интерфейс.
Интересно, что в COM можно увидеть все компромиссы, с которыми приходится сталкиваться при построении межъязыкового, но все еще ориентированного на C++ объектно-ориентированного интерфейса: результат получается довольно сложным, в некоторых отношениях уродливым и не очень простым для использования из любого языка. API Windows, будучи простыми функциями, в целом более удобны для вызова.
Если вас интересует система, основанная на C++ API, вы можете взглянуть на Haiku; лично для меня это один из аспектов, из-за которого я весьма заинтересован в этом проекте.
Кстати, если вы собираетесь заниматься программированием под Win32 только с помощью API, вам лучше приобрести хорошую книгу, чтобы привыкнуть к этим "особенностям" и другим идиомам Win32. Две известные - это Rector-Newcomer и Petzhold.
Потому что Win32 Api написаны на простом C, а не на C ++. Таким образом, любая программа практически на любом языке может обращаться к этому API.
Кроме того, не существует простого механизма для использования объектов в разных модулях и на разных языках. Т.е. вы не можете экспортировать класс C ++ в python. Конечно, есть технологии, подобные OLE / COM, но они все еще написаны на простом языке C. И их немного сложно использовать.
С другой стороны, вызовы простых функций C стандартизированы. Таким образом, вы можете вызывать подпрограммы из DLL или статической библиотеки на любом языке.
Win32 был разработан для работы с языком C, а не с C++.
Вот почему вы увидите возвращаемые типы, например, BOOL вместо bool.
bool специфичен для C++ и не существует в C.
Об объектно-ориентированной обертке Win32 от Microsoft смотрите MFC.
Более новым фреймворком от Microsoft с тех пор является .Net Framework.
Фреймворк .Net основан на управляемом коде и не работает нативно. Самым современным способом программирования графического интерфейса под Windows является WPF или даже Silverlight.
Наиболее современным способом программирования неуправляемого графического интерфейса является использование MFC, хотя некоторые люди все еще предпочитают использовать прямой Win32.
Обратите внимание, что работа с указателями не является специфической для C, она все еще очень распространена в C++.
Windows API - это старый добрый C, поэтому повсюду используются указатели. Кроме того, причина, по которой вы запрашиваете у Windows новый указатель, заключается в том, что Windows необходимо отслеживать все объекты ... она выделяет объекты и сообщает вам указатель (или иногда просто числовой идентификатор), чтобы вы могли с ними работать.
Первая причина в том, что передача указателей обходится дешево. Указатели имеют размер 4 байта на x86 и 8 байтов на x64. В то время как структура или класс, на который он указывает, могут занимать намного больше в памяти. Таким образом, создание экземпляра класса означает резервирование новой памяти снова и снова. Это неэффективно с точки зрения скорости и потребления памяти.
Другой способ - передать ссылки на объекты, интеллектуальные указатели или аналогичные конструкции. Но win32 api был разработан в эпоху C, так что это то, где он находится до сих пор;)
Что касается потенциальной путаницы с указателями - это, конечно, возможно. Но в большинстве случаев их время жизни явно указано в API (если не очевидно).
- Наличие функций C в качестве API позволяет программистам на C и C ++ использовать его.
- API-интерфейсы Windows восходят к прошлому - C был известен в те дни.
Все HWND, HANDLE, HDC - это всего лишь слабая попытка создать фиксированные объектно-подобные типы данных (с использованием struct ). У C FAQ есть вопросы по этому поводу -> http://c-faq.com/struct/oop.html .
Вероятно, поскольку Win32 API «старше», чем массовое объектно-ориентированное программирование, это не C ++ API по своей сути.
Это похоже на то, что вам следует попробовать одну из многих объектно-ориентированных оболочек. Как MFC или .net.
Чтобы понять указатели, вы можете прочитать учебник CPlusPlus.com по указателям .