Это хорошая идея, чтобы восстановить заголовки Win32? - PullRequest
7 голосов
/ 27 мая 2011

В последнее время я все больше работаю с кодом C / C ++ для Win32, и, исходя из фона C #, я разработал навязчивую идею «чистого кода», которая полностью согласована, поэтому отходит от прекрасного пространства имен System. *Возвращаясь к путанице #defines, составляющих заголовочные файлы Win32 API, это немного шокирует.

Прочитав алфавитный список основных функций Win32 в MSDN, я понял, насколько на самом деле прост API Win32, иприскорбно, что он окутан всеми событиями последних 25 лет, в том числе многочисленными ссылками на 16-битные программы, которые совершенно неактуальны в современном 64-битном мире.

Я должен начать новый C /Проект C ++ скоро, и я думал о том, как я мог бы воссоздать заголовки Win32 по мере необходимости.Я мог бы сделать его красивым, и все же он поддерживал бы 100% бинарную (и исходную) совместимость с существующими программами (потому что #defines в конечном счете разрешают ту же самую вещь).

Мне было интересно, пытался ли кто-нибудь это сделатьв прошлом (Google ничего не обнаружил), или если кто-то хотел отговорить меня от этого.

Еще одна вещь, о которой я подумал, заключалась в том, как с более чистым C Win32 API становится возможным разработать более чистый и простойиспользовать оболочку C ++ Win32 API поверх, так как не будет никакого загрязнения пространства имен от старых элементов C Win32.

РЕДАКТИРОВАТЬ:

Просто чтобы уточнить, я не делаю это дляулучшить производительность компиляции или для любого вида оптимизации, я полностью осознаю, что компилятор избавляется от всего, что не используется.Мой квест состоит в том, чтобы иметь библиотеку заголовков Win32, с которой приятно работать (потому что мне не нужно нажимать Caps-Lock каждый раз, когда я использую функцию).

Ответы [ 6 ]

10 голосов
/ 27 мая 2011

Не делай этого.

Это может быть возможно, но это займет много времени и, вероятно, приведет к незначительным ошибкам.

Однако, что еще более важно, это сделает вашу программу совершенно невозможной для поддержки кем-либо, кроме вас.

3 голосов
/ 27 мая 2011

Хотя заголовки Win32 можно считать «грязными», вам почти никогда не придется (или не хочется) заглядывать внутрь них. Все, что вам нужно знать, документировано в Win32 SDK. Точное содержимое заголовочных файлов является подробностью реализации.

Там есть тонна вещей, которые будут отнимать много времени и излишне привередливы, особенно в отношении разных версий Win32 SDK.

Я рекомендую:

#include <windows.h>
3 голосов
/ 27 мая 2011

Нет. В чем смысл? Просто включите <windows.h> и определите несколько макросов, таких как WIN32_LEAN_AND_MEAN, VC_EXTRALEAN, NOGDI, NOMINMAX и т. Д., Чтобы исключить то, что вам не нужно / нужно, чтобы ускорить время компиляции.

3 голосов
/ 27 мая 2011

Нет смысла делать это.Тот факт, что существует дополнительный код, не означает, что он скомпилирован в двоичный файл (все неиспользованное будет оптимизировано).Кроме того, в случае КРАЙНЕЙ вероятности того, что что-то меняется (я не знаю, может быть, WM_INPUT меняется число), гораздо проще использовать системные заголовки.Кроме того, что является более интуитивным?Я думаю, #include <windows.h> гораздо проще понять, чем #include "a-windows-of-my-own.h".

Кроме того, честно говоря, вам никогда не нужно даже смотреть на содержимое windows.h.Да, я читал это, да, это ужасно, как грех, но он делает то, что мне нужно, и мне не нужно его поддерживать.

Возможно, ЕДИНСТВЕННЫЙ недостаток использования настоящего windows.h заключается в том, чтоэто МОЖЕТ замедлить компиляцию на несколько миллисекунд.

2 голосов
/ 27 мая 2011

На мой взгляд, это плохая практика.Аккуратность и краткость достигается за счет максимально возможного соблюдения стандартной практики и максимально эффективного использования платформы.Вы должны предположить, что Microsoft обладает исключительным опытом в своей собственной платформе, а некоторые аспекты выходят за рамки того, что вы знаете прямо сейчас.Говоря простыми словами, это их продукт, и они знают лучше.

Свернув свое собственное:

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

Самый элегантный код - это тот, который несет больше LOC реальной программной логики и как можно меньше LOC для «ведения» (т. Е. Кода, не имеющего прямого отношения к поставленной задаче).Не упустите возможность использовать заголовки Platform SDK, чтобы сделать ваш проект более элегантным.

1 голос
/ 27 мая 2011

Это было предпринято в прошлом.

В своем каталоге include, MinGW содержит собственную версию windows.h.Предположительно это существует для того, чтобы заголовки работали с gcc.Я не знаю, будет ли он работать с компилятором Microsoft.

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