Доброго дня, 

дано :

Eclipse IDE for C/C++ Developers

Version: Helios Release
Build id: 20100617-1415

и 



итог :
размер exe - ка ~ 500Кб

чего так много-то ? или это есть нормально ? 

http://www.mingw.org/wiki/Large_executables

потому что гцц - гуан*. это никак не лечится, ~200Кб это минимум для любых прог, никакие -s не помогут. 
там просто нет нормальной оптимизации.

Добавлено через 3 минуты и 44 секунды
самое забавное, что под виндой гцц юзает msvcrt.dll, и всеравно выдает .exe по 500Кб,
тогда как msvc компилит тот же код в 100Кб, при статической компиляции.

Это сообщение отредактировал(а) Abyx - 12.7.2010, 08:06

иди убейся   


так и должно быть.


а какое отношение имеет теплое к мягкому?  


ню-ню  
доказательства где?

Добавлено @ 09:45
а вообще, тему нужно переместить в "GNU Toolchain"

Добавлено через 2 минуты и 22 секунды

тут все расписано. от чего, и почему.

Это сообщение отредактировал(а) boostcoder - 12.7.2010, 09:46

boostcoder, ололо да вы прямо молитесь на свой гцц


что тут доказывать? не верите что бывают хеллоуворлды размером 100Кб?
да... наверное если вы всегда юзаете гцц, то таких не видели...


там не написано почему у msvc получаются исполняемые файлы в 5 раз меньше

  Активно мусорит в экзешник RTTI, кроме того всяческие рантаймы т.д. Это все разовые расходы. Всяческие ембедид системы имеют опцию отключения RTTI + exceptions . Это заметно уменьшает стартовый размер. Кроме того здорово раздувают код шаблоны.
  Если вы не пишете для ембедид систем, то размеры до 1 Мб и даже более не должны смущать. Вон QT вообще тянет за собой ~5Мб рантаймов. 

для тех кто никогда не видел msvc, в нем это делается так...
запускаем msvs2010, новый проект, С++, консольное приложение, ставим галку [v] пустой проект, добавляем файл main.cpp, печатаем код

выбираем опции компиляции "релиз", лезем в свойства проекта, выставляем статическую линковку рантайма, жмем "построить"
получаем .exe размером 96.5Кб, импортирует только kernel32.dll

M bsa

Abyx, хватит троллить.

Поди запусти свой студиевский экзешник на чистой машине, выяснится, что ему еще и redistributable package нужен...

Alexeis, в msvc тоже есть RTTI, статический (!) рантайм, шаблоны, а код (sic!) в 5 раз меньше, что там не так?

Добавлено через 34 секунды
bsa, читайте внимательно.

Ы  откуда такие сведения?


а что это?

Насчет размеров файлов. Кроме embedded систем, есть еще частое обновление модулей программ по сети, а кое-где бывает не безлимитный интернет.
Кроме того некоторые заказчики не могут понять, почему когда им делают формочки на дельфи, получаются .exe по 50Кб, а когда я им делаю проги без ГУЙ на С++ - 500Кб.

  Ну и что радости? Как начнешь писать хоть что-то мало мальски приличное так экзешник раздуется ацки. Подключи MFC и сразу все станает на свои места  . Подключишь что нить другое результат аналогичный. А вот если совсем отключить все рантаймы и линковать голый экзешник так вообще можно получить 5 кб   . Какая экономия! А главное польза  .

Добавлено через 2 минуты и 33 секунды

  Только при компиляции с пакетами (или альтернативные GUI библиотеки). Иначе 600-800 кб. Там еще больше запихано RTTI . Наверное на 300-350 кб. 

Alexeis, пока речь о конкретном коде, который использует только iostream
размер mfc vs размер qt - это отдельный разговор, не в пользу qt

Abyx, мде сейчас проверил. Откомпилировал свою функционально-законченную dll ку (VS2005) static multithread Runtime в релизе - 108 кб - Debug > 900Кб. Однако! Действительно. Вполне себе рабочий проект даже с одной простенькой формочкой. 

В эпоху террабайтных носителей продолжаем фапать на килобайтные хелловорды!?  Это диагноз.

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

он есть. таскайте динамический рантайм вместе с программой - тот код рантайма который программа не использует - будет мертвым по определению.

кроме того, динамический рантайм может не давать оптимизатору его инлайнить.


вы похоже не понимаете как делается оптимизация за счет увеличения размера.

>он есть. таскайте динамический рантайм вместе с программой - тот код рантайма который программа не использует - будет мертвым по определению.

Ясно, опять ни о чем. Открою вам маленький секрет: такскать с собой динамические библиотеки - некомильфо, dll hell во все поля.

>вы похоже не понимаете как делается оптимизация за счет увеличения размера.

Ох ты ж, держитеменясемерошестеронеудержат. Я умиляюсь вашему прфессионализму, которого пока хватает лишь на то, чтобы рассказывать, чего я не понимаю.

Навскидку, вот что я вижу в размерах stl:
- общий код, вкомпилированный в либу, а не вынесеный наружу через хедеры
- вкомпилированные специализации темплейтов под некоторые типы
- использование внутренних статических хешей для каких-то структур данных

Выкидываем пункты 2 и 3, получаем маленькую, но донельзя тупую stl. Выкидываем кучу кода наружу (пункт 1), получаем жирный софт, в который дорая часть stl-я и вкомпилируется.

што? каких хешей? каких данных?

мы о статической линковке говорим или нет?!!!!
что значит "вкомпилированные в либу"? какая еще либа в бинарнике при статической линковке либы с исходниками?
весь бинарник должен быть оптимизирован целиком,
все что не используется - выкидывается,
все что используется 1-2 раза - должно быть заинлайнено и оптимизировано с остальным кодом

для кода в 1м посте в бинарнике вообще практически ничего не должно остаться от STL

Добавлено через 13 минут и 9 секунд
что вообще означает "Выкидываем кучу кода наружу" ?
куда наружу? 

у компилятора есть сорцы STL, не только заголовочных файлов, но и .cpp
во время кодогенерации он должен использовать сорцы stl чтобы инлайнить их в пользовательский код.
отдельно что-то компилится только в случае множественного использования большого куска кода, или когда компилятор не может определить цепочку вызовов, например изза вызовов виртуальных методов через указатель на базовый класс.

в результате инлайна могут получаться функции размером в десятки килобайт %)

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

>што? каких хешей? каких данных?

Ну да. Навскидку, я ж предупреждал.

>мы о статической линковке говорим или нет?!!!!

OMG. Меня плющит, по привычке опять на динамическую перескочил.

>куда наружу?

Я имел в виду (говоря про динамическую линковку), что куча всего, реализованного в .h библиотеки в конечном счете попадет в программу, а не в бинарник самой либы.

Сейчас собрал полностью (libc и libstdc++) статический бинарник хелловорлда в метр с лишним... objdump показал около 5000 использованных символов... Изучением графа вызовов займусь в свободное время. Еще раз навскидку есть предположение, что гцц запихал в бинарь то, что необходимо не только main-у, а всему iostream-у и всему, что он использует (ибо он подключен в исходный файл программы и естественно компилируется).