> Тимохов Дима ©   (13.09.16 20:39) [16]
>
> Все больше хочется быть новичком, у которого есть мануал как сделать то-то и то-то и все.


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

> Kerk ©   (13.09.16 14:11) [8]
>
> С другой стороны, перенос проекта из D2007 в новые версии
> может быть очень болезненным. Такой опыт тоже был. Но тоже
> успешный в итоге.

Добавлю своё имхо. Непрограммиста, но пофигиста широкого профиля. Перенос проекта из Д2007 (а мои дельфийские проекты на нем и сидят до сих пор) в новые версии Дельфи разделяется на две сущности/проблемы.
Первая это переход с ANSI на Юникод. При отсутствии в проекте сторонних компонент и проблема сия отсутствует. При наличии сторонних компонент иногда вызывает проблемы, но сравнительно легко решаемые.
Вторая - многоплатформенность. Вот тут уже действительно могут быть проблемы. Переход с VCL на FMX простой заменой не выполнишь.

> Германн ©   (14.09.16 01:28) [21]


> Переход с VCL на FMX простой заменой не выполнишь.

На FMX переходить никто не заставляет в новых версиях.

Но Дима об этом тоже спрашивал.

> Германн ©   (14.09.16 01:55) [23]
> Но Дима об этом тоже спрашивал.

это для нового проекта.

Про уникод. На самом деле ты не совсем прав. Сторонних компонент нет, но есть что-то типа


Когда-то такой подход был удобен, чтобы "бегать" по байтам в памяти. Я лично так не писал никогда (предвидел, что будет Ж). Но у нас в проекте есть подобный код, и не мало.
Так, что с уникодом тоже придется повозиться в своих исходниках.

> Тимохов Дима ©   (14.09.16 01:59) [24]
>
>
> > Германн ©   (14.09.16 01:55) [23]
> > Но Дима об этом тоже спрашивал.
>
> это для нового проекта.
>
> Про уникод. На самом деле ты не совсем прав. Сторонних компонент
> нет, но есть что-то типа
> var
>   p: PChar
> begin
>   p := p+1.
>   ...
> end.
> Когда-то такой подход был удобен, чтобы "бегать" по байтам
> в памяти. Я лично так не писал никогда (предвидел, что будет
> Ж). Но у нас в проекте есть подобный код, и не мало.
> Так, что с уникодом тоже придется повозиться в своих исходниках.
>

А что такой код не работает в юникодных версиях Дельфи?
Казалось бы что сей код изначально должен бегать по символам (Char), а не по байтам.
Сам сейчас проверить не могу.

Или что мешает массово заменить объявление PChar на PAnsiChar?

Note: AnsiChar is used by the Delphi desktop compilers, but is not supported by the Delphi mobile compilers. Так что тож, просто замена не для всех.

> А что такой код не работает в юникодных версиях Дельфи?Казалось
> бы что сей код изначально должен бегать по символам (Char),
>  а не по байтам.

XE10.1 код бегает по Char, т.е +2 байта.
Для бега по байтам есть PByte, только включить арифметику указателей {$POINTERMATH ON}. Проверил по умолчанию включена.


> Warning: Do not cast non-character pointer types to PAnsiChar
> to do pointer arithmetic. Instead, use the PByte pointer
> type, which is declared with the {$POINTERMATH ON} compiler
> directive.

> Переход с VCL на FMX простой заменой не выполнишь.

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

> для профи вообще ничего не надо, на то он и профи. а если
> профи читает, то он уже не профи, а новичек.

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

> Pavia ©   (14.09.16 07:37) [30]
> Основное умение которое учат в вузе это умение собирать материал.

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

> Гораздо выгоднее учиться на чужих ошибках, а не на своих.

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

> И профи тем и отличается от новичка что умеет быстро учиться.

Не спорю. О времяпровождении я примерно так же говорил.

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

Программирование абсолютно техническая наука, по крайней мере сегодня.
А суть в любых книгах передается словами и картинками, это как бы в определении книги заложено. И если в гуманитарной или же художественной литературе суть может быть между строк, разная по одной теме и как угодно ещё, то в технической она буквальна, так как 2*2 =4 независимо от политики, погоды и предпочтений автора.

Ща подумалось:почему вообще так говорят: "учиться на чужих ошибках"?
Разве учиться на чужих успехах не выгодней?
Да и те же книжки взять, по программированию, там же не пишется, что вот если вы сбацаете так - будет ошибка, если попробуете так - будет тоже ошибка... и еще двадцать восемь вариантов приведут к ошибкам, так что пишете так - будет хорошо :)
Представляю книжку для радиомонтажника:
"Следует помнить, что большинство клеевых составов, используемых для монтажа деталей, приведут к ошибке. Лучше паять".

> "Следует помнить, что большинство клеевых составов, используемых
> для монтажа деталей, приведут к ошибке. Лучше паять".


Возможно, токопроводящим клеем можно что-то склеить :)


> Разве учиться на чужих успехах не выгодней?


Отрицательный эффект от неуспеха меньше, чем от повторения ошибки, не ?

Представил себе сапера: "Не, не буду я учиться на чужих ошибках, я уж лучше на своих" :)

> Игорь Шевченко ©   (14.09.16 11:22) [33]

я поэтому и напечатал "... большинство клеев" ;)


> Отрицательный эффект от неуспеха меньше, чем от повторения ошибки, не ?

наверное. и наверное, тут просто всего должно быть в меру.


> Внук ©   (14.09.16 14:04) [34]

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

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

> Тимохов Дима ©   (14.09.16 01:59) [24]
>
> Про уникод. На самом деле ты не совсем прав. Сторонних компонент
> нет, но есть что-то типа
> var
>   p: PChar
> begin
>   p := p+1.
>   ...
> end.
> Когда-то такой подход был удобен, чтобы "бегать" по байтам
> в памяти. Я лично так не писал никогда (предвидел, что будет
> Ж). Но у нас в проекте есть подобный код, и не мало.

Такой подход удобен если использовать PByte() как "все правильные пацаны", а не брать ахинею из книжек Миши Фленова.
Оть читал бы правильные книги - небыло бы такого кода :)

> Pavia ©   (14.09.16 07:25) [29]
>
>
> > Переход с VCL на FMX простой заменой не выполнишь.
>
> А какие подводные камни?

Ну не знаю правильно ли тут использовать термин "подводные камни", но мне при написании того ответа вспомнилось. Использовался в одном проекте TStringGrid. И в нем (проекте) часто использовались свойства TStringGrid.Cols и TStringGrid.Rows. А при переносе проекта на FMX выяснилось что в FMX у TStringGrid таких свойств нет! Есть только Cells и ничего более.

> Германн ©   (15.09.16 01:19) [38]

какой может быть перенос UI с VCL на FMX вообще? вы о чем?
с горем пополам еще можно перенести какой-то код, не связанный с UI и платформой, и то там куча проблем может возникнуть. например ARC.

вообще для меня главная загадка, почему под Mac используется FMX, но ARC нет, хотя, вопрос конечно риторический.