Вот говорят, что дельфи не умирает

← →
DevilDevil © (2014-01-22 10:23) [240]

> vuk © (22.01.14 10:15) [239]
> Засада только одна - это неизвестно, какая часть.

На дворе 21 век. И современные компиляторы вполне успешно справляются с задачей определения, какой код прилинковывать, а какой нет :)

← →
vuk © (2014-01-22 10:25) [241]

to DevilDevil © (22.01.14 10:23) [240]:

> И современные компиляторы вполне успешно справляются с
> задачей определения, какой код прилинковывать, а какой нет
> :)

Компиляторы научились заглядывать настолько вперед, что знают, какое свойство у них запросят через RTTI?

← →
DevilDevil © (2014-01-22 10:35) [242]

[174]

← →
vuk © (2014-01-22 10:38) [243]

И что? То что там написано относительно RTTI - чушь.

← →
DevilDevil © (2014-01-22 10:39) [244]

очень сильный аргумент, товарищ vuk :)

← →
vuk © (2014-01-22 10:49) [245]

Хорошо, буду задавать вопросы.

> Пусть отныне свойства и функции, объявленные в published
> не будут заноситься в RTTI, но сохраняют роль отображаемых
> в Object Inspector.
>

Каким макаром? Святым духом?

До кучи. Ощущение, что у вас нет понимания, зачем вообще нужен механизм RTTI. А ведь он подразумевает обращение к произвольным свойствам посредством полученной от компонента информации. Поэтому то, что объявлено, как доступное через RTTI обязано включаться безусловно. Да и компонентные модели подразумевают неделимость компонентов.

А от замены dfm на код я и сам бы не отказался, но только по совершенно другим причинам. Причем, при сохранении текущей компонентной модели и RTTI. Размер exe меня не волнует на данный момент, ну вот совсем. У меня он больше 50 мегабайт и я не парюсь. :)

← →
Ega23 © (2014-01-22 10:54) [246]

> На дворе 21 век. И современные компиляторы вполне успешно
> справляются с задачей определения, какой код прилинковывать,
> а какой нет :)

Да. И оптимизируют очень неплохо, в отличие от дельфёвого. Только вот время билда - 2 часа, заместо 10 секунд.

← →
Inovet © (2014-01-22 11:00) [247]

> [246] Ega23 © (22.01.14 10:54)
> Только вот время билда  2 часа, заместо 10 секунд.

Нужен оптимизатор оптимизации.

← →
DevilDevil © (2014-01-22 11:01) [248]

> Ega23 © (22.01.14 10:54) [246]

> Да. И оптимизируют очень неплохо, в отличие от дельфёвого.
> Только вот время билда - 2 часа, заместо 10 секунд.

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

← →
DevilDevil © (2014-01-22 11:08) [249]

> vuk © (22.01.14 10:49) [245]

блин
говорю ведь об элементарных вещах

формула обхода RTTI очень проста
а) не нужно всё подряд пихать в RTTI (как в текущих версиях)
б) published свойства идут в RTTI в design-time bpl-и, но для run-time published в RTTI не идёт
в) dfm-ки переводятся в статический код

что здесь сложного и из ряда вон выходящего ?
в run-time RTTI по свойствам и методам нужен крайне редко. Поэтому и включать его в run-time нужно при наличии каких-то специальных опций, а не по дефолту, как это делается сейчас

← →
Василий Иванов (2014-01-22 11:13) [250]

> Поэтому и включать его в run-time нужно при наличии каких-
> то специальных опций, а не по дефолту, как это делается
> сейчас

наконец-то дошли до сути

← →
vuk © (2014-01-22 11:15) [251]

to DevilDevil © (22.01.14 11:08) [249]:

> published свойства идут в RTTI в design-time bpl-и, но для
> run-time published в RTTI не идёт

Что идет вразрез с правилом неделимости компонентов и делает невозможным обращение к произвольным свойствам.

← →
имя (2014-01-22 11:20) [252]

Удалено модератором

← →
Ega23 © (2014-01-22 11:25) [253]

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

Надо линковать, тогда ещё быстрее будет. И оптимизатор выключить. Тогда до секунды той самой дойдёт.

← →
DevilDevil © (2014-01-22 11:27) [254]

> Ega23 © (22.01.14 11:25) [253]

скорость записи лишних данных на диск значительно медленнее работы алгоритма по отбрасыванию лишнего из линковки

← →
Inovet © (2014-01-22 11:28) [255]

> [253] Ega23 © (22.01.14 11:25)
> Надо линковать, тогда ещё быстрее будет.

Заодно винчестер поменять на какой-нибудь не старше хотя бы лет 10.

← →
Ega23 © (2014-01-22 11:38) [256]

Удалено модератором

← →
DevilDevil © (2014-01-22 11:53) [257]

Удалено модератором
Примечание: Выражения выбираем, не в пивной

← →
Ega23 © (2014-01-22 11:56) [258]

Понятно. Не прочитал, в общем. Или прочитал, но не понял.
Ненаказуемо.

← →
имя (2014-01-22 11:59) [259]

Удалено модератором

← →
DevilDevil © (2014-01-22 12:02) [260]

> Ega23 © (22.01.14 11:56) [258]

Если мнение GunSmoker-а импонирует твоему нежеланию (и/или неумению) оптимизировать - это не значит, что вы правы.

По поводу актуальности он прав и я согласен. Но умный компилятор и скорость компиляции - актуальны по сей день. А ты об этом почему-то забываешь

← →
DevilDevil © (2014-01-22 12:04) [261]

> Василий Иванов (22.01.14 11:59) [259]
> Выбери другой инструмент, делов-то?

Дак а я и выбираю. Программирую на Delphi 6 и 7
Только я болею за болею за развитие Delphi и мне не безразличен сабж. Просто хочется, чтобы кроме развития охвата платформ, компилятору прибавилось бы ещё и ума, а скорость компиляции ещё бы сократилась, в том числе и для C++Builder, а то там вообще ахтунг (с той же Visual Studio сравнивая)

← →
Ega23 © (2014-01-22 12:19) [262]

Цена на 1 байт дискового пространства, а также оперативной памяти, за последние 20 лет упала порядков так на 6.
Вот, собственно, и всё.

← →
Игорь Шевченко © (2014-01-22 12:22) [263]

http://russian.joelonsoftware.com/Articles/StrategyLetterIV.html

← →
DevilDevil © (2014-01-22 12:25) [264]

[257]

← →
Плохиш © (2014-01-22 13:35) [265]

> Только я болею за болею за развитие Delphi и мне не безразличен
> сабж.

Ещë один кухонный болельщик? Предложи производителю свои услуги по создонию сверкрутой среды разработки, а то они реально не справляются. То объявляют баги как desined и закрывают, то просто меняют текст исключения и то же баг объявляют закрытым.

← →
Kerk © (2014-01-22 13:52) [266]

Если поставить себя на место менеджеров Embarcadero и представить, что есть свободные N человеко-часов для работ над компилятором - что же сделать:
1) исправить часть известных багов;
2) добавить больше функционала;
3) немного сократить размер exe.

Даже не знаю, чего бы я выбрал...

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

← →
Ega23 © (2014-01-22 14:04) [267]

Если они наконец-то ErrorInside нормально сделают и Find Declaration - это будет гораздо бОльший успех и выгода во времени, чем мистические секунды и мегабайты.

← →
DevilDevil © (2014-01-22 14:11) [268]

> Kerk © (22.01.14 13:52) [266]
> Ega23 © (22.01.14 14:04) [267]

Согласен
Только если сделать компилятор умным - к нему будут серьёзнее относиться - чаще закупать - денег будет больше - тем подобной этой не будет.

Сейчас есть поддержка Android и iOS. А толк?
Все как программили под Eclipse и XCode - так и программят
С чего бы это, да ?

to DevilDevil © (22.01.14 14:11) [268]:

> С чего бы это, да ?

Попробую угадать. Размер исполняемых модулей и только. Это единственная проблема, разумеется. :))

Да, если бы вместо поддержки Android и iOS, уменьшили бы размер exe-шников, то все бы сейчас на Delphi писали, а не под Eclipse и XCode. Даже и не поспоришь.

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

← →
jumping jack (2014-01-22 14:25) [271]

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

но поскольку DevilDevil вроде бы VCL доволен, а не доволен только FMX
и энтузиазма у него полно, то как бы напрашивается идея взять ему флаг в свои руки да и сделать свой собственный виджетсет, примерно так же отличающийся от FMX, как KOL от VCL (в сторону легкости и скорости)

ну, если свой виджетсет - слишком сложно, можно подумать об утилите или визарде, берущей весь исходный код FMX и копирующей её в папку проекта с должной обработкой (лучше в виде вставки кучи $IFDEF), позволяющей скомпилировать всё в супероблегченном виде (без RTTI, а, если можно, даже меняя virtual-методы на static)

Не угадал
Основная проблема в том, что Delphi и C++Builder под девайсы не воспринимают всерьёз.
А происходит это уже по целому ряду причин

Баги FMX, медленная компиляция (билдер), низкое качество генерируемого под винду кода (ярлык, который закреплялся на протяжении уже не первого жесятка лет), тупой компилятор, плохой маркетинг, завышенная цена, огромный размер бинарного файла.

Зачем делать ставку на туфту если можно делать ставку на зарекомендовавшиеся себя решения? Вот и не делают. Размер бинарника - это всего лишь одно из проявлений низкокачественного компилятора и архитектуры, что в конечном счёте влияет на низкую популярность продукта

← →
jumping jack (2014-01-22 14:29) [273]

и, конечно, с переводом DFM в код (эта утилита/визард)

> которое появилось всего-то несколько месяцев назад

XE2 появился в 2011 году
бинарники под девайсы генерятся через LLVM. Как и в XCode кстати
FM вообще хрен знает сколько лет, раньше она по другому называлась

> Да, если бы вместо поддержки Android и iOS, уменьшили бы
> размер exe-шников, то все бы сейчас на Delphi писали, а
> не под Eclipse и XCode. Даже и не поспоришь.

давай мы перестанем устраивать детский сад и придумывать мессейджи, на которые я не намекал
по поводу размера, поддержки устройств и RTTI я тебе всё пояснил, причём несколько раз. Я не думаю, что такому взрослому человеку как ты, здесь может быть что-то не понятно

to DevilDevil © (22.01.14 14:26) [272]:

> А происходит это уже по целому ряду причин

От то-то же! Размер даже в приведенном списке, где-то на последнем месте. А в самом начале - нечто другое.

> Размер бинарника - это всего лишь одно из проявлений низкокачественного
> компилятора и архитектуры, что в конечном счёте влияет на
> низкую популярность продукта

Реквестирую список компонентных архитектур, приводящих к маленькому размеру бинарника! :)

> DevilDevil © (22.01.14 14:33) [274]
>
> > которое появилось всего-то несколько месяцев назад
>
> XE2 появился в 2011 году
> бинарники под девайсы генерятся через LLVM. Как и в XCode кстати
> FM вообще хрен знает сколько лет, раньше она по другому называлась

Поддержка iOS появилась в прошлом году в апреле, поддержка Android в прошлом году в сентябре. Всего-лишь год назад никаких iOS/Android в Delphi не было и следа. Я не думаю, что Delphi когда-нибудь станет популярнее, чем родные средства разработки для этих платформ, но все равно ждать хоть каких-то успехов на этом поприще еще слишком рано.

> но поскольку DevilDevil вроде бы VCL доволен, а не доволен
> только FMX

Конкретно я не доволен и VCL в новых версиях. Всё то же время компиляции и размер бинарника. А почему это происходит - из-за дженериков, неймспейсов, инлайнов, RTTI или ещё какой билиберды - я уже не знаю. Я знаю, что можно сделать и быстрее и компактнее - было бы желание.

> и энтузиазма у него полно, то как бы напрашивается идея
> взять ему флаг в свои руки да и сделать свой собственный
> виджетсет, примерно так же отличающийся от FMX, как KOL
> от VCL (в сторону легкости и скорости)

энтузиазма полно. Только он целиком и полностью уходит на свои проекты. Его даже слишком мало :)
Delphi-компилятор я один не напишу :) А добавлять виджетсет типа KOL тоже не вижу смысла :)

← →
имя (2014-01-22 14:43) [278]

Удалено модератором
Примечание: Достал

> Поддержка iOS появилась в прошлом году в апреле

http://ru.wikipedia.org/wiki/Delphi_(%D1%81%D1%80%D0%B5%D0%B4%D0%B0_%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B8)#Delphi_XE2

Вроде и лет не двадцать.
Странно это всё.

Вот говорят, что дельфи не умирает Найти похожие ветки