Что лучше объявить для соглашения о вызовах программы Windows?

Я прочитал статью о Calling convention (__stdcall, __fastcall, паскаль, cdecl и т. д …)

И мне любопытно: Почему часто __stdcall (WinAPI) объявляется для функции WinMain ()?

Пока я читаю, __stdcall работает со стеком, __fastcall работает с регистрами и не использует стек вообще.

Итак, я пытался объявить WinMain () с __fastcall, Компилятор (Visual C ++) выдал мне ошибку.

error C2373: 'WinMain' : redefinition; different type modifiers
c:\program files\microsoft sdks\windows\v6.0a\include\winbase.h(2560) : see declaration of 'WinMain'

Почему я не могу использовать __fastcall для WinMain () и есть ли возможность использовать его для этого?

Потому что работать с регистрами без использования стека намного быстрее, не так ли?

PS
Мое предложение состоит в том, что есть некоторые контракты метода, которые запрещают мне использовать __fastcall, но это только мое предложение.

1

Решение

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

Кстати, вы бы ничего не выиграли, если бы (win-) main имел конвенцию fastcall, поскольку она вызывается только один раз!
Вы могли бы рассмотреть быстрый вызов для функций со многими небольшими параметрами (которые вписываются в регистры), которые очень часто вызываются в течение длительных периодов времени.

Процедура запуска (buildin) для программ Windows будет вызывать либо WinMain, либо main (в зависимости от графического интерфейса или консольного приложения) с определенным соглашением.
Если вы пишете WinMain или main с другим соглашением, то компоновщик будет жаловаться.

1

Другие решения

WinMain должно быть __stdcall, Он вызывается кодом запуска CRT, который уже создан для передачи параметров способом, определяемым __stdcall условность.

0

По вопросам рекламы [email protected]