Сообщение Re[4]: Ненавижу пакетно-ориентированное программирование от 26.09.2025 10:34
Изменено 26.09.2025 10:52 L_G
Re[4]: Ненавижу пакетно-ориентированное программирование
ЕМ>Не. В идеале такой компилятор должен получать на вход исключительно исходники (хотя бы обфусцированные). Обладая должной мощью, он мог бы найти все возможные зависимости (вплоть до динамических), по ним построить граф, и максимально его оптимизировать, а все ненужное выкинуть. Тогда, действительно, из десятка библиотек, по сотне мегабайт каждая, можно будет собрать бинарник в пару десятков килобайт, если его функциональность большего не требует.
Турбопаскаль и Дельфи успешно выкидывали код неиспользуемых процедур/методов без всяких исходников — для построения графа вполне достаточно того, что в объектных файлах и дээлэлках есть ИМЕНА/сигнатуры вызываемых (из них и ими самими) процедур/методов (таблицы импорта/экспорта вроде это называется).
Хотя, возможно, с dll это вовсе не делалось, а с остальным — за счет особого формата библиотек (не сишный obj).
ЕМ>(вплоть до динамических)
А вот с этим — облом! Динамическое компилятору ну никак не проанализировать (без исполнения кода, да и оно не даёт абсолютно никакой гарантии!)
В Дельфи объем экзешников начал "расти как на дрожжах", огорчая минималистов, из-за включения рефлексии, после которой ВСЕ published-методы уже нельзя было выкидывать — а ну как код вызовет их по имени (сформировав само имя динамически e.g. загрузив из файла конфигурации, которого и В ИСХОДНИКАХ-ТО НЕТ или он там другой)
Турбопаскаль и Дельфи успешно выкидывали код неиспользуемых процедур/методов без всяких исходников — для построения графа вполне достаточно того, что в объектных файлах и дээлэлках есть ИМЕНА/сигнатуры вызываемых (из них и ими самими) процедур/методов (таблицы импорта/экспорта вроде это называется).
Хотя, возможно, с dll это вовсе не делалось, а с остальным — за счет особого формата библиотек (не сишный obj).
ЕМ>(вплоть до динамических)
А вот с этим — облом! Динамическое компилятору ну никак не проанализировать (без исполнения кода, да и оно не даёт абсолютно никакой гарантии!)
В Дельфи объем экзешников начал "расти как на дрожжах", огорчая минималистов, из-за включения рефлексии, после которой ВСЕ published-методы уже нельзя было выкидывать — а ну как код вызовет их по имени (сформировав само имя динамически e.g. загрузив из файла конфигурации, которого и В ИСХОДНИКАХ-ТО НЕТ или он там другой)
Re[4]: Ненавижу пакетно-ориентированное программирование
ЕМ>Не. В идеале такой компилятор должен получать на вход исключительно исходники (хотя бы обфусцированные). Обладая должной мощью, он мог бы найти все возможные зависимости (вплоть до динамических), по ним построить граф, и максимально его оптимизировать, а все ненужное выкинуть. Тогда, действительно, из десятка библиотек, по сотне мегабайт каждая, можно будет собрать бинарник в пару десятков килобайт, если его функциональность большего не требует.
Турбопаскаль и Дельфи при компоновке успешно выкидывали код неиспользуемых процедур/методов без всяких исходников — для построения графа вполне достаточно того, что в объектных файлах есть ИМЕНА/сигнатуры вызываемых (из них и ими самими) процедур/методов (что-то типа таблиц импорта/экспорта в dll, но шире).
Возможно, сишный формат obj такое не позволит, но у Борланда был свой.
ЕМ>(вплоть до динамических)
А вот с этим — облом! Динамическое компилятору ну никак не проанализировать (без исполнения кода, да и оно не даёт абсолютно никакой гарантии!)
В Дельфи объем экзешников начал "расти как на дрожжах", огорчая минималистов, из-за включения рефлексии, после которой ВСЕ published-методы уже нельзя было выкидывать — а ну как код вызовет их по имени (сформировав само имя динамически e.g. загрузив из файла конфигурации, которого и В ИСХОДНИКАХ-ТО НЕТ или он там другой)
Турбопаскаль и Дельфи при компоновке успешно выкидывали код неиспользуемых процедур/методов без всяких исходников — для построения графа вполне достаточно того, что в объектных файлах есть ИМЕНА/сигнатуры вызываемых (из них и ими самими) процедур/методов (что-то типа таблиц импорта/экспорта в dll, но шире).
Возможно, сишный формат obj такое не позволит, но у Борланда был свой.
ЕМ>(вплоть до динамических)
А вот с этим — облом! Динамическое компилятору ну никак не проанализировать (без исполнения кода, да и оно не даёт абсолютно никакой гарантии!)
В Дельфи объем экзешников начал "расти как на дрожжах", огорчая минималистов, из-за включения рефлексии, после которой ВСЕ published-методы уже нельзя было выкидывать — а ну как код вызовет их по имени (сформировав само имя динамически e.g. загрузив из файла конфигурации, которого и В ИСХОДНИКАХ-ТО НЕТ или он там другой)