Компилятор Delphi

← →
NaRuTo © (2008-02-22 17:08) [0]

Уважаемые мастера! Правдо ли то что компилятор Delphi много всякой не нужной информации заносит в exe-шник....И из за этого размеры ехе Delphi так велики

← →
Skier © (2008-02-22 17:10) [1]

Неправдо

← →
Черный Шаман (2008-02-22 17:12) [2]

> NaRuTo © (22.02.08 17:08)

Пиши на WinApi

← →
Thrasher © (2008-02-22 17:14) [3]

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

← →
Джо © (2008-02-22 17:39) [4]

Компилятор туда еще встраивает отпечатки пальцев кодера (новые технологии борьбы с пиратством).
И это так же верно, как и то, что у алжирского бея под носом шишка.

← →
Правильный_Вася (2008-02-22 18:02) [5]

кораздо больше ненужной информации туда встраивает програмер

← →
NaRuTo © (2008-02-22 20:00) [6]

> Правильный_Вася (22.02.08 18:02) [5]

Смотря какой...

← →
Palladin © (2008-02-22 20:03) [7]

смотреть"то зачем... сказано же, что ненужной....

← →
tesseract © (2008-02-22 22:22) [8]

Ну ресурсы Delphi вырезать так и научился.

← →
Loginov Dmitry © (2008-02-22 23:27) [9]

> Уважаемые мастера! Правдо ли то что компилятор Delphi много
> всякой не нужной информации заносит в exe-шник....И из за
> этого размеры ехе Delphi так велики

Нет. Он вставлят только нужную нужную информацию и код виртуальных функций всех используемых в приложении классов. Причем это делает не компилятор (он вообще ни в чем не виновен), а злой Linker. Видимо, разработчикам Delphi было просто влом дорабатывать linker соответствующим образом. Вот и получается, что проект из одной формы на 90% состоит из "мертвого" кода, который никогда не будет выполнен.

← →
Игорь Шевченко © (2008-02-22 23:29) [10]

Правда.
Все компиляторы зло.

← →
Amoeba © (2008-02-22 23:50) [11]

> Loginov Dmitry © (22.02.08 23:27) [9]
>
> > Уважаемые мастера! Правдо ли то что компилятор Delphi
> много
> > всякой не нужной информации заносит в exe-шник....И из
> за
> > этого размеры ехе Delphi так велики
>
>
> Нет. Он вставлят только нужную нужную информацию и код виртуальных
> функций всех используемых в приложении классов. Причем это
> делает не компилятор (он вообще ни в чем не виновен), а
> злой Linker. Видимо, разработчикам Delphi было просто влом
> дорабатывать linker соответствующим образом. Вот и получается,
> что проект из одной формы на 90% состоит из "мертвого"
> кода, который никогда не будет выполнен.

На этапе компиляции нереально определить какие из виртуальных ф-ий будут вызываться, а какие нет, в отличие от статических. Не стоит вешать собак на ребят из Borland"а.

← →
Игорь Шевченко © (2008-02-22 23:55) [12]

> Видимо, разработчикам Delphi было просто влом дорабатывать
> linker соответствующим образом

Плохо быть разработчиком. Всяк пнуть норовит

← →
Loginov Dmitry © (2008-02-23 23:18) [13]

> На этапе компиляции нереально определить какие из виртуальных
> ф-ий будут вызываться, а какие нет

Если к функции есть обращение, то она будет вызываться. Если обращений нет - то не будет! Куда уж проще? В рамках одного модуля отследить это не должно представлять никаких сложностей. Т.е. задача в частных случаях имеет простейшее решение, и если линкер не имеет возможности определить, можно ли выкинуть данную функцию или нет, то разработчики Delphi вполне могли бы дать возможность программистам указывать, можно ли это делать, или нет. Но видимо, влом было этим заниматься!

← →
Семеныч (2008-02-23 23:30) [14]

> Loginov Dmitry © (23.02.08 23:18) [13]

> В рамках одного модуля отследить это не должно представлять
> никаких сложностей.

В рамках одной статически собранной программы, а не модуля. И Delphi это действительно отслеживает.

А модуль - это BPL. Он может загружаться динамически - поэтому на этапе его компиляции невозможно определить, что из него будет использовано, а что не будет. Та же история с DLL. Поэтому в BPL и DLL надо включать все, что экспортируется - что Delphi и делает.

← →
Loginov Dmitry © (2008-02-24 00:00) [15]

> В рамках одной статически собранной программы, а не модуля.

Это и имеется ввиду под термином "модуль" чаще всего.

← →
Loginov Dmitry © (2008-02-24 00:01) [16]

> А модуль - это BPL. Он может загружаться динамически - поэтому
> на этапе его компиляции невозможно определить, что из него
> будет использовано, а что не будет.

Это совсем не в тему.

← →
ANTPro © (2008-02-24 00:02) [17]

Вот разработчики гады до сих пор в компиляторе AI не реализовали! :о)

← →
boa_kaa © (2008-02-24 00:23) [18]

сижу... фтыкаю... что же вставляет QT и почему он тогда устраивает Adobe???

← →
Плохиш © (2008-02-24 00:59) [19]

> boa_kaa © (24.02.08 00:23) [18]
> сижу... фтыкаю... что же вставляет QT и почему он тогда
> устраивает Adobe???

Есть подозрение, что Adobe глубоко фиолетово кто, что и куда "вставляет", они деньги зарабатывают.

← →
www (2008-02-24 17:22) [20]

> Вот и получается, что проект из одной формы на 90% состоит
> из "мертвого" кода, который никогда не будет выполнен.

из одной формы, на которой ничего нет
и нафига такой такой проект нужен? как часто ты такое Г делаешь?

← →
ANTPro © (2008-02-24 17:32) [21]

> [20] www (24.02.08 17:22)

Ты не поверишь&#133 есть софт в котором 3-5 форм, а стоит он десятки млн.

← →
www (2008-02-24 19:25) [22]

> есть софт в котором 3-5 форм

> из одной формы, на которой ничего нет

найди 3-5 различий

← →
Loginov Dmitry © (2008-02-24 19:37) [23]

> из одной формы, на которой ничего нет
> и нафига такой такой проект нужен? как часто ты такое Г
> делаешь?

ты эта... В тематику ветки уже въехал?

← →
www (2008-02-24 19:49) [24]

я "эта"

← →
TUser © (2008-02-25 04:47) [25]

> Loginov Dmitry © (23.02.08 23:18) [13]
> > На этапе компиляции нереально определить какие из виртуальных
>
> > ф-ий будут вызываться, а какие нет
>
>
> Если к функции есть обращение, то она будет вызываться.
> Если обращений нет - то не будет! Куда уж проще?

А если функция вызывается так
procedure TYourClass.WMPUPKIN (var Msg: TMessage); message WM_PUPKIN;
begin
if csDesignTime in ComponentState then
CallFunction();
end;
линковать ли код для CallFunction? Да она никогда не будет работать! Да такого сообщения не приходит! Да даже если и придет, то это уже не дезайн-тайм!

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

← →
Loginov Dmitry © (2008-02-25 07:51) [26]

> линковать ли код для CallFunction? Да она никогда не будет
> работать! Да такого сообщения не приходит! Да даже если
> и придет, то это уже не дезайн-тайм!

Это пример, где линкер как раз обязан включить CallFunction();

А вот примет по-проще:

type TMyObject = class procedure Proc1; procedure Proc2; virtual; end; .............................. procedure TMyObject.Proc1; begin ShowMessage("Proc1"); end; procedure TMyObject.Proc2; begin ShowMessage("Proc2"); end; procedure TForm1.FormCreate(Sender: TObject); begin with TMyObject.Create do try Proc1; finally Free; end; end;

Неужели определить, что процедура "Proc2" ниоткуда не вызывается - настолько сложная задача?
1000 раз - не верю!!!!

← →
www (2008-02-25 11:38) [27]

> что процедура "Proc2" ниоткуда не вызывается

это не процедура, это метод класса

> [27] www (25.02.08 11:38)

:о)

> это не процедура, это метод класса

;)
а разница между ними в чем, хоть в курсе?

Всеж-таки насчет 1000 раз я погорячился. С утра все думал над этой проблемой. Она не то чтобы не разрешимая, но ее решение весьма непростое и не стоит тех сил и времени, требуемых на ее решение. Решить ее можно, но для этого нужно вводить в спецификацию языка новые директивы (имеющимихся средств недостаточно), которые только запутают язык (поэтому их использовать никто не будет). Так что придется принять проблему "мертвого" кода, как неизбежную плату на столь красивый и удобный язык ;)

← →
winamp (2008-02-25 17:04) [31]

пишем код:
program Project1; begin end.

жмем один раз F7
потом Ctrl+Alt+C (окно отладки)
и потом много-много раз F7
Наблюдаем вызовы InitExe,StartExe,InitUnits, и многое-многое другое.....
Это можно назвать хитрым обрядом Стартования Программы.
Потом приходим к не менее хитрому и запутанному обряду Окончания Программы.
Вопрос - нафига все это нужно?

> winamp (25.02.08 17:04) [31]

(1) Эти обряды стартовая и окончания занимают в общей сложности 8Кб.
(2) В модуле System есть несколько глобальных переменных, которые затем используются другими процедурами/фукциями, которые надо инициализировать. Например, ParamCount, hInstance, hModule менеджер памяти и т. д.
(3) Надо инициализировать TSL где будут жить threadvar переменные
(4) Надо выполнить секцию initialization всех модулей
(5) Надо вызвать ту процедуру, что между begin и end.

Может я что и пропустил. А вот уже подключение SysUtils сразу дает еще +50K к размеру (переменные + их инициализация).

Но, если хочешь, перекомпилируй system.pas и выброси все, что считаешь лишним :)

> Есть такая штука — KOL.

Есть. Ее фишка в том и заключаются, что везде, где только можно, избегают использования виртуальных фукнций. Но это, к сожалению, крайне неудобно и некрасиво (пример - сам KOL).

> Loginov Dmitry © (25.02.08 16:08) [29]

В общем случае решения не существует. Адреса виртуальных процедур и функций хранятся в таблице VMT. Для любого объекта указатель на таблицу VMT используется. Как можно определить, что ее элемент с определенным индексом не используется? Не говоря о том, что индекс можно получить арифметическим путем, большинство виртуальным методом TObject вызываются из ассемблерных вставок с использованием констант. Кроме того никто не мешает мне в коде напрямую аналогичным образом использовать VMT.

Впрочем такая ситуация достаточно экзотична. Обычно описанная виртуальная функция все-таки где-то вызывается в коде. Вот только этот код может быть в секции условия if, которое никогда не сработает, в сообщении, на которое никогда не будет установлена подписка, в классе, экземпляры которого не создаются, но во всех потомках она перекрыта и т. д. И тут ничего не сделаешь (например в последнем случае класс может быть создан с использованием RTTI).

← →
asail (2008-02-25 17:57) [35]

> Loginov Dmitry © (25.02.08 07:51) [26]

> Неужели определить, что процедура "Proc2" ниоткуда не вызывается
> - настолько сложная задача?

Да, а если в где-то есть:TMyNewObject = class (TMyObject) ... end;

А затем где-то вызывается: MyNewObj = TMyNewObject.Create; try MyNewObj.Proc2; finally MyNewObj.Free; end;

Что тогда? А если эти классы еще и в разных bpl описанны???
см. [14]

> Есть такая штука — KOL.

Ага. ТОлько KOL по удобству использования с VCL рядом не лежал...
Он конечно дает маленькие приложения... НО ИМХО если стоит вопрос скорости и размера: пиши на WinAPI, стосит вопрос скорости разработки интерфейса - пиши на VCL... а у KOL какое применение?

> пиши на WinAPI, стосит вопрос скорости разработки интерфейса
> - пиши на VCL... а у KOL какое применение?

Нечто среднее :) Надо к черному и белому просто добавить серое :)

← →
www (2008-02-25 18:33) [38]

> а у KOL какое применение?

показать разницу?

Компилятор Delphi Найти похожие ветки