вообще то у теперяшных VS CRT весит примерно 75 кило. у VS6 был примерно на 40-50 кило.


Это не диагноз.
ясень пень что такое 20 мб по сравнению с террабайтом, но все это загрузиться в ОЗУ которое винда превратит в 40 мб в памяти.

Это сообщение отредактировал(а) Dem_max - 12.7.2010, 10:49

У меня 2 ГБ. Сейчас это уже мало считается. Но я и с 2 ГБ ОЗУ не переживаю за 40 МБ. 

Таки диагноз.  

А я переживаю, у меня каждая прога на компе пытается насрать куда угодно, при этом при автозагрузке запуститься, запустить дочерний процесс и радостно работать в скрытом режиме иногда давая понять что есть обновления. итого считаем 20 процессов по 40 мб это 800 мб, практически гиг. А при хибернейте это радостно начинает сохраняться на винт. 

терабайтные винчи, гигабайтное ОЗУ - это не повод делать программы хуже, чем 10 лет назад, без какой-либо на то причины.

писать проги-спутники-обновлялки которые висят в памяти и жрут 40Мб это PI.....
имхо человек который занимается не разработкой, а оптимизацией размеров программы....занимается не тем


ЗЫ тема авно, автор похож на троля

kemiisto, размер это иногда скорость. А скорость это то, собственно для чего и нужен С++. Представь систему с плагинами, которых может быть порядка 10ти и каждый будет при загрузке инициализировать всякую муть, из которой реально нужно 5%. Загрузка приложения заметно замедлиться. 

Плагины это вовсе не плохо, плагины  (как отдельные DLL, так и другие форматы) собственно и придумывались с учетом того чтобы главное приложение не тянула в память все не нужные в данный момент функции, а при необходимости подгружала плагины и выгружала их при ненадобности.  К тому же загрузка главного приложения может ускориться.

А оптимизация по коду, по размеру должна применять уже в готовом релизе, а не на стадии написания программы.

Это сообщение отредактировал(а) Dem_max - 12.7.2010, 11:25

Ржунимагу над неосилятором гцц, молящемся на мсвц.^W^W^W^W^W^W^W^W^W^WНет, я отвечу в еще более наивно-идиотичной манере, чем половина этого топика.

Проблема не в гцц, а в венде! Только что скомпилировал плюсовый хелловорлд, получил пять с небольшим килобайт бинарника. Могу сократить до менее килобайта. Наверное все дело в рулезной операционке, а никак не в чьих-то кривых руках и нежелании читать маны.

ТС, не парься, считай это нормальным. Это маленький оверхед, незаметный на фоне конечной реальной программы.

djamshud, вот смотри: одна ОС, два компилятора.
Оба компилят один и тот же исходник - получаются разные размеры исполняемых файлов. Как так?
Отладочная и прочая служебная информация? Нет. Там разные размеры секций кода.

Добавлено через 5 минут и 56 секунд

очевидно проблема в реализации гцц под винду.

btw, код с аналогичной функциональностью на асме, скомпилится байт в 600, с учетом 512б выравнивания секций.

С опцией -static?  

P.S. Правда, в нынешних условях "проблема" действительно ломаного гроша не стоит.

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

Это сообщение отредактировал(а) djamshud - 13.7.2010, 10:25

djamshud, я открывал его в IDA и смотрел что там. Это было сделано в 1ю очередь, чтобы понять почему там такой размер. Достаточно посмотреть на граф вызовов, чтобы понять, что там нереально много кода, который в самом деле вызывается.

Почему-то мне кажется, что вы, djamshud, никогда не использовали IDA. При этом пытаетесь что-то говорить про машинный код.
Кроме того, вы не понимаете что значит "расковырять бинарник" и "выкинуть все лишнее".

Добавлено через 5 минут и 41 секунду
Если в кратце, то main() компилится примерно одинаково. Проблема в том как компилится STL. Я не знаю, дело ли в отсутствии должной оптимизации, или еще и в изначально плохом труднооптимизируемом коде STL. 
В любом случае, STL - это часть реализации языка в компиляторе. А оптимизатор должен справляться и со сложным кодом.

Abyx, есть мнение, что в винде гцц линкует свой СТЛ статически, а отсюда и размер. Расковыренный бинарник это покажет, и если это подтвердится, не вижу проблемы выкинуть лишнее и прилинковать динамически.

Лично я не вижу совершенно никакой связи между "дело ли в отсутствии должной оптимизации, или еще и в изначально плохом труднооптимизируемом коде STL" и размером бинарника. И самое главное, оба "вывода" совершенно беспочвенны.

djamshud, если вы потрудитесь почитать тему, то вы увидите, что речь только статической линковке, и у гцц и у мсвц.
Замена статической линковки на динамическую - это не вариант, когда нужна статическая. Кроме того, это еще больше раздувает размер проги, из за мертвого кода. Очевидно, что в винде ни у кого нет рантайма гцц, так что нельзя сказать что это позволит уменьшить размер проги.

Алсо, при так называемой "статической" линковке, гцц использует msvcrt.dll o_O 

Это сообщение отредактировал(а) Abyx - 14.7.2010, 12:02

Abyx, окей, статическая, так статическая. Расскажите про "мертвый код", появляющийся при динамической линковке и почему у меня его нет? Почему вы отождествляете размер скомпилированной гцц-шной СТЛ с ее неэффективностью? (Как правило как раз наоборот имеет место быть конкуренция между эффективностью и размером, то есть либо одно, либо другое, либо некий компромисс, но не все сразу).