Размер exe-шника С/С++ - и Pascal

← →
Psychedelic © (2007-02-08 20:09) [40]

> p.p.s. понимай все буквально, без "двойных смыслов", будет
> легче. ("будь проще, и люди к тебе потянутся...")

Спасибо поучение. Я подумаю.

P.s. столько учителей развелось...

← →
ANTPro © (2007-02-08 21:00) [41]

> [19] Psychedelic © (08.02.07 17:14)
> Откуда такая информация? В своих словах вы уверены на 100
> %?
> Объясните. Или укажите источник. Или может вы в Borland"e
> работатете?

Это просто вечный боян : )

Юзать KOL или не юзать решать тебе. Меня KOL для простеньких приложений вполне устраивает. Быстро, просто, качественно, еще и размер не большой.

← →
GrayFace © (2007-02-08 22:04) [42]

REA (08.02.07 13:16) [16]
Хотя со ссылками на run-time функции классов и хранением строк в Unicod без необходимости они и правда погорячились...
Кто?

Psychedelic © (08.02.07 18:29) [26]
Ведь скорость и качество - это основные пункты в программировании.
Качество и функциональность. Скорость относится к качеству, там, где она нужна. Малый размер - тоже, только где он нужен похоже никто не знает.
Только при чем тут скорость? У KOL свой компиллятор?

Psychedelic © (08.02.07 18:29) [26]
Ps. Убрать Object? Вы представляете что тогда будет с Delphi и с совместимостью с проектами? Врядли компания пойдет на создание убытка для своих клиентов.
В object и так глючат property (должны ли они работать не знаю, но компилятор послушно генерит неправильный код), но никто вроде не жалуется.

← →
ZiTRaX © (2007-02-08 22:12) [43]

С ехе-шником в 2кб разобрался. Я просто вообще не то скачивал - привык, что ссылки идут в конце статьи, а не в начале, и скачал исходники Landscape. Вот что бывает из-за невнимательности. Но там есть один минус - используются посторонние утилиты (максимум, что мне позволено - это использовать изменённые модули).

Просто тестирование моего задания будет выполняться так: я приношу свои наработки (*.pas-, *.c/*.cpp- *.rc-файлы), оформленные в виде проектов. Проекты билдятся, а затем запускаются на чистой машине (свежеустановленная WinXP+SP2). Если "приложение" запустилось, то я молодец, иначе "иди и ищи ошибки". Ну и ещё там важна минимальность ехе-шника (чем меньше, тем лучше). Потом будет анализ дизассемблированного листинга с целью нахождения "лишних" участков asm-кода. Вот такая вот фигня! Зачем оно надо, я не знаю. Но надо. Поэтому глупый вопросик: какой из перечисленных в моём первом посте компиляторов создаст самый минимальный ехе-шник простейшего WinAPI-окна с выполнением перечисленных выше условий.

P.S. И ещё: чтобы в ВСВ получить нормально работающий ехе-шник, нужно только убрать галочки с "Build with runtime packages" и "Use dynamic RTL" (отладочную информацию я убираю)? Или что-то ещё? И какие файлы считаются dynamic RTL?
//................................................................................ .....................
Всем ещё раз спасибо!!!

← →
ferr © (2007-02-08 22:16) [44]

Ты не поверишь, обойтись без вставки доп информации можно в ассемблере. Если нужен другой путь то есть идея кому-нибудь кого-нибудь убить, любым способом.

← →
GrayFace © (2007-02-08 22:16) [45]

А нет, все-таки нашелся пример, когда малый размер имеет значение.

← →
ZiTRaX © (2007-02-08 22:23) [46]

Удалено модератором
Примечание: Создание пустых сообщений

← →
ANTPro © (2007-02-08 22:31) [47]

> [42] GrayFace © (08.02.07 22:04)
> Только при чем тут скорость? У KOL свой компиллятор?

У KOL есть дефайн ASM_VERSION

← →
homm © (2007-02-09 00:01) [48]

> какой из перечисленных в моём первом посте компиляторов
> создаст самый минимальный ехе-шник простейшего WinAPI-окна
> с выполнением перечисленных выше условий.

На седьмой студии (Визуал которая) 1кб (1024б) делал. Меньше ТОЛЬКО с помощью сторонних утилит. Меньше нельзя, таков формат win23 PE файлов, генерируемых любым нормальным компилятором. STFW libctiny

← →
GrayFace © (2007-02-09 01:06) [49]

ANTPro © (08.02.07 22:31) [47]
У KOL есть дефайн ASM_VERSION
Он включает Асм-версии его функций? Дак в Delphi тоже многие функции на уровне Асма оптимизированы. А, по меньшей мере, 95% кода в оптимизации не нуждаются.

← →
GrayFace © (2007-02-09 01:08) [50]

Хотя попадаются и функции типа StringReplace, которая убога по оптимальности, хотя должна бы быть оптимизирована.

← →
Германн © (2007-02-09 02:23) [51]

Удалено модератором
Примечание: И не цитируем

← →
Игорь Шевченко © (2007-02-09 10:04) [52]

Psychedelic © (08.02.07 18:29) [26]

> Ого, ну и программисты у нас. Оказыватеся те кто программирует
> на Delphi должен осваивать новые технологии. Новые!

Правильные у нас программисты. Программисты, промежду прочим, если не для собственного развлечения, пишут программы для того, чтобы они людям пользу приносили. А для того, чтобы программы пользу приносили, основные усилия должны быть направлены не на уменьшение размеров программы, а на ее функциональные возможности. И на понятный код, в том числе, для целей сопровождения.

> Ну а если чел умеет бросать только компоненты на форму (это
> к вам не относиться - это вобщем) , а у нас в основном таких
> "программистов" завались (об этом уже говорили - обговаривали,
> - ведро на рубль ), то конечно для него это будет довольно
> трудновато.
>
> А что плохого когда имеем RAD средство

Так бросание компонентов - это и есть основное преимущество RAD-средства, там первая буква обозначает Rapid, чем меньше программист будет заботиться о неотносящихся к основной цели программы моментах, тем быстрее и качественнее будет создана его программа.

> Ps. Убрать Object? Вы представляете что тогда будет с Delphi
> и с совместимостью с проектами? Врядли компания пойдет на
> создание убытка для своих клиентов.

Э...клиентов, использующих object, сдается мне, не так уж много по сравнению с неиспользующими...

> Вы поймите врядли это было бы развлечением. Посмотрите на
> маштабы.
> Написано большое поднможесто компонент, Книга, участвуют
> люди не только из России . Вложено много труда и времени.
>

Давай не будем говорить о масштабах. Масштабы использования VCL просто несравнимы. А уж книг написано - не счесть, один Архангельский целую полку в книжном магазине занимает, и это капля в море.
А то, что труда вложено - вложено, не спорю. Вот есть некий AlvaroGP, часто бывающий в Борландовских конференциях, так он тоже много времени вкладывает в то, чтобы сделать быстрозапускающуюся среду (Delphi имеется в виду) - но толк от его усилий пропадает с каждой новой версией Delphi.

> KOL это тоже делфи, это не другой язык.
> Каждое средство для чего то нужно, для разных задач.

А можно узнать, для чего нужна KOL ?

← →
evvcom © (2007-02-09 11:25) [53]

> [33] DevilDevil © (08.02.07 19:23)
> зато в плане возможностей языка, С++ безусловно будет выше Delphi

Когда я в институте изучал Си после Паскаля, я тоже думал, что Си имеет больше возможностей. Потом эти возможности я увидел и в Паскале (Delphi). Может я сильно отстал, и в Си действительно появились какие-то возможности, которых нет в Паскале, тогда прошу привести их, хотя бы 2-3. Обсудим.

> [43] ZiTRaX © (08.02.07 22:12)
> Потом будет анализ дизассемблированного листинга с целью
> нахождения "лишних" участков asm-кода.

Это ж какому идиоту может придти в голову делать анализ дизассемблированного листинга с ЯВУ при приеме лабы/контрольной/курсача/диплома? Пусть даже это 2-3 кБ! Это анализ не на 5-10 минут.

← →
sabu (2007-02-09 11:32) [54]

evvcom © (09.02.07 11:25) [53]

>Когда я в институте изучал Си после Паскаля, я тоже думал, что Си имеет больше возможностей. Потом эти возможности я увидел и в Паскале (Delphi). Может я сильно отстал, и в Си действительно появились какие-то возможности, которых нет в Паскале, тогда прошу привести их, хотя бы 2-3. Обсудим.

Например, в паскале нельзя перегрузить оператор (), а оператор -> который в c++ тоже можно перегрузить, в нем в принципе отсутствует.

Пожалуйста ознакомьтесь с книгой Modern C++ Design, и поработайте с библиотекой boost.

← →
Игорь Шевченко © (2007-02-09 11:38) [55]

sabu (09.02.07 11:32) [54]

> оператор -> который в c++ тоже можно перегрузить, в нем
> в принципе отсутствует.

да, он называется ^, что не является принципиальным отсутствием.

Книжка по паскалю - тоже рулез немеряный

← →
sabu (2007-02-09 11:41) [56]

Игорь Шевченко © (09.02.07 11:38) [55]

Мне это известно :).
Я к тому, существуют ли смарт поинтеры в паскале или нет?

← →
evvcom © (2007-02-09 11:42) [57]

> [54] sabu (09.02.07 11:32)
> в паскале нельзя перегрузить оператор (),

В Паскале вообще нет перегрузки операторов. А оно это надо? "()" - это типа оператор расстановки приоритетов? Ну и что будет, если ты перегрузишь этот "оператор"? Ты поменяешь привычный его смысл, перевернешь все с ног на голову, а это уже зло.

> а оператор -> который в c++ тоже можно перегрузить, в нем
> в принципе отсутствует

Это, AFAIK, доступ к полям, методам класса/объекта? Если так, то почему ж отсутствует?

Я не говорю о тех или иных символах, которые обозначают те самые "возможности". Я говорю именно о возможности получить тот же самый результат при тех же самых входных данных. Предупрежу сразу заявы типа "а такого ?: оператора тоже в Паскале нет!" Отвечу, оператора - да, нет такого, но возможность есть!

← →
KSergey © (2007-02-09 11:48) [58]

> evvcom © (09.02.07 11:25) [53]
> Может я сильно отстал, и
> в Си действительно появились какие-то возможности, которых
> нет в Паскале, тогда прошу привести их, хотя бы 2-3. Обсудим.
>

Вопрос очень больной, понятно, так что давайте будет корректны хотя бы в терминах.
Имеется в виду С или С++? Это ведь два совершенно разных языка.

> sabu (09.02.07 11:32) [54]
> Например, в паскале нельзя перегрузить оператор ()

А разве в Delphi Language вообще можно перегрузить хоть один оператор? Или жисть не стоит на месте и я бесконечно отстал?

> Игорь Шевченко © (09.02.07 11:38) [55]
> sabu (09.02.07 11:32) [54]
>
>
sabu> оператор -> который в c++ тоже можно перегрузить, в нем
sabu> в принципе отсутствует.
>
> да, он называется ^, что не является принципиальным отсутствием.
>
> Книжка по паскалю - тоже рулез немеряный

Ээээ Игорь, вы ничего не путаете?
Оператор -> в Delphi в принципе не нужен, т.к. там все ссылки на объект есть указатели, так что странно говорить об отсутсвии чего-либо (да еще и как минус), елси это что-либо в принципе не имеет смысла.

← →
sabu (2007-02-09 11:49) [59]

evvcom © (09.02.07 11:42) [57]

Смотрите глубже.
Важно не само наличие возможности перегрузки оператора, а то какие возможности дает эта перегрузка.
Например, возможность перегрузки оператора () позволяет создавать функторы - функции, имеющие состояния. Кроме того, эта возможность позволяет использовать функторы как аргументы шаблонов. Это дает возможность, написав единожды код шаблона, менять его функциональность путем передачи различных типов функторов как его аргументов (например производить конверсию типов внутри шаблона, у которых отсутствуют необходимые операторы-экстракторы).
Посмотрите также как реализован объект Function из boost.

← →
KSergey © (2007-02-09 11:54) [60]

Чего действительно нет в паскале - так это шаблонов.
только мне думается, что оно и к лучшему :)

А все С++ либы (та же boost) понятно на шаблонах и завязаны, так что говорить об отсутсвии таких библиотек как о минусе - бессмысленно. Для них просто нет поддержки в языке. Хотя функциональных заменителей - вагон в тележкой.

> evvcom © (09.02.07 11:42) [57]
> "()" - это типа оператор расстановки приоритетов?

Это еще и оператор вызова ф-ции/метода :)
Хоя опять же имеет смысл лишь в семантике С++, по-моему.

> sabu (09.02.07 11:41) [56]
> Я к тому, существуют ли смарт поинтеры в паскале или нет?

нафиг?
Считаю это протезом в С++ ввиду отсутсвия конструкции try/finally.
Хотя и удобно, когда привыкнешь. Иногда даже нравится начинает :)

← →
Думкин © (2007-02-09 11:59) [61]

Цитата: Изначально опубликовано komar Вот и кердык одинэсу..... Дим, давай будем поосторожнее в словах и не будем провоцировать участников на религиозные войны. Уважаемые участники, давайте брать лучшее из разных программ и генерировать самое эффективное решение, не основываясь на клановых или релизиозных предпочтениях.
http://www.axforum.info/forums/showthread.php?t=4320&page=2&highlight=%D0%A2%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D0%B0+%D0%B4%D0%B5%D1%80%D0%B5%D0%B2%D0%BE

← →
evvcom © (2007-02-09 12:00) [62]

> [59] sabu (09.02.07 11:49)
> позволяет создавать функторы - функции, имеющие состояния
> функторы как аргументы шаблонов
> отсутствуют необходимые операторы-экстракторы
> объект Function из boost

У....... Видимо, я действительно сильно отстал :) Ты это сейчас с кем разговаривал? :)
Ладно, я понятия не имею, о чем шла речь. Просто есть некоторые догадки из-за того, что есть знакомые буквы. Может я не прав, но, думаю, речь опять идет не о возможностях, а об удобствах. В конце концов все эти шаблоны преобразовываются к какому-то коду, который точно так же можно написать и на Паскале без "функторов", "экстракторов" и "бустов" :)
P.S. Время течет, развивается и Паскаль. Что там нового в BDS 2006 появилось я тоже пока не знаю, но, возможно, что-то из этих или других удобств уже тоже есть.

← →
evvcom © (2007-02-09 12:02) [63]

> [60] KSergey © (09.02.07 11:54)
> Это еще и оператор вызова ф-ции/метода :)

Причем далеко не всегда обязательный :)

← →
Игорь Шевченко © (2007-02-09 12:05) [64]

KSergey © (09.02.07 11:48) [58]

Я ничего не путаю. Кроме указателей на объекты, в языке Паскаль (и в Delphi тоже) есть указатели и не на объекты. При их разыменовании используется оператор ^, аналогичный оператору -> в языке С (++)

sabu (09.02.07 11:49) [59]

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

Известно какие - запутать код до неузнаваемости.
Вот можно ли программисту без особо выстроенных извилин разобраться в коде boost или stl ? :)

← →
sabu (2007-02-09 12:14) [65]

Игорь Шевченко © (09.02.07 12:05) [64]

>При их разыменовании используется оператор ^, аналогичный оператору -> в языке С (++)

Неправда ваша.
В с++ эквивалентом будет (*some_ptr).some_fileld.

>Вот можно ли программисту без особо выстроенных извилин разобраться в коде boost или stl ? :)

В boost может разобраться любой, если приложет достаточно усилий (хотя вряд ли ему захочется ради любопытства разбирать такиее ее части как regexp и spririt).

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

← →
Думкин © (2007-02-09 12:17) [66]

> Во внутреннем устройстве stl по-моему невозможно разобраться,
> так как разработчики применили очень своеобразный стиль
> кодирования.

А чтение VCL доступно всем, без грандиозных усилий.

← →
evvcom © (2007-02-09 12:21) [67]

> [65] sabu (09.02.07 12:14)
> В boost может разобраться любой, если приложет достаточно усилий
> Во внутреннем устройстве stl по-моему невозможно разобраться

Ну и нафига писать такой код? Разработчики с такими известными именами как Microsoft, Borland должны быть примерами для подражания, чтобы по их коду можно было учиться. Я учился по VCL, сейчас сторонние компоненты некоторые смотрю (исходники) и с легкостью в них разбираюсь, потому что написаны они очень похоже на VCL Борланда. А если в stl невозможно разобраться, то вот так и получаются потом такие программисты. Напишут такое, что потом легче застрелиться, чем заниматься поддержкой.

← →
sabu (2007-02-09 12:28) [68]

evvcom © (09.02.07 12:21) [67]

>Ну и нафига писать такой код?

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

> [68] sabu (09.02.07 12:28)

Не убедил.

sabu (09.02.07 12:14) [65]

> Неправда ваша.
> В с++ эквивалентом будет (*some_ptr).some_fileld.

да ну ? :) Удивил.

some_ptr->some_field компилятор не пропустит ?

> В boost может разобраться любой, если приложет достаточно
> усилий

> Во внутреннем устройстве stl по-моему невозможно разобраться

Сравни с паскалем :)

sabu (09.02.07 11:32) [54]
> Может я сильно отстал, и в Си действительно появились какие-
> то возможности, которых нет в Паскале, тогда прошу привести
> их, хотя бы 2-3. Обсудим.

Привести можно. Только чего тут обуждать?
1. В паскале отсутствуют поля, которые есть в обыкноменном C.
2. В паскале отсутствует возможность писать функции с переменным числом параметров. Похожая функциональность достигается при помощи описателя array of const, которая используется в функции Format - паскалевского аналога sprintf . Но паскалевский аналог функции sscanf отсутствует - нет языковых конструкций.

вставлю свои 3 коп... :->

> Чего действительно нет в паскале - так это шаблонов.
> только мне думается, что оно и к лучшему :)

к худшему... шаблоны в си++ не ахти как реализованы (а от template metaprogramming вообще мозги в трубочку сворачиваются ;)), но тем не менее, они есть и это очень мощный иструмент - там, где на паскале будет написано килобайт 200 кода, на си++ - около 6 - 10
плюс, отсутствие полноценных автоматичческих обьектов в дельфи - огромный минус (legacy в виде object в расчет брать не будем - тут уже проскакивало, что скоро их того)

> > sabu (09.02.07 11:41) [56]
> > Я к тому, существуют ли смарт поинтеры в паскале или нет?
>
>
> нафиг?
> Считаю это протезом в С++ ввиду отсутсвия конструкции try/finally.
>
> Хотя и удобно, когда привыкнешь. Иногда даже нравится начинает
> :)

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

> 1. В паскале отсутствуют поля, которые есть в обыкноменном
> C.

Это как ?

← →
sabu (2007-02-09 13:16) [74]

Игорь Шевченко © (09.02.07 12:49) [70]

>да ну ? :) Удивил.
>some_ptr->some_field компилятор не пропустит ?

Конечно пропустит. Однако для получения значения поля здесь используется лишь один оператор. Давая эквивалентный результат, способ отличается синтаксисом.

>Сравни с паскалем :)

А можно ли легко разобраться в Автошеме?
STL по гениальности не уступает этой замечательной программе.
И смех тут мало уместен.

> [71] palva © (09.02.07 13:05)
> 1. В паскале отсутствуют поля, которые есть в обыкноменном C.

Извини, я давно изучал С, напомни, если не в лом, что ты имеешь ввиду.

> В паскале отсутствует возможность писать функции с переменным
> числом параметров. Похожая функциональность достигается при помощи описателя array of const

Ты сам себе противоречишь. Пишешь, что отсутствует возможность, и тут же, что все-таки она есть.

> Но паскалевский аналог функции sscanf отсутствует - нет
> языковых конструкций.

Ерунду говоришь. Нет аналога - напиши. Языковые конструкции имеются. Тот же array of const.

> >Сравни с паскалем :)
>
> А можно ли легко разобраться в Автошеме?
> STL по гениальности не уступает этой замечательной программе.
>
> И смех тут мало уместен.

Дима?... ты?... здгавствуй, годимый :)

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

> [74] sabu (09.02.07 13:16)
> Давая эквивалентный результат, способ отличается синтаксисом.

Так изначально было заявлено что в Паскале нет каких-то возможностей, т.е. чего-то невозможно сделать. Синтаксис тут причем?

> Это как ?

Наверно я плохо сказал. Имеются в виду битовые поля в структурах. Типа так:
#include <stdio.h> void main() { struct { unsigned i1:3, i2:2, i3:5, i4:3; } s; s.i1 = 1; s.i2 = 2; s.i3 = 8; s.i4 = 4; printf("%d %d %d %d\n", s.i1, s.i2, s.i3, s.i4); /* 1 2 8 4 */ }

> [71] palva © (09.02.07 13:05)

Кстати, к аналогам sprintf, sscanf скорее можно отнести write[ln] и read[ln]. Из-за конечного f полной аналогии, конечно, не получится, но тем не менее это compiler magic functions, думаю, в С аналогично. Если посмотреть асм, то никакого "переменного" количества параметров ты не увидишь.

← →
sabu (2007-02-09 13:28) [80]

evvcom © (09.02.07 13:21) [77]

>Так изначально было заявлено что в Паскале нет каких-то возможностей, т.е. чего-то невозможно сделать. Синтаксис тут причем?

Да мы немного отвлеклись.
Проблема была в том, что в паскале отсутствует перегрузка операторов.
И даже если бы она была, неизвестно возможно ли было бы создать смартпоинтеры, перегрузив оператор разыменования, так как для получения значения поля используется два оператора.
Наверняка разработчики компилятора снова применили бы какую-нибудь магию, которой не требуется в c++, языке по своей природе мистическом.

Размер exe-шника С/С++ - и Pascal - компиляторов Найти похожие ветки