Что за delphi такой XE?

← →
Eraser © (2011-08-20 01:02) [40]

> [37] Dennis I. Komarov © (19.08.11 23:41)

Дань моде это, возможно, только для программ, расчитанных на работу внутри какого-то одного конкретного учреждения или же для узкоспециализированных утилит, опять же, для внутренних нужд. В остальном, обязательно найдутся юзеры, которым понадобиться полноценный юникод. Про коробочные продукты и речи нет, там понадобится 100%.

← →
Игорь Шевченко © (2011-08-20 01:09) [41]

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

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

← →
Германн © (2011-08-20 01:42) [42]

> Anatoly Podgoretsky © (19.08.11 23:34) [34]
>
>
> > Так что еще проблемы с переводом - это результат халатного
> > отношения к работе ранее.
>
> Это так, но мало кто до 2009 писал AnsiString, а не string

Подозреваю, что таких не просто мало, а очень мало.
Клинические случаи не будем рассматривать. А из остальных только типа меня. Которые при отсутствии нормального финансирования (про которое упоминал ИШ) поддерживали и поддерживают проект созданный в Д1. Мне без явного указания типа AnsiString ну никак нельзя было обойтись, ибо очень часто использовались паскалевские строки с учетом их структуры.
Но мне тогда это было "жизненно необходимо"! 16-битная программа не могла работать с железом на NT-платформе.

← →
Германн © (2011-08-20 02:15) [43]

> Eraser © (20.08.11 00:57) [39]
>
> > [17] Игорь Шевченко © (19.08.11 20:34)
>
> Поддержка юникода появилась 3 года назад. Можно было за
> этот срок выделить время на его внедрение.

Срок-то да. А деньги?
Кто захочет тратить деньги за какой-то там Юникод, если ПО и так работает?

← →
Eraser © (2011-08-20 02:42) [44]

> [42] Германн © (20.08.11 01:42)

> Игорь Шевченко ©

А кто выделяет деньги на то, что программеры вместо работы сидят в соц. сетях, блогах или на форумах? Вот тот пусть и перераспределит рабочее время, выделив часть и для рефакторинга. Я прекрасно понимаю, что бывают исключения - хорошо слаженные команды, где фактически 90% рабочего времени уделяется работе, ежедневный план составлен на год (или хотя бы пару месяцев) вперед и т.п. Но реалии таковы, что обычно пареньки, которые по совместительству сами себе и технические директора тратят на работу куда меньше половины положенного рабочего времени. "Не вижу возможности и высокие трудозатраты" и дальше разглядывает фотки "одноклассниц" ) Короче принцип "работает - не трожь". Такое нынче правило, но исключения допускаю, как я уже сказал. Так что биться об заклад в конкретно этом случае не стал бы.

← →
Германн © (2011-08-20 03:14) [45]

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

Я не сижу ни в соц.сетях, ни в блогах, ни даже в ЖЖ (куда меня регулярно пытался перенаправить Kerk). Я даже в интернет выхожу только изредка.

← →
Германн © (2011-08-20 03:23) [46]

> Eraser © (20.08.11 02:42) [44]
>
> > [42] Германн © (20.08.11 01:42)
>
>
> > Игорь Шевченко ©
>
> А кто выделяет деньги на то, что программеры вместо работы
> сидят

У тебя какая-то ненормальная фирма.
Не знаю точно как у ИШ, но с меня требуют результат. И именно в те сроки, которые были оговорены. А кто, где и как сидит, это уже не важно.

← →
Eraser © (2011-08-20 03:54) [47]

> [45] Германн © (20.08.11 03:14)

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

> [46] Германн © (20.08.11 03:23)

> У тебя какая-то ненормальная фирма.

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

← →
Игорь Шевченко © (2011-08-20 11:25) [48]

> А кто выделяет деньги на то, что программеры вместо работы
> сидят в соц. сетях, блогах или на форумах? Вот тот пусть
> и перераспределит рабочее время

Слив засчитан

← →
Anatoly Podgoretsky © (2011-08-20 11:54) [49]

Хорошую штуку ХЕ не назовут, надо минимум два ХЕ

← →
Inovet © (2011-08-20 12:40) [50]

> [49] Anatoly Podgoretsky © (20.08.11 11:54)
> два ХЕ

Квадратный ХЕ.

← →
Anatoly Podgoretsky © (2011-08-20 12:43) [51]

Ну да в квадрате XE^2

← →
Anatoly Podgoretsky © (2011-08-20 12:44) [52]

> Inovet (20.08.2011 12:40:50) [50]

И решить уравнение a+a=a*a

← →
Inovet © (2011-08-20 12:49) [53]

> [52] Anatoly Podgoretsky © (20.08.11 12:44)
> a+a=a*a

0, 2

← →
Anatoly Podgoretsky © (2011-08-20 12:56) [54]

> Inovet (20.08.2011 12:49:53) [53]

Ответ должен быть один и по теме, еще раз

XE+XE=XE*XE

Чему равно XE

← →
Inovet © (2011-08-20 12:59) [55]

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

← →
Inovet © (2011-08-20 13:13) [56]

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

← →
Компромисс (2011-08-20 13:33) [57]

Рефакторинг сам по себе не является благом. Если после рефакторинга появляются улучшения (уменьшение времени внесения изменений, повышения быстродействия, масштабируемости и т.д.), только тогда можно говорить благе.
В данном конкретном случае никакого блага не появляется, даже наоборот. Тратится время (которого нет) и появляется возможность для новых багов.
Вот если бы заказчик запросил поддержку юникода, то одним из вариантов решения был бы переход на другую версию Delphi. Причем, вполне могло оказаться, что был бы принят другой вариант решения ибо добавить поддержку а la tnt могло быть на N дней быстрее и без внесения новых багов.

Расскажу о своем опыте. Были проекты на D3, D4, D6. Выясняется, что в одном из приложений D3 есть утечка памяти, которая через пару недель работы приводит к зависанию сервера приложений. Принимается решение о переводе на D6 (хотя последняя версия уже D7), потому что 1) в D6 данный баг уже исправлен 2) есть специалисты с опытом работы именно на D6. То есть не придется искать/учить работника с D7. При этом все остальные приложения остаются на D3/D4.
"Работает - не трожь" никто не отменял.
А то проведете рефакторинг ("модернизацию"), а тебе за это лишение премии, за внесение новых багов. И никого не будет волновать, чего ты там еще добавил, потому что это что-то всё равно никому не нужно и никем не используется.

← →
oxffff © (2011-08-20 14:01) [58]

Все дело в том, что хороших специалистов единицы.

← →
Компромисс (2011-08-20 14:08) [59]

Все дело в том, что хороших специалистов единицы.

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

← →
Anatoly Podgoretsky © (2011-08-20 15:19) [60]

> Компромисс (20.08.2011 13:33:57) [57]

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

Д5, Д6, Д7 братья близнецы, по сути SP1 и SP2
Просто кушать хотелось.

← →
Anatoly Podgoretsky © (2011-08-20 15:22) [61]

> Компромисс (20.08.2011 14:08:59) [59]

Есть правило - продолжать поддерживать проект в той же версии и только если
обосновано тогда и переносить. Но с Д5 на Д7 как правило только
перекомпиляция, если конечно нет посторонних компонент

← →
Компромисс (2011-08-20 15:49) [62]

Есть правило - продолжать поддерживать проект в той же версии и только если
обосновано тогда и переносить.

Как раз это правило и обсуждалось в этой ветке.

← →
Eraser © (2011-08-20 17:07) [63]

> [57] Компромисс (20.08.11 13:33)

Вы описали классический подход к разработке софта. В целом я его противник, т.е. противник правила "работает - не трожь". На каком-то этапе действительно посчитают, что TNT проще, чем переход на новую версию. Сейчас вот выйдет XE2 с поддержкой 64 разрядности, потом через пару лет заказчик потребует сделать 64x версию программы. В итоге получим, что от TNT все равно придется избавляться и переходить таки на новую версию делфи, при этом переписывать придется гораздо больше. Да бог бы с ним с юникодом и 64x. Вот без дженериков рельно неудобно работать. Мое мнение, что нужно адаптивровать проект (если конечно проект расчитан на развитие, что далеко не обязательно должно быть так) к каждой новой версии компилятора.

← →
DVM © (2011-08-20 17:15) [64]

> Eraser © (20.08.11 02:42) [44]

+100

Кстати, бонусом от перехода на юникод будет еще повышение производительности программы, особенно интенсивно использующих WinAPI.

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

Переходить никого и никуда не агитирую. Просто категоричность некоторых умиляет.

← →
Игорь Шевченко © (2011-08-20 17:16) [65]

Anatoly Podgoretsky © (20.08.11 15:22) [61]

> Но с Д5 на Д7 как правило только
> перекомпиляция, если конечно нет посторонних компонент

а Variants когда выделился ? По-моему, в D6
И русский текст в dfm стал юникодным

← →
Игорь Шевченко © (2011-08-20 17:18) [66]

> Сейчас вот выйдет XE2 с поддержкой 64 разрядности, потом
> через пару лет заказчик потребует сделать 64x версию программы

Мечты.

> Мое мнение, что нужно адаптивровать проект (если конечно
> проект расчитан на развитие, что далеко не обязательно должно
> быть так) к каждой новой версии компилятора

Монгольский космонавт

← →
DVM © (2011-08-20 17:21) [67]

> Игорь Шевченко © (20.08.11 17:18) [66]

> > Мое мнение, что нужно адаптивровать проект (если конечно
>
> > проект расчитан на развитие, что далеко не обязательно
> должно
> > быть так) к каждой новой версии компилятора
>
>
> Монгольский космонавт

Это вы разработчику платных компонент расскажите

← →
Игорь Шевченко © (2011-08-20 17:58) [68]

DVM © (20.08.11 17:21) [67]

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

Всегда ваш,
К.О.

Это как с виндой. После выхода новой версии консерваторы года 2-3 орут, что пользоваться этой системой нельзя, корпорация зла опять все изуродовала и сидят на ОС 10 летней давности. Потом, как раз, к выходу уже следующего обновления, консерваторы наконец переходят на старую новую винду и начинают плодить ветки "а что такое UAC?", "а куда подевались мои файлы?" и т.п. От версии к версии такой цирк повторяется. По-моему проще сразу смириться с неизбежным и пробовать новые версии. Я не агитирую за то, что нужно кидаться на каждую новую бета-версию или RC, но за прогрессом основных инструментов работы нужно следить.

Eraser © (20.08.11 17:59) [69]

> -моему проще сразу смириться с неизбежным и пробовать новые
> версии

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

> [70] Игорь Шевченко © (20.08.11 18:01)

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

> Игорь Шевченко (20.08.2011 17:16:05) [65]

Не помню, но вроде бы в Д5, но если и так, то это такая мелочь, о которой
скажет компилятор

> Eraser © (20.08.11 17:07) [63]

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

Вот заказчик пусть и оплачивает переход. Не только разработку, но и тестирование ессно тоже...

> asail © (20.08.11 23:21) [73]

Хочет заказчик или нет, хотим мы или нет, но век 32 бит программ и ОС подходит к концу. Лучше быть готовым к этому заранее. 32 бит программы еще поддерживаются в 64 бит системах, но вот 16 бит уже нет, а ведь не так давно казалось, что они живее всех живых. Никто не может гарантировать, что в следующей версии ОС не исчезнет поддержка 32 бит программ или она будет сильно ограниченной.

> [74] DVM © (20.08.11 23:26)
> что в следующей версии ОС не исчезнет поддержка 32 бит программ

16 бит аппратно не поддерживается, так что не ОС, а процессор с новым расширением. Но 16 бит 20 лет тащили в 32 процессорах.

> DVM © (20.08.11 23:26) [74]

Есть ситуации, когда переход на новую Дельфи практически невозможен. Например, у нас очень большой проект (несколько тысяч юнитов, среди которых множество с более чем 10000 строк кода). Все это разбито на несколько сотен dll и десятки exe и служб. 90% используют БДЕ для доступа к БД, а также сторонние компоненты, причем, некоторые из них уже не поддерживаются разработчиками, хоть и были платными. Как этот зоопарк перевести на ХЕ, не переписывая почти все заного, я чета не очень себе представляю...

> 16 бит аппратно не поддерживается

Это где ?

> Inovet © (20.08.11 23:30) [75]

> 16 бит аппратно не поддерживается

ну в наше время сделать эмулятор и прозрачно встроить его в ос не проблема, но делать не стали.

> Но 16 бит 20 лет тащили в 32 процессорах.

64 бит тоже не вчера появились.

> asail © (20.08.11 23:42) [76]

> Например, у нас очень большой проект

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

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

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

> не переписывая почти все заного, я чета не очень себе представляю.
> ..

Я уже говорил, не так страшен черт. Не надо сразу все пытаться переписать. Во-первых, львиная доля (процентов 80 вменяемого кода) не нуждается ни в каких доработках. Emabarcadero все же пыталась максимально смягчить переход. Во-вторых, раз у вас куча dll - переводите их постепенно, это вполне возможно, на то они и dll.

> [73] asail © (20.08.11 23:21)

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

> Есть ситуации, когда переход на новую Дельфи практически
> невозможен. Например, у нас очень большой проект (несколько
> тысяч юнитов, среди которых множество с более чем 10000
> строк кода). Все это разбито на несколько сотен dll и десятки
> exe и служб. 90% используют БДЕ для доступа к БД, а также
> сторонние компоненты, причем, некоторые из них уже не поддерживаются
> разработчиками, хоть и были платными. Как этот зоопарк перевести
> на ХЕ, не переписывая почти все заного, я чета не очень
> себе представляю...

вообще плохо предстваляю, что это за продукт или система с десятками служб и доступом через BDE. Вроде бы службы стали активно применять после 2000 года, можно было задействовать и более современные подходы для доступу к БД.

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

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

Что за delphi такой XE? Найти похожие ветки