Поставил Go ... скомпилил на нем ХеллВорд. exe файл вывалил 2 мб Они там что рехнулись ? Почему он такой огромный ???
Сборщик мусора, куча RTTI-таблиц, которые нужны просто для всего в языке. Чего ты хотел то? Ну и пореж отладочную информацию, будет порядка мегабайта.
Не умеет как С/С++ в оптимизацию, отключая в коде всё, что не используется. Ну делфи так делал, правда в компактный код его тоже можно.
С учетом удешевления дискового пространства и увеличения скорости интернета это как 200кб 10 лет назад . Ну а если при компиляции выкинуть отладочную информацию то еще процентов 30 можно выиграть.
Открой в IDA Pro и убедись, что нет то что и много. Вопрос тут не в том, что компилятор Го не умеет в DCE, а в том, что у Го слишком жирный рантайм, большая часть которого написано на самом языке: жир, требующий жира сам по себе.
С++ тоже не умеет (сюрприз!). Просто его STL преимущественно не объектно-ориентированная библиотека и на ней можно не заметить 30 лет уже как реалий современного мира. Хотя даже STL заметно набивает бинарник чем то новым в немалом количестве по сравнению с Си. И достаточно взять какой-нибудь Qt чтобы бинарник набух виртуальными функциями. Проблема реализации ООП в том, что нельзя гарантировать, что виртуальная функция не используется чтобы стрипнуть её из образа - т.к. разорвана прямая связь между адресом функции и её использованием в коде через индекс в virtual table. В классическом стриппере упоминание конструктора любого класса метит virtual table самого класса и всех его наследников как используемые - все указатели на виртуальные функции в них соответственно тоже метятся как использованные, поэтому всё дерево классов и их виртуальных функций от этого корня и вверх метится как используемое неважно было ли в коде реальное использование всех этих функций. Более того это ключ к работе динамически подгружаемые плагинов, поэтому стрипать просто нельзя если мы хотим такую плюшку, а мы её нередко хотим. Но это полбеды - в по настоящему адекватных тех же GUI-библиотеках будет присутствовать код по, например, динамическому реконструированию облака объектов - например загрузки кнопок и прочих контролов в окне из какого нибудь mainForm.xml файла. А вот это уже ад для стриппера, потому что там будет каким то образом протащены конструкторы всех потенциально возможных контролов через createControl(char *className, ...) - эта функция при любом использовании сразу же затянет всё облако классов в бинарник без возможности стрипнуть любые виртуальные функции которые в свою очередь потащат и все (или почти все) невиртуальные (иначе зачем они были нужны?). Более того - для облегчения написания такой функции и лёгкостью дополнения облака классов новыми чаще всего используется принцип авторегистрации когда при подключении модуля а-ля "кнопки" регистрация конструктора (фабрики) происходит в глобальном конструкторе/секции инициализации и необходимо и достаточно только лишь подключить модуль к системе сборки чтобы все его ООП-классы попали в бинарник без возможности стрипнуть. Не нужно даже самому вызывать конструктор кнопки - она всё-равно автоматом попадёт в сборку. Белые проблемы белых людей. --- Сообщение объединено, 27 мар 2024 --- P.S. "virtual table самого класса и всех его наследников" читать как "virtual table самого класса и всех его предков"
так если прикинуть - 10_000 вирт фунок по 100 байт в среднем, даже 1М не получается в объёме, а ещё можно отметить, что рантайм не обязан грузится одним куском, тч и в стрипах особой-то надобности нет. ЗЫ.. 100 байт взял, чтоб прям наглядно
https://flattened.net/ - просто оставлю это здесь, если вам иди (го) слишком жирно, то попробуйте шарпов, может, содержание жиров там придется вам по вкусу.
для всё-в-одном гуй бинаря 20М - очень скромный размерчик даже по меркам нулевых и ежли там от силы наберётся 100 килов на вирт функи - уже хорошо
