Mercury13

Подозреваю, что объявление функции после вызова разрешили, потому что оно достаточно легко реализуемо, но даёт изрядную свободу прогеру. Например: несколько открытых конструкторов вызывают private init(), а этот init, как и все скрытые методы, сидит где-то в конце.

Проходов компиляции может быть много — например, сначала мы говорим, что f(x) — это вызов, а вторым проходом определяем, с какой функцией f имеем дело. К тому же конкретно в Си++ любой код в теле класса — автоматический inline, то есть не создаёт кода, пока кто-то снаружи не вызовет.

Умножение, приведение типа или ещё какая-то дрянь — это особенность метода разбора. Во многих языках, в том числе в Паскале, используется LL-разбор — сканирование слева направо, опознание слева направо. Ошибки наподобие «ожидалась точка с запятой» — это артефакт примитивных LL-анализаторов. В Си используется LR-разбор — сканирование слева направо, опознание справа налево, а ожидающие опознания лексемы хранятся в стеке.

И вообще, если пишете собственный крайне специализированный язык, делайте его LL(1), это очень упростит разбор.

Кстати, в Паскале принят обратный порядок видимости: private → protected → public → published. Последнее — поле доступно в рефлексии времени выполнения.

Что тогда делают? Есть три варианта.
1. Перейти на кроссплатформенную библиотеку (Qt, например).
2. Наладить свою небольшую библиотеку, которая когда-нибудь станет кроссплатформенной.
3. Наладить механизм псевдонимов.
Эти варианты можно объединять: что-то перевести на другую библиотеку, что-то написать своё.

Примеры из личного кода.

ОДИН. Ну, например, собственные механизмы работы с путями к файлам потихоньку уходят в сторону std::filesystem::path.

ДВА. Ну, допустим, сделал свою библиотеку доступа к файлам — бонуса три. 1) Есть функции вроде writeIW (Intel word). 2) Проще писать свои абстрактные потоки, чем с std. 3) Феноменальная скорость под Windows (использует нечастый, но быстрый overlapped API с двойной буферизацией). На остальных ОС — обычная обёртка над FILE*.

ТРИ. std::random_device из MinGW 9 давал детерминированную последовательность. Потом попытался бросить эту обходную ветку, но кто-то из программистов пожаловался — на его машине r_d просто не инициализировался.

#if defined(__MINGW32__) && defined(__GNUC__) && !defined(__clang__)

    #define MINGW_RANDOM_DEVICE_WORKAROUND

    class MingwRandomDevice {};  // куча WinApi, опустим
#else //defined(__MINGW32__) && defined(__GNUC__) && !defined(__clang__)
    #include <random>
    using MingwRandomDevice = std::random_device;
#endif //defined(__MINGW32__) && defined(__GNUC__) && !defined(__clang__)

Раз у вас stdlib.h закомментирован, вы, наверно, знаете, откуда malloc взялся. Попробуем раскрутить ошибки.

note: include ‘ stdlib.h ’ or provide a declaration of ‘malloc’
Компилятор, очевидно, знает, где этот malloc завалялся…

warning: implicit declaration of function ‘malloc’ [-Wimplicit-function-declaration]
…но неявно объявляет функцию.

warning: incompatible implicit declaration of built-in function ‘malloc’
Неявное определение int* malloc(int). Реальное void* malloc(size_t). Преобразовать (int*)malloc надо было.

Почему всё-таки запустилось? А потому, что на целевой машине size_t = unsigned int, а размеры указателей совпадают практически всегда. После того, как функция неявно объявилась, линкер подцепил на её место стандартную, и соглашения вызова совпали.

Всё, что я знаю: GCC — самый «въедливый» компилятор. После Intel и Embarcadero (про M$ не знаю) на «зашаблоненном» коде GCC найдёт ещё два десятка ошибок.