Объясните, почему в winapi — stdcall? Я понимаю, в принципе, разницу между stdcall и cdecl, но видимо не очень... Видимо это вызвано чем то, что так принято?

Здравствуйте, __INFINITE, Вы писали:

__I>Объясните, почему в winapi — stdcall? Я понимаю, в принципе, разницу между stdcall и cdecl, но видимо не очень... Видимо это вызвано чем то, что так принято?

Исторически сложилось. На x86 — stdcall чуть дешевле, чем cdecl:
stdcall: в функции — ret N (2 байта)
cdecl: в функции — ret (1 байт) + всюду, где эта функция вызывается — add sp,N (3 байта).

Здравствуйте, __INFINITE, Вы писали:

__I>Объясните, почему в winapi — stdcall? Я понимаю, в принципе, разницу между stdcall и cdecl, но видимо не очень... Видимо это вызвано чем то, что так принято?

Вот еще кое-что от товарища Ларри Остермана:

And the cdecl calling convention is possibly the worst of the x86 calling conventions (pascal might be worse). The biggest problem with cdecl is that the caller has to clean up the stack. When the NT kernel was changed from being cdecl to stdcall, we literally shrunk the size of the kernel binary by more than 10%. Code compiled with stdcall also executes faster than cdecl because it executes fewer instructions (this may no longer be as significant but it can add up).

Правда, я немного удивлен выделенным фрагментом. Всегда думал, что stdcall и pascal — одно и то же. И не совсем согласен по поводу бесполезности cdecl. Мне она нравится больше даже кое-чем: изменение стека в части параметров производится в одном месте и крайне трудно огрести из-за несогласованности стека, что очень просто при stdcall, если на стек положили неверное число параметров.

Здравствуйте, Alex Alexandrov, Вы писали:

AA>

AA>And the cdecl calling convention is possibly the worst of the x86 calling conventions (pascal might be worse). The biggest problem with cdecl is that the caller has to clean up the stack. When the NT kernel was changed from being cdecl to stdcall, we literally shrunk the size of the kernel binary by more than 10%. Code compiled with stdcall also executes faster than cdecl because it executes fewer instructions (this may no longer be as significant but it can add up).

AA>Правда, я немного удивлен выделенным фрагментом. Всегда думал, что stdcall и pascal — одно и то же. И не совсем согласен по поводу бесполезности cdecl. Мне она нравится больше даже кое-чем: изменение стека в части параметров производится в одном месте и крайне трудно огрести из-за несогласованности стека, что очень просто при stdcall, если на стек положили неверное число параметров.

Тут фишка вот в чём. В Паскале (под Дос) было принято класть на стек сперва левый аргумент, потом следующий и т.д.

А в Си — сперва правый. При этом, если стек растёт вниз, адреса аргументов расположены по возрастающей. И кроме того, конвенция cdecl (с переменным числом параметров) отличается от stdcall лишь способом очистки стека, но не его заполнением и доступом.

cdecl — родная для Си конвенция ещё со времён K&R, когда на прототипы функций можно было забить.
stdcall — "экономичная" по памяти.
pascal — родная для Паскаля.

В Win16 конвенция pascal была волевым образом приведена к stdcall (а не наоборот). По всей видимости, чтобы можно было на паскале под винды (TPW, BP7, микрософтовские поделки) по-человечески указывать прототипы винапишных функций.

---

А насчёт того, какая конвенция более ударопрочная... так ведь стек можно ухайдокать самыми разными способами. Да и вызов функции с меньшим, чем нужно, числом параметров — может запросто привести к расстрелу. Ни cdecl, ни stdcall не спасут.