Существует так называемое кодоэкономичное программирование, заключающееся в том, что в объектный код не включаются лишние процедуры, функции... Я знаю, что для достижения подобной цели есть, например, специальная библиотека для Дельфи.
А почему бы такое же не использовать стандартные библиотеки, на которых получаются толстые программы, а потом убирать из них неиспользуемый код специальной утилью?
для совместимости
ты должен работать в рамках одного стандартного неймспейса
иначе при попытке расширения сторонними разработчиками у них начнётся жопа
так что испрользуешь стандартные библиотеки не меняя интерфейсов стандартных классов
Andreythinking пишет:
Я знаю, что для достижения подобной цели есть, например, специальная библиотека для Дельфи.
Я всегда думал, что убирать из окончательного образа лишний код - функция компоновщика... При чем здесь библиотека - непонятно.
Это актуально со статическими библиотеками. Динамически загружаемые библиотеки особо не исключишь, ибо их и так в образе нет. Разве что можно исключить ссылки на них, если они реально не будут загружаться. Это тоже вроде есть в компоновщиках.
Ragnarok пишет:
Я не совсем понимаю, зачем это вообще нужно.
Есть любители маленьких программ
keal пишет:
Ragnarok пишет:Я не совсем понимаю, зачем это вообще нужно.
Есть любители маленьких программ
"hello world" всегда в цене, да...
keal пишет:
Ragnarok пишет:Я не совсем понимаю, зачем это вообще нужно.
Есть любители маленьких программ
На этот случай есть UPX. 
Извращенцы?
; Пишем сверхмалые приложения на C++ & win32API. Секреты кодинга.
Как и все кулхацкерские программы - наша программа будет консольной, GUI - в отстой.
Пустое окно, сделанное в Дельфи, которое может только менять размер, закрываться, весит 300 к.б. Наверняка, чтобы закодировать такое поведение, требуется информации раз в 10 меньше.
Andreythinking пишет:
Пустое окно, сделанное в Дельфи, которое может только менять размер, закрываться, весит 300 к.б. Наверняка, чтобы закодировать такое поведение, требуется информации раз в 10 меньше.
17кб
Много места в программах занимает кусок кода, вставляемый компилятором для работы с ООП.
Например, имеем два файла:
// 1.cpp
#include <iostream>
int main (void){return 0;}// 2.cpp
int main (void){return 0;}Компилируем их командами
g++ 1.cpp -o 1
g++ 2.cpp -o 2В итоге имеем такие размеры (могут отличаться в зависимости от версии компилятора, дефолтовых настроек и т.д., но тенденция ясна):
файл 1 (в котором упоминается ООП, хоть и не используется) -- 417 кБ,
файл 2 (чистый C без всяких ++) -- 14 кБ.
Хотите экономить каждый байт -- пишите на ассемблере.
А вообще, уменьшить размер помогают утилиты вроде strip (или PEOptimizer под Windows), которые удаляют точки отладки и прочий мусор из исполняемого кода. Ну, и старый добрый upx.
P.S. "strip" и "upx --best" позволили уменьшить размер файла 1 аж до 71 кБ.
Пустое окно, сделанное в Дельфи, которое может только менять размер, закрываться, весит 300 к.б. Наверняка, чтобы закодировать такое поведение, требуется информации раз в 10 меньше.
Требуется гораздо меньше.
На оргиях, помнится, лежала прога с тестом Филатовой. Ее размер (правда, с использованием upx) -- 18 кБ.
Она представляла собой окно с меню. Через меню запускаляся тест из 40 вопросов (текст вопросов и обработка результатов -- в самом exe'шнике). Вопрос -- это текст + 5 кнопок с вариантами ответов.
Кроме того рекомендую посмотреть эту статью: http://en.wikipedia.org/wiki/.kkrieger .
masai пишет:
Требуется гораздо меньше.
На оргиях, помнится, лежала прога с тестом Филатовой. Ее размер (правда, с использованием upx) -- 18 кБ.
Если программа - всего лишь тест, то плюнь на виндоус и пиши в чистом досе. Или в скриптах для браузера.
masai пишет:
Кроме того рекомендую посмотреть эту статью: http://en.wikipedia.org/wiki/.kkrieger
Что за хренотень?
Шутер, занимающий всего
System requirements
1.5GHz Pentium 3 / Athlon or faster
512MB of RAM
GeForce 4Ti (or higher) or ATI Radeon 8500 (or higher) graphics card supporting pixel shader 1.3
DirectSound-compatible sound hardware
DirectX 9.0b
Microsoft Windows
96KB disk space
?
Ну-ну. Вот на моём компе такая игра не пойдёт - исключительно из-за RAM. А диск спейс действительно впечатляющий! Прям как в DOS-играх 1990-го года.
kaprizka пишет:
Если программа - всего лишь тест, то плюнь на виндоус и пиши в чистом досе. Или в скриптах для браузера.
Полностью согласен! Средства должны быть адекватны цели.
Если цель получить маленький код -- можно писать на ассемблере, если цель -- быстро написать тестик для инета -- java или javascript. Если мне потребуется написать программку для замены в кучке текстов числа 12 на число 21, вряд ли я для этого выберу хаскел или Си.
kaprizka пишет:
masai пишет:Кроме того рекомендую посмотреть эту статью: http://en.wikipedia.org/wiki/.kkrieger
Что за хренотень?
Шутер, занимающий всегоSystem requirements
1.5GHz Pentium 3 / Athlon or faster
512MB of RAM
GeForce 4Ti (or higher) or ATI Radeon 8500 (or higher) graphics card supporting pixel shader 1.3
DirectSound-compatible sound hardware
DirectX 9.0b
Microsoft Windows
96KB disk space?
Ну-ну. Вот на моём компе такая игра не пойдёт - исключительно из-за RAM. А диск спейс действительно впечатляющий! Прям как в DOS-играх 1990-го года.
На моем тоже не пошла бы. Поэтому сходил к другу, чтоб посмотреть. Убедился, что все на скриншотах в статье википедии -- это правда.
Может, в ней архивы в оперативную память распаковываются? Этим можно объяснить малый размер на диске и большие требования к RAM.
masai пишет:
В итоге имеем такие размеры (могут отличаться в зависимости от версии компилятора, дефолтовых настроек и т.д., но тенденция ясна):
файл 1 (в котором упоминается ООП, хоть и не используется) -- 417 кБ,
файл 2 (чистый C без всяких ++) -- 14 кБ.
Все конечно зависит от компилятора. Например в gcc 4.1.1 разница в два раза. 5732 байт против 2828.
masai пишет:
Хотите экономить каждый байт -- пишите на ассемблере.
Ну не каждый человек сможет написать код на ассемблере короче и быстрее, чем последние версии gcc.
Andreythinking пишет:
Может, в ней архивы в оперативную память распаковываются? Этим можно объяснить малый размер на диске и большие требования к RAM.
Все текстуры создаются (а не распаковываются) динамически; изображение обрабатывается исключительно видеокартой, причем активно используются шейдеры, что значительно экономит место (и повышает нагрузку); все, что можно -- упаковано и т.д. У них на сайтике где-то было техническое описание.
pax пишет:
masai пишет:Хотите экономить каждый байт -- пишите на ассемблере.
Ну не каждый человек сможет написать код на ассемблере короче и быстрее, чем последние версии gcc.
Што да, то да.