Есть ли уже среди Вас, перешедшие на D2009? Расскажите о ее преимуществах, в сравнении с предыдущими версиями. Давно собираюсь найти достойную замену D5.

> [0] Unknown user ©   (24.01.09 23:55)

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

>Eraser

Юникод применяется также в интерфейсе или просто поддержка на уровне функций? Можно подробнее о дженериках?

>[1] Eraser © (2009-01-25 00:06:00)
>риемущества говорят сами за себя - юникод
VCL наконец стал юникодным? не прошло и десяти лет?

---
All Your Base Are Belong to Us

> [2] Unknown user ©   (25.01.09 00:09)


> Юникод применяется также в интерфейсе или просто поддержка
> на уровне функций?

да, теперь он везде )

> Можно подробнее о дженериках?

гугл в помощь.

На больших проектах D2009 ведет себя стабильнее D6 и D7, не говоря уже о предыдущих версиях BDS. От юникода польза только там, где он реально нужен. А кода перелопатить и перетестить на совместимость, как правило,  нужно много. От дженериков польза будет, когда их до ума доведут, а пока стремно даже Generics.Сollections использовать.

>[4] Eraser © (2009-01-25 00:14:00)
>да, теперь он везде )
эх. и всего-то какой-то год не дождался… а x86_64 уже компилирует?

---
Understanding is not required. Only obedience.

> [6] ketmar ©   (25.01.09 00:16)


> а x86_64 уже компилирует?

нет, летом бету компилятора обещают. там вообще планы гитлеровские http://dn.codegear.com/article/39174 лишь бы реализация не как у дженериков была.

> vuk ©   (25.01.09 00:15) [5]
> На больших проектах D2009 ведет себя стабильнее D6 и D7,
>  не говоря уже о предыдущих версиях BDS.


предыдущие BDS м на маленьких не стабильны.

>[7] Eraser © (2009-01-25 00:19:00)
>нет, летом бету компилятора обещают
благодарю. я уже не первый год пишу под x86_64. увы.

---
Do what thou wilt shall be the whole of the Law.

to KilkennyCat ©   (25.01.09 00:21) [8]:
>предыдущие BDS м на маленьких не стабильны.
Ну вот и я про то. У нас основной проект частенько роняет лицом в салат D6. Пробовали D7 - чуть получше, но тоже роняет. С D2009 вроде бы пока сильно лучше, чем на D7. На мелких проектах (до 30-40 модулей) проблем вообще не видно. Окончательно еще не переехали, но переезд запланирован.

>vuk

А в чем заключается бросание лицом в салат? Зависает сама IDE? В Д5 например частенько Code Explorer замерзает на больших проектах. И всякие ошибки с малопонятным названием, вроде L470, не редкость.

>[10] vuk © (2009-01-25 00:29:00)
>На мелких проектах (до 30-40 модулей)
а нафига в одном проекте столько модулей? O_O

---
All Your Base Are Belong to Us

to Unknown user ©   (25.01.09 00:34) [11]:
>А в чем заключается бросание лицом в салат?
Симптомов много. Access violation в разных местах, ошибки линкера на ровном месте, out of system resources, все даже не упомню. Но больше всего раздражает именно когда "лицом в салат" - это когда отвернулся от монитора, потом смотришь, а Delphi нас покинуло. Молча.

to ketmar ©   (25.01.09 00:34) [12]:
>а нафига в одном проекте столько модулей? O_O
За надо. Это еще маленький. В большом, где-то тысячи полторы. :) Формы, фреймы, датамодули, утилиты всякие. Основных форм в приложении больше сотни. Плюс диалогов всяких сотни полторы.

>ketmar

Я работаю над проектом в котором больше сотни модулей. Исполняемый файл в несжатом виде около 6 Мб. Библиотеки не используются, все в исполняемом файле. Неоптимальный подход, но не я начинал этот проект.

> а Delphi нас покинуло. Молча.

О, это да... бесит жутко...

>[14] vuk © (2009-01-25 00:44:00)
как всё мрачно. я бы давно поделил на ядро и набор DLL.

---
Understanding is not required. Only obedience.

to ketmar ©   (25.01.09 00:48) [17]:
> я бы давно поделил на ядро и набор DLL.
Ага, поиметь вместо одного проекта кучу мелких и окончательно в них заблудиться. А потом еще мучительно думать, а почему у юзера на машине dll не той версии.

> Unknown user ©   (24.01.09 23:55)
>  Давно
> собираюсь найти достойную замену D5.

Насколько помню, "достойными заменами" версий Дельфи были Д2(переход от MSDos16 к Win32), Д3(переход от черновика Д2 к чистовику). Других достойных замен не знаю.

http://dn.codegear.com/article/39174

Насколько я понял из статьи, разработчики собираются сохранить обратную совместимость. То есть подменив компилятор на 64 битный мы сможем получить 64 исполняемый код без модификации исходников?

>[18] vuk © (2009-01-25 00:52:00)
>А потом еще мучительно думать, а почему у юзера на машине dll не той версии.
а почему в DLL нет версионности, а в ядре автоапдейтера? O_O

---
Do what thou wilt shall be the whole of the Law.

to ketmar ©   (25.01.09 01:23) [21]:
>а почему в DLL нет версионности, а в ядре автоапдейтера? O_O
Да не, можно было всего этого нагородить, конечно, но только в наших условиях монолитный exe получается намного удобнее. И смысла в модульности - ноль. Даже при весе exe больше 25 мегов.

> vuk ©   (25.01.09 00:15) [5]
>
> На больших проектах D2009 ведет себя стабильнее D6 и D7

Хм.
На всех "больших" проектах, или на некоторых "твоих больших" проектах?

ketmar ©   (25.01.09 00:48) [17]


> как всё мрачно. я бы давно поделил на ядро и набор DLL.


а нафига ?

Не знаю чего там у вас стабильно... я наловил массу глюков внутри новой VCL и плюнул на эту D2009.

> Игорь Шевченко ©   (25.01.09 02:46) [24]
>
> ketmar ©   (25.01.09 00:48) [17]
>
>
> > как всё мрачно. я бы давно поделил на ядро и набор DLL.
>
>
>
> а нафига ?
>

А чтобы все были "во мраке"!
Дарк, он только прикидывается, что он не на тёмной стороне!
:)

to Германн ©   (25.01.09 02:44) [23]:
>На всех "больших" проектах, или на некоторых "твоих больших" проектах?
Странный вопрос. Ясен же пень, что в моем распоряжении только ограниченное множество проектов. :)

> vuk ©   (25.01.09 03:00) [27]
>
> to Германн ©   (25.01.09 02:44) [23]:
> >На всех "больших" проектах, или на некоторых "твоих больших"
> проектах?
> Странный вопрос. Ясен же пень, что в моем распоряжении только
> ограниченное множество проектов. :)
>

Ясен, то он ясен.
Смущает только Пень! :)
См.  [19]

Германн ©   (25.01.09 03:22) [28]


> См.  [19]


Ну не знаю - я на старых версиях не могу работать, после 2006 неудобно.

В 2009 регулярные выражения появились?

to Германн ©   (25.01.09 03:22) [28]:
>См.  [19]
И что? Я, вот, всем, что ниже D5 пользоваться смысла не вижу. Из-за фреймов (у нас это примерно 80% модулей). Как было без них - хорошо помню.

Кто уже использует Д2009 в работе? Какие впечатления о новой среде?

я бы перешел на 2009, но столько денег нет.

> vuk ©   (25.01.09 00:29) [10]  У нас основной проект частенько роняет
> лицом в салат D6. Пробовали D7 - чуть получше, но тоже роняет.
>

Аналогично. И я заметил, что роняет определенный модуль весом в 400Кб где-то. Ну разве это много?

Использую в работе. Перешел с 2006. На 2007 переходить не стал, бесили некоторые глюки. На 2009 перешел даже с учетом того, что пришлось несколько библиотек адптировать руками + код основного проекта.
Впечатления. Быстрая, стабильная, современная, однозначно лучшая. 7ка - блокнот.

Кстати наднях выйдет апдейт3, судя по кол-ву измененных файлов - много фиксов.

>[24] Игорь Шевченко © (2009-01-25 02:46:00)
>а нафига ?
потому что столь огромная программа всё равно состоит из набора модулей (ну, или очень плохо сдизайнена и являет собой страшную лапшу). не вижу смысла тащить в память всё подряд монолитным блобом. хотя… я понимаю, гигабайты памяти, гигагерцы скорости…

---
Understanding is not required. Only obedience.

Ассемблер, только ассемблер

> [5] vuk ©   (25.01.09 00:15)
> А кода перелопатить и перетестить на совместимость, как правило,  нужно много.

Угу. Сейчас занимаюсь этим "перелопачиванием" и конца и края не видно :)

ketmar ©   (25.01.09 15:43) [37]


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


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

Но даже если внутренняя структура четко разграничена на модули - какой смысл делить готовую программу (и заморачиваться дополнительными протоколами связей между модулями), если монолитный EXEшник прекрасно справляется со своей работой ?

насчет плохого дизайна - в где критерии хорошего ?

А в справке изменения в лучшую сторону есть, по сравнению с предыдущий версией?

>[40] Игорь Шевченко © (2009-01-25 16:12:00)
>какой смысл делить готовую программу (и заморачиваться дополнительными
>протоколами связей между модулями), если монолитный EXEшник прекрасно
>справляется со своей работой ?
я считаю, так красивей. и удобней.

>где критерии хорошего ?
у меня в голове, натурально.

---
Do what thou wilt shall be the whole of the Law.

ketmar ©   (25.01.09 16:41) [42]


> я считаю, так красивей. и удобней.



> >где критерии хорошего ?
> у меня в голове, натурально.


"Вынужден констатировать факт моей неоспоримой правоты в данной дискуссии, дальшейшее обсуждение считаю нецелесообразным"

to ketmar ©   (25.01.09 16:41) [42]:
>я считаю, так красивей. и удобней.
Да на здоровье! А практика показывает, что усложнять систему исходя из того, что это будет (наверное) красиво смысла нет. "Усложнять - просто, упрощать - сложно". (c) не помню кто.

>у меня в голове, натурально.
Во, а у меня в голове другой критерий. Если какая-то технология используется только для того "шоп былО", то фтопку такое использование.

> Ну не знаю - я на старых версиях не могу работать, после
> 2006 неудобно.

это точно. после bds2007 редактор кода в d7 для меня ужасен.

Игорь Шевченко ©   (25.01.09 16:55) [43]
Если с установкой SP7 на Windows часть перестает работать, то пользователю надо обновлять все? Вариант обновления пользователю одной dll весом 120 kb не рассматривается?

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

> 123-ий  (26.01.2009 7:58:47)  [47]

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

> Anatoly Podgoretsky ©   (26.01.09 09:05) [48]

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

>123

exe-шник тоже умудряются обновлять каким-то чудом :) ведь он имеет право быть измененным ничуть не меньшее чем библиотеки.

> Unknown user ©   (26.01.09 10:14) [50]

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

test   (26.01.09 07:13) [46]


> Если с установкой SP7 на Windows часть перестает работать,
>  то пользователю надо обновлять все? Вариант обновления
> пользователю одной dll весом 120 kb не рассматривается?


Не рассматривается. Потому что нафиг никому не нужен такой вариант

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

>[53] vuk © (2009-01-26 11:44:00)
>У нас внутрикорпоративный софт.
а про это, кстати, никто ничего не говорил.

---
Understanding is not required. Only obedience.

> ketmar ©   (27.01.09 00:43) [54]

не все козыри сразу. =)

Вернемся к Делфи :) В будущем CodeGear планируют выпустить 64 битный компилятор. Какие это даст преимущества программисту? Будет ли код написанный для 32 битного компилятора компилироваться на 64 битном?

> Будет ли код написанный для 32 битного компилятора компилироваться
> на 64 битном?

ну если грамотно написан, без закладки на то, что размер указателя - всегда 32 бита, то должен

А в каком веке выпустят компилятор под ARM  ?

to ketmar ©   (27.01.09 00:43) [54]:
>а про это, кстати, никто ничего не говорил.
Собственно, какая разница? Мне кажется, что достаточно того, что я говорил, что нам так удобнее в наших условиях.

> На 2009 перешел даже с учетом того, что пришлось несколько
> библиотек адптировать руками + код основного проекта.
> Впечатления. Быстрая, стабильная, современная, однозначно
> лучшая. 7ка - блокнот.


Не согласуется с:


> Кстати наднях выйдет апдейт3, судя по кол-ву измененных
> файлов - много фиксов.

Большая часть багов D2009 связана с дженериками. Если их не использовать, то проблем особых не наблюдается пока.

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

А вот интересно, ведь в C++ билдере, который в той же самой BDS, есть тот же самый VCL, плюс C++ со всеми его шаблонами и STL-ами. Почему люди продолжают кушать кактус и плеваться на дженерики?

> Большая часть багов D2009 связана с дженериками. Если их
> не использовать, то проблем особых не наблюдается пока.


Наблюдается-наблюдается... еще какие... меня взбесило там дофига чего, ну вот например: TTabSheet could throw an access violation if no PageControl was assigned to it

Но есть на свете добрые люди:
http://andy.jgknet.de/blog/?page_id=288

Правда непонятно, почему сами CG так тормозят с фиксами...

В общем, словил я парочку непоняток и AV (жесть!!!) внутри VCL (!!!) и плюнул я на эту версию пока что... буду ждать финального апдейта, типа как December update для 2007... либо выхода следующей версии. DPL и 64 бита меня не интересуют, мне и 32-х за глаза... а вот стабильности с генофондом в VCL - очень хотелось бы.

to ZeroDivide ©   (28.01.09 10:14) [64]:
>Наблюдается-наблюдается... еще какие...
Поконкретнее можно?

>а вот стабильности с генофондом в VCL - очень хотелось бы.
У нас из стандартных компонентов мало что используется, так что на баги серьезные пока не нарвался.

После того, как дебагер вывалился с AV внутри TPageControl, поняв что зрение меня не обманывает... я быстренько свернул все эксперименты с этой IDE :) А подробнее... в QC, думаю, можно ознакомиться. Правда, пока сам не нарвался, все эти qc кажутся малозначительными.

В VCL Fix Pack в версии 1.1 эту проблему закрыли, но я недождался ее выхода... т.е. буду ждать официальные фиксы, а затем много тестировать и думать, стоит ли переходить.

А еще, вроде как, UNICODE_FSS в FireBird IBX не поддерживает (я не пробовал, только слышал), так что несмотря на прелести юникодного интерфейса, полностью юникодофицироватсья у меня не получится, а потому, возможно, в моем случае, стоит повременить с переходом.


> У нас из стандартных компонентов мало что используется,
> так что на баги серьезные пока не нарвался.


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