История изменений

Ну, в команде с такими как ты я точно не стал бы работать.

Да ты вообще в команде работать не можешь.

Проблемы вызывает расчёт кода на отрицательные числа там, где их быть не должно. И, повторюсь, такие баги я видел (в публичном популярном софте) и не один раз. В том числе и потому, что переполнение signed int наступает в два раза раньше того, что могло бы быть, а unsigned даже если переполнится, то во многих (не во всех - и программист разумеется должен это всё предусматривать) случаях это произойдёт прозрачно и без багов (не надо делать спец. ветки кода для обработки).

Целочисленное переполнение возникает либо из-за неправильной реализации алгоритма, либо из-за недостаточной разрядности числа (и речь вовсе не о недостатке в один сраный бит). Ни в первом ни во втором случае unsigned не является панацеей и нужно либо исправлять алгоритм кода, либо переходить на long или long long (в зависимости от дата модели LP64 или LLP64). Твоё утверждение о том, что целочисленное переполнение unsigned менее болезненно, чем signed - просто враньё.

Ошибки конечно у всех бывают, но сравнивать не надо. Код многократно перепроверяется перед попаданием в рабочую версию.

Ещё как надо сравнивать, потому что в таком лихом и плохочитаемом кода такая бага может сидеть незамеченной годами. Статическую типизацию придумали как раз для выявления как можно большего числа подобных проблем на этапе компиляции, но ты считаешь себя умнее и просто отключаешь надоедливые предупреждения компилятора о несоответствии типов.

Это в дурацком clang-е нельзя. А так, разумеется, можно.

Да что ты говоришь? Ты вообще знаешь, что такое прототип функции в Си? Где находятся прототипы вариантов функции main()?

И разницы вобщем-то никакой - и то и то это всего лишь соглашение с используемой libc.

Ты просто нахально пользуешься отсутствие перегрузки функций в Си. И ты до сих пор не смог внятно объяснить зачем тебе так хочется именно unsigned int argc, что аж зудит.

Если других источников ориентации нет - то остаётся только так, да. Но это ж не всегда так.

Расскажи про свои источники ориентации на unsigned int argc.

Плевать.

Гораздо логичнее плевать на твои странные хотелки.

Тем более что оно не про Си.

А в чём принципиальная разница? В C++ эти типы ведут себя как-то иначе или компилируются в какой-то другой машинный код?

Хорошо, перефразирую - в «win32 native проге с стандартной ms библиотекой есть WinMain и нету main». А entry point не будет ни одно из них. Entry point - в статически слинкованной части rtl, он уже, среди прочего, вызывает одну из этих трёх обычных функций. Да, можно перенастроить линкер чтобы он сделал entry point’ом какую-то самописную функцию, но обычно так не делают. И argc argv ей точно никто не передаст, она должна будет сама их получать с помощью winapi.

Entry Point - это точка входа в код твоего приложения. Если ты написал виндовое приложение на Си, точкой входа может быть один из трёх вариантов, которые я перечислил выше. Какой код инициализации его вызывает никакого значения не имеет. В случае нативного консольного виндового приложения будет вызвана функция инициализации mainCRTStartup, которая вызовет main(). Есть и другие *CRTStartup функции инициализации, вызывающие другие точки входа в приложении на Си.

Ну, в команде с такими как ты я точно не стал бы работать.

Да ты вообще в команде работать не можешь.

Проблемы вызывает расчёт кода на отрицательные числа там, где их быть не должно. И, повторюсь, такие баги я видел (в публичном популярном софте) и не один раз. В том числе и потому, что переполнение signed int наступает в два раза раньше того, что могло бы быть, а unsigned даже если переполнится, то во многих (не во всех - и программист разумеется должен это всё предусматривать) случаях это произойдёт прозрачно и без багов (не надо делать спец. ветки кода для обработки).

Целочисленное переполнение возникает либо из-за неправильной реализации алгоритма, либо из-за недостаточной разрядности числа (и речь вовсе не о недостатке в один сраный бит). Ни в первом ни во втором случае unsigned не является панацеей и нужно либо исправлять алгоритм кода, либо переходить на long или long long (в зависимости от дата модели LP64 или LLP64). Твоё утверждение о том, что целочисленное переполнение unsigned менее болезненно, чем signed - просто враньё.

Ошибки конечно у всех бывают, но сравнивать не надо. Код многократно перепроверяется перед попаданием в рабочую версию.

Ещё как надо сравнивать, потому что в таком лихом и плохочитаемом кода такая бага может сидеть незамеченной годами. Статическую типизацию придумали как раз для выявления как можно большего числа подобных проблем на этапе компиляции, но ты считаешь себя умнее и просто отключаешь надоедливые предупреждения компилятора о несоответствии типов.

Это в дурацком clang-е нельзя. А так, разумеется, можно.

Да что ты говоришь? Ты вообще знаешь, что такое прототип функции в Си? Где находятся прототипы вариантов функции main()?

И разницы вобщем-то никакой - и то и то это всего лишь соглашение с используемой libc.

Ты просто нахально пользуешься отсутствие перегрузки функций в Си. И ты до сих пор не смог внятно объяснить зачем тебе так хочется именно unsigned int argc, что аж зудит.

Если других источников ориентации нет - то остаётся только так, да. Но это ж не всегда так.

Расскажи про свои источники ориентации на unsigned int argc.

Плевать.

Гораздо логичнее плевать на твои странные хотелки.

Тем более что оно не про Си.

А в чём принципиальная разница? В C++ эти типы ведут себя как-то иначе или компилируются в какой-то другой машинный код?

Хорошо, перефразирую - в «win32 native проге с стандартной ms библиотекой есть WinMain и нету main». А entry point не будет ни одно из них. Entry point - в статически слинкованной части rtl, он уже, среди прочего, вызывает одну из этих трёх обычных функций. Да, можно перенастроить линкер чтобы он сделал entry point’ом какую-то самописную функцию, но обычно так не делают. И argc argv ей точно никто не передаст, она должна будет сама их получать с помощью winapi.

Entry Point - это точка входа в код твоего приложения. Если ты написал виндовое приложение на Си, точкой входа может быть один из трёх вариантов, которые я перечислил выше. Какой код инициализации его вызывает никакого значения не имеет. В случае нативного консольного виндового приложения будет вызвана функция инициализации mainCRTStartup, которая вызовет main(). Есть и другие *CRTStartup функции инициализации, вызывающие другие точки входа в приложение на Си.