RadStudio XE4. Дожили...

← →
DVM © (2013-05-05 10:31) [0]

Изучаю модули новой XE4. Не знаю, к чему все идет, но по-моему ни к чему хорошему. Что заметил:
1) Тотальное избавление от указателей. Еще чуть-чуть и их запретят?
2) TList (!!!), наш, основа основ, рабочая лошадка, стал практически deprecated!
3) TMemoryStream практически deprecated, теперь вместо него TByteStream
4) Идет избавление везде от AnsiString, UnicodeString, WideString, PAnsiChar, UTF8String и т.д. в пользу простого string.
5) Везде, буквально везде TBytes (который я почему то недолюбливаю), банальный Move() приобрел странную замену в лице:

procedure MoveData(Source: TBytes; SrcIndex: NativeInt; Dest: TBytes; DestIndex: NativeInt; Count: NativeInt); overload; var Ind: NativeInt; begin Ind := 0; while Count > 0 do begin Dest[DestIndex + Ind] := Source[SrcIndex + Ind]; inc(Ind); dec(Count); end; end;

6) String теперь может индексироваться с 0 (для x86/64 опционально) !!!

← →
Игорь Шевченко © (2013-05-05 10:54) [1]

еще и with запретят

← →
DVM © (2013-05-05 11:06) [2]

> Игорь Шевченко © (05.05.13 10:54) [1]

> еще и with запретят

Да With туда и дорога, но как без указателей быть? Как без них строить высокопроизводительный код? Даже банальный record записать в стрим скоро станет проблемой, ибо (из TStream):

//{$IFNDEF NEXTGEN} function Read(var Buffer; Count: Longint): Longint; override; function Write(const Buffer; Count: Longint): Longint; override; //{$ENDIF !NEXTGEN} function Read(Buffer: TBytes; Offset, Count: Longint): Longint; override; function Write(const Buffer: TBytes; Offset, Count: Longint): Longint; override;

NEXTGEN - это новый компилятор для LLVM, пока закомментировано, но вектор развития явно обозначен.

← →
DVM © (2013-05-05 11:16) [3]

> Даже банальный record записать в стрим скоро станет проблемой,
> ибо (из TStream):

Вот такое извращение предлагается в данный момент для записи скажем record-а (обратите внимание на дополнительный Move):

procedure TStream.WriteBuffer(const Buffer; Count: Longint); var Buf: TBytes; LTotalCount, LWrittenCount: Longint; begin SetLength(Buf, Count); Move(Buffer, Buf[0], Count); { Perform a write directly. Most of the time this will succeed without the need to go into the WHILE loop. } LTotalCount := Write(Buf, 0, Count); while (LTotalCount < Count) do begin { Try to write a contiguous block of <Count> size } LWrittenCount := Write(Buf, LTotalCount, (Count - LTotalCount)); { Check if we written something and decrease the number of bytes left to write } if LWrittenCount <= 0 then raise EWriteError.CreateRes(@SWriteError) else Inc(LTotalCount, LWrittenCount); end end;

Весь код таким образом будет только и заниматься как копирование данных из/в этот TBytes где попало. Кроме увеличения потребляемой памяти и замедления программы это ни чего не дает.

← →
clickmaker © (2013-05-05 11:42) [4]

а вот зачем дополнительный Move, я совсем не понял...

← →
DVM © (2013-05-05 11:55) [5]

> clickmaker © (05.05.13 11:42) [4]

> а вот зачем дополнительный Move, я совсем не понял...

он там затем, чтобы скопировать данные из входного буфера в TBytes и затем уже вызвать метод TStream.Write принимающий параметром TBytes, т.к. вероятно старый метод Write исчезнет.

← →
clickmaker © (2013-05-05 12:06) [6]

походу, новая политика борландеров - избавление от нетипизированных параметров типа const Buffer

← →
Павиа (2013-05-05 12:08) [7]

> Весь код таким образом будет только и заниматься как копирование
> данных из/в этот TBytes где попало. Кроме увеличения потребляемой
> памяти и замедления программы это ни чего не дает.

Вы просто современные возможности компиляторов не представляете. Они могли спокойно в LLVM добавить метод, который выкенет лишнее копирование.
Но видимо процесс компиляции теперь станет длинным.

Я бы сказал им это давно надо было сделать. Еще в Delphi 8. Или до выпуска 64 битного компилятора.
Но честно им надо держать 2 языка как это делает майкрософт. Один высокоуровнивый и один низкоуровневый.

← →
DVM © (2013-05-05 12:10) [8]

> clickmaker © (05.05.13 12:06) [6]

От указателей в основном избавляются, а это уже следствие.

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

← →
DVM © (2013-05-05 12:11) [9]

> Павиа (05.05.13 12:08) [7]

> Они могли спокойно в LLVM добавить метод, который выкенет
> лишнее копирование.

хорошо если так

← →
clickmaker © (2013-05-05 12:41) [10]

> 1) Тотальное избавление от указателей. Еще чуть-чуть и их
> запретят?

насколько я понял, большая часть изменений сделана для поддержки компилятора мобильных приложений (iOS, например)

> 4) Идет избавление везде от AnsiString, UnicodeString, WideString,
> PAnsiChar, UTF8String и т.д. в пользу простого string

это как раз логично. Родной тип для ОС все-таки unicode

http://docwiki.embarcadero.com/RADStudio/XE4/en/What"s_New_in_Delphi_and_C++Builder_XE4

← →
DVM © (2013-05-05 12:47) [11]

> clickmaker © (05.05.13 12:41) [10]

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

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

> это как раз логично. Родной тип для ОС все-таки unicode

Да, но как быть там, где нужно взаимодействовать с API поддерживающими WideString, PAnsiChar и т д? Непонятно.

Кстати, вот еще по теме http://www.gunsmoker.ru/2013/05/modern-delphi.html

← →
Юрий Зотов © (2013-05-05 12:51) [12]

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

← →
NoUser © (2013-05-05 12:56) [13]

> Что заметил:
а как тогда в 6) у них поведение pos,copy,.. - тоже опционально автоматом перестраивается, или как?

> т.к. вероятно старый метод Write исчезнет.
Туда ему и дорога ;)

Это ж надо как-то новой (айдроид) программерской аудитории рассказать что такое const Buffer. А, не дай бог, кто-то из сишников осознает что это const void& Buffer, там такого айфону подымут про безопасность и стиль.

А тут сразу нескольких зайцев - и новых буковок есть у них, и указатели подальше, и, типа, контроль границы данных (length(Dest)).

← →
DVM © (2013-05-05 13:05) [14]

> NoUser © (05.05.13 12:56) [13]

> а как тогда в 6) у них поведение pos,copy,.. - тоже опционально
> автоматом перестраивается, или как?

там все хитро, см ссылку на gunsmoker-а, там у него описан этот момент.

← →
antonn © (2013-05-05 13:05) [15]

>
> Да With туда и дорога, но как без указателей быть? Как без
> них строить высокопроизводительный код?

к сожалению, нынче бизнесу все чаще нужен не высокопроизводительный код, а быстронаписанный код, с тоннами разных подключенных библиотек и слоев абстракций реализующий что надо в два нажатия и кушающий памяти как две вин98. и с паравозом зависимостей в этих самых библиотеках.
(на днях делал трассировку большого изображения в старом Корел Трейс (векторизация), кликнул кнопку и он подвис. ну, думаю, щас будет тупить.. открываю диспетчер программ и привычно ищу по объему в.памяти корел, и не нашел, он занял 35Мб. Навороченный векторный редактор обрабатывающий картинку занял 35Мб, а долбаные "переговаривалки" не подключенные к серверу Скайп и Линк жрут от 120Мб)

специально остался в дельфи на 7-й версии, для быстрогенераторов программ юзаю шарп :(

← →
antonn © (2013-05-05 13:11) [16]

> Это ж надо как-то новой (айдроид) программерской аудитории
> рассказать что такое const Buffer. А, не дай бог, кто-то
> из сишников осознает что это const void& Buffer, там такого
> айфону подымут про безопасность и стиль.
>
> А тут сразу нескольких зайцев - и новых буковок есть у них,
> и указатели подальше, и, типа, контроль границы данных
> (length(Dest)).

вчера изучал андроид с его явой, был немало удивлен и потерял время пока дошло, что вот такое там не пройдет:
String S1 = "dd"; String S2 = "dd"; if(S1==S2){ }
потому что в условии сравниваются долбаные указатели, а не данные =) до сих пор не могу понять зачем так сделали...

Ах да, в новых "дельфях" тоже ввели регистрозависимость (в написании типов, например) прошлого века? :)

← →
Юрий Зотов © (2013-05-05 13:16) [17]

> antonn © (05.05.13 13:11) [16]

Если эти три оператора идут подряд (как Вы показали), то действительно странно. А если между вторым и третьим есть что-то еще, то в третьем, вероятно, проверяется, не была ли в этом "что-то" изменена одна из строк.

← →
DVM © (2013-05-05 13:17) [18]

> antonn © (05.05.13 13:11) [16]

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

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

> Ах да, в новых "дельфях" тоже ввели регистрозависимость
> (в написании типов, например) прошлого века?

Пока не ввели.

← →
Kilkennycat © (2013-05-05 13:23) [19]

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

это правильное решение, притом, никто не запрещает сравнивать данные, если ресурсов не жалко.

← →
clickmaker © (2013-05-05 13:27) [20]

> [11] DVM © (05.05.13 12:47)

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

← →
Eraser © (2013-05-05 13:27) [21]

вот тут все написано к чему все идет
http://www.embarcadero.com/resources/white-papers?download=102

← →
DVM © (2013-05-05 13:32) [22]

> clickmaker © (05.05.13 13:27) [20]

> так указатели же никто не запрещает. Тип Pointer на месте
> и основные указательные типы тоже. То, что они в vcl их
> избегаю - ну так это их личное дело.

Не VCL, а RTL скорее. Указатели конечно не запрещены пока, даже предупреждений не выдается по умолчанию пока. Но идет планомерное избавление от классов, в основе которых используются указатели тем или иным способом. И замена их на TBytes и аналогичное по мере возможности.
Логичным продолжением будет сначала deprecated для указателей, потом и вовсе удалят.
Строки отличные от string к примеру просто удалили для LLVM версии.

← →
antonn © (2013-05-05 13:34) [23]

> Юрий Зотов © (05.05.13 13:16) [17]
>
> > antonn © (05.05.13 13:11) [16]
>
> Если эти три оператора идут подряд (как Вы показали), то
> действительно странно. А если между вторым и третьим есть
> что-то еще, то в третьем, вероятно, проверяется, не была
> ли в этом "что-то" изменена одна из строк.

да, действительно, плохой пример нарисовал, вот то на чем я споткнулся:
String S1 = "DD"; if(S1.toLowerCase()=="dd"){ }
нужно делать так:
if(S1.toLowerCase().equals("dd")){

> Kilkennycat © (05.05.13 13:23) [19]
>
>
> > сравниваются долбаные указатели, а не данные =) до сих
> пор
> > не могу понять зачем так сделали...
>
> это правильное решение, притом, никто не запрещает сравнивать
> данные, если ресурсов не жалко.

а в каких языках такое правильное решение еще есть? а то что-то дельфи, пхп, перл, шарп делают наверное не правильно...

← →
DVM © (2013-05-05 13:35) [24]

> Eraser © (05.05.13 13:27) [21]

о, спасибо за ссылку

← →
Дмитрий С © (2013-05-05 14:16) [25]

Это получается мое приложение, компилирующееся под XE3 уже не будет компилироваться под XE4?

← →
Павиа (2013-05-05 14:17) [26]

> Кстати, вот еще по теме http://www.gunsmoker.ru/2013/05/modern-
> delphi.html

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

> http://www.embarcadero.com/resources/white-papers?download=102

Теперь я понимаю что embarcadero не может провести разработку на должном уровне и будет переписывать всё по новой в следующем году. Поэтому им срочно нужны деньги на XE5.
Посмотрим как они выкрутяться в следующем году.

← →
DVM © (2013-05-05 14:22) [27]

> Дмитрий С © (05.05.13 14:16) [25]

> Это получается мое приложение, компилирующееся под XE3 уже
> не будет компилироваться под XE4?

99% вероятность, что будет под x86/x86-64. Под LLVM скорее всего не будет.

← →
DVM © (2013-05-05 14:24) [28]

> Павиа (05.05.13 14:17) [26]

> Теперь я понимаю что embarcadero не может провести разработку
> на должном уровне

А что значит на должном уровне? Им с одной стороны надо максимально быстро внедрять LLVM и мобильные платформы, с другой стороны поддерживать старый код и сделать максимально безболезненным переход. Тут сложно найти компромисс.

← →
BMW (2013-05-05 14:40) [29]

> DVM © (05.05.13 12:47) [11]
> Кстати, вот еще по теме http://www.gunsmoker.ru/2013/05/modern-delphi.html

Надо же... ембракадера наконец-то додумалась сделать свой паскаль-диез :)

← →
Eraser © (2013-05-05 14:47) [30]

> DVM © (05.05.13 14:24) [28]

да уж, будут выкручиваться, но код вида
Obj := TObj.Create; try ... finally Obj.Free; end;

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

← →
Павиа (2013-05-05 15:13) [31]

> А что значит на должном уровне? Им с одной стороны надо
> максимально быстро внедрять LLVM и мобильные платформы,
> с другой стороны поддерживать старый код и сделать максимально
> безболезненным переход. Тут сложно найти компромисс.

Так о этом и речь. Не хватает им сил что-бы сделать качественно за один год. Поэтому и пожертвовали совместимость по полной ради скорости разработки новой версии. И LLVM по нормальному прикрутить не могут так как фрон-енд весь надо переписать чтобы использовать плюшки LLVM по полной. Поэтому они и хотят IR использовать. А чтобы как-то оправдать заякнулись про мобильную платформу.

← →
знайка (2013-05-05 15:29) [32]

совместимость по полной, палка о двух концах

← →
DVM © (2013-05-05 15:42) [33]

Кстати, по тестам вот эта функция, которая повсеместно заменяет собой Move() в частности в модуле Classes медленнее почти в 20 раз !!! Это только малая толика "улучшений".

> procedure MoveData(Source: TBytes; SrcIndex: NativeInt;
> Dest: TBytes; DestIndex: NativeInt; Count: NativeInt); overload;
>

← →
Дмитрий С © (2013-05-05 16:09) [34]

Как то все печально звучит. Гонятся за зайцами.

← →
BMW (2013-05-05 16:12) [35]

> По умолчанию, в Delphi XE4 этот код покажет 2/1/1/2 на Windows и 2/2/1/2 на iOS.

и

> Уже сейчас предполагается, что строки станут неизменяемыми (т.н. immutable-строки): это означает, что строку нельзя изменить когда она была создана.

Да это просто саботаж какой-то...

← →
Anatoly Podgoretsky © (2013-05-05 16:34) [36]

Кушать хочется, но вся пища у Микрософта.

← →
Kilkennycat © (2013-05-05 17:12) [37]

> antonn © (05.05.13 13:34) [23]

> а в каких языках такое правильное решение еще есть? а то
> что-то дельфи, пхп, перл, шарп делают наверное не правильно.
> ..

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

← →
robt2 (2013-05-05 18:41) [38]

> 1) Тотальное избавление от указателей. Еще чуть-чуть и их запретят?

а зачем они батонокидателям, теперь они окончательно уверуют что трояны можно делать только на С++ :)

> deprecated

эт чо за зверь?

кароче ХЕ4 говоришь можно некачать?

← →
DVM © (2013-05-05 19:21) [39]

> robt2 (05.05.13 18:41) [38]

> > deprecated
>
> эт чо за зверь?

http://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%BF%D1%80%D0%B5%D0%BA%D0%B0%D1%86%D0%B8%D1%8F

← →
clickmaker © (2013-05-05 19:28) [40]

- доктор, у меня проблемы с депрекацией
o)

← →
картман © (2013-05-05 21:21) [41]

> Поэтому они и хотят IR использовать

что это?

← →
TUser © (2013-05-05 23:44) [42]

Как бы фрипаскаль не начал перенимать инновации.

← →
Зато мы делаем ракеты! (2013-05-05 23:56) [43]

Юрий Зотов © (05.05.13 12:51) [12]

Похоже, они специально делают несовместимость новых версий со старыми.

они это уже делали при переходе d5->d7
ну пара контор, до того сидевших на коболе и перешедших на d5, так на d5 и остались. ну и борланду или как оно там счас чё?

а остальные организованной толпой...

← →
Германн © (2013-05-06 01:14) [44]

> они это уже делали при переходе d5->d7

Не заметил такого. Об чём речь?

← →
Дмитрий С © (2013-05-06 03:08) [45]

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

Развитие фрипаскаля медленное как корова у зергов, пока дойдет до них..

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

Пс. Конечно будет большая печаль, если какой нибудь фонарик под андроид будет весить 15 метров и сотню оперативы.

← →
картман © (2013-05-06 03:25) [46]

> Конечно будет большая печаль, если какой нибудь фонарик
> под андроид будет весить 15 метров и сотню оперативы.

интел выручит))

вообще, нынешняя ИТ-индустрия напоминает нечто подобное: http://www.youtube.com/watch?v=m1zUpIZjctk

← →
Inovet © (2013-05-06 04:13) [47]

> [41] картман © (05.05.13 21:21)
> > Поэтому они и хотят IR использовать
>
> что это?

Инфракрасный

← →
Юрий Зотов © (2013-05-06 07:37) [48]

> Зато мы делаем ракеты! (05.05.13 23:56) [43]
> они это уже делали при переходе d5->d7

Лично и в одиночку переводил здоровенный проектище с D7 на D7. Заняло где-то неделю-другую - при том, что занимался еще и другими делами. Глюков после перевода выявлено не было.

Разве это несовместимость? Это так, семечки. Не сравнить с тем, что они в XE4 сотворили, судя по статье gunsmoker"а.

← →
Юрий Зотов © (2013-05-06 07:45) [49]

> antonn © (05.05.13 13:34) [23]
> if(S1.toLowerCase().equals("dd"))

if ("dd".equalsIgnoreCase(S1))

← →
antonn © (2013-05-06 08:16) [50]

> Юрий Зотов © (06.05.13 07:45) [49]

в любом случае без "==", через equals

← →
robt2 (2013-05-06 10:23) [51]

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

← →
O'ShinW © (2013-05-06 10:33) [52]

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

← →
DevilDevil © (2013-05-06 10:45) [53]

> DVM © (05.05.13 10:31)

я просто в шоке !
спасибо, что поднял тему!

p.s. а что, в мобильных платформах нет указателей ?

← →
clickmaker © (2013-05-06 12:27) [54]

> а что, в мобильных платформах нет указателей ?

да куда они денутся? Просто для CLR pointer заменили TObject, ввели ключевое слово unsafe...

← →
robt2 (2013-05-06 12:57) [55]

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

← →
DevilDevil © (2013-05-06 15:40) [56]

> clickmaker © (06.05.13 12:27) [54]

> да куда они денутся? Просто для CLR pointer заменили TObject,
> ввели ключевое слово unsafe...

моя твоя не понимать
нафига использовать подсчёты ссылок ?
пусть Java и C# используют
нам то зачем ?

нам и без них хорошо

← →
jack128_ (2013-05-06 15:47) [57]

>>p.s. а что, в мобильных платформах нет указателей ?
Есть конечно. С++ поддерживается всеми мобильными платформами.

>>нафига использовать подсчёты ссылок ?
>>пусть Java и C# используют
>>нам то зачем ?
как раз java и шарп счетчик ссылок не используют.

← →
DevilDevil © (2013-05-06 15:53) [58]

тогда не понятно, от чего столько геморроя
http://www.gunsmoker.ru/2013/05/modern-delphi.html

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

← →
DVM © (2013-05-06 16:09) [59]

> DevilDevil © (06.05.13 15:53) [58]

Если вот этот MoveData() окончательно вытеснит Move(), то можно распрощаться со скоростью.

← →
DevilDevil © (2013-05-06 16:17) [60]

> DVM © (06.05.13 16:09) [59]

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

← →
Rouse_ © (2013-05-06 19:06) [61]

Общая идеология развития ХЕ мне нравиться, но только если смотреть на нее со стороны стартап-проектов. Есть очень много полезных вещей.
Но вот что касается постоянных переписок проектов под новые веяния - это жирный минус.
В итоге мы по всей видимости остановимся на ХЕ3, дальше смысла переходить не имеет (мобильность нам не сильно нужна), а для стартап-проектов давно уже используем C#.

← →
dmk © (2013-05-06 19:46) [62]

Печально все это. На что рекомендуете переводить проекты с D7? Под X3 пробовал, вроде компилируется, но куча хинтов про строки, а хочется чтобы в ближайшие лет 10 ничего не трогать, но под Win64/32 работало. Мобильность вообще не вариант для моих полиграфических проектов.

← →
Rouse_ © (2013-05-06 20:10) [63]

> dmk © (06.05.13 19:46) [62]

Мы на 2010-о сидим, переезд с 2007-го дался очень сложно (в основном из-за строк, глюки выплывали примерно 3 месяца после переезда + 3 месяца сам переезд). Сейчас правим в свободное время модули под ХЕ3, нюансов конечно меньше, но не все так просто.
Если уж решишься - то ИМХО сразу проскочить на ХЕ3. Есть такая надежда что в следующих релизах эмбаркадера таки определиться где у них MobileStudio а где Delphi и все устаканиться...

← →
MBo © (2013-05-06 20:12) [64]

>но куча хинтов про строки
что за работа со строками? В общем-то, перевод не вызвал особых затруднений. Где низкоуровневая работа велась - string, char, pchar переименованы в AnsiXXX, где высокоуровневая - почти ничего не поменялось. Со множествами символов тоже как-то разруливается.

← →
Rouse_ © (2013-05-06 20:18) [65]

> MBo © (06.05.13 20:12) [64]
> что за работа со строками? В общем-то, перевод не вызвал
> особых затруднений

Ну хоть у кого-то счастье было :)

← →
dmk © (2013-05-06 20:24) [66]

Rouse_ © (06.05.13 20:10) [63]
Вот и думаю, дождаться X4-X5 или на X3 остановится.

MBo © (06.05.13 20:12) [64]
>что за работа со строками?
Да сложного ничего, простые старые ANSI-строки для хранения тэгов прочитанных из файлов TIFF, ICC, ICM. Пока в юникод перевел, но не очень понимаю куда все движется. Все же программирование для меня не основное занятие. Больше вызывает озабоченность за ассемблер. У меня процентов 35-40 на асме написано. В основном MMX, SSE, SSE2. Преобразования матриц. Если писать на паскале, то тормоза появляются. Видимо надо перестраивать идеологию. Вот и читаю, что ждать от будущих версий.

← →
Rouse_ © (2013-05-06 20:31) [67]

> dmk © (06.05.13 20:24) [66]

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

← →
Eraser © (2013-05-06 20:34) [68]

> dmk © (06.05.13 20:24) [66]

что значит "остановиться"? чтобы через 5 лет создавать плаксивые ветки на форуме о том, как тяжело перейти на XE10? за все время хоть какие-то реальные сложности с переходом возникали только при переходе на юникод.

> У меня процентов 35-40 на асме написано

возможно имеет смысл вынести это в отдельную библиотеку и компилировать каким-нибудь продвинутым инструментом от Intel?

← →
MBo © (2013-05-06 20:48) [69]

>Rouse_ © (06.05.13 20:18) [65]
>Ну хоть у кого-то счастье было

Специфика - проекты у меня небольшие, но много. Все сразу переводить не нужно, только по мере необходимости внести существенные изменения. Если доработки небольшие - D2006 еще на ходу

← →
dmk © (2013-05-06 20:53) [70]

>Убиваются указатели и прочее

Жуть. Кто мог предположить такое. У меня куча асма с вмешательством в классы. Сплошные указатели. Может это и ай-яй-яй, но ведь не запрещено.
Поэтому и придется всю структуру и логику переделывать.

>возможно имеет смысл вынести это в отдельную библиотеку и компилировать
>каким-нибудь продвинутым инструментом от Intel?

С асмом особых проблем не вижу. Чистые расчеты перенесу во внешние obj. Бибилотека и так в отдельном модуле. Проблема со своим классом окна. Придется видимо полностью класс пересматривать. Там столько наворочено. Видимо придется полностью свой класс писать. Все к тому и шло. Сейчас процентов 50 наследования от VCL.

>создавать плаксивые ветки
Не мои грехи. Я их этого возраста давно вышел.

← →
Павиа (2013-05-06 21:58) [71]

> Жуть. Кто мог предположить такое. У меня куча асма с вмешательством
> в классы. Сплошные указатели. Может это и ай-яй-яй, но ведь
> не запрещено.

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

← →
Inovet © (2013-05-07 04:05) [72]

> [62] dmk © (06.05.13 19:46)
> но под Win64/32 работало

> [66] dmk © (06.05.13 20:24)
> У меня процентов 35-40 на асме написано. В основном MMX, SSE, SSE2.

Так всё равно переписывать под х64. А наружу асм вынести? Не так удобно, конечно...

← →
Inovet © (2013-05-07 04:08) [73]

> [68] Eraser © (06.05.13 20:34)
> возможно имеет смысл вынести это в отдельную библиотеку

А что ещё остаётся. Вообще 35-40% кода уже как-то асм вставками и назвать сложно.

← →
Дмитрий С © (2013-05-07 04:59) [74]

Вопрос мой проигнорировали, задам еще раз.
Есть ли альтернатива этому delphi из будущего? Есть какая-нибудь среда разработки под Windows/Mac/Linux, да еще и под мобильные платформы на более менее нативном языке?

← →
Павиа (2013-05-07 08:20) [75]

В качестве такой среды фри паскаль (лазариус) неподходит?

← →
oxffff © (2013-05-07 08:40) [76]

> Дмитрий С © (07.05.13 04:59) [74]

http://www.remobjects.com/oxygene/platforms/

← →
DevilDevil © (2013-05-07 09:25) [77]

хе-хе )
продолжаю сидеть на D6 и D7 :)

← →
картман © (2013-05-07 09:56) [78]

> oxffff © (07.05.13 08:40) [76]
>
> http://www.remobjects.com/oxygene/platforms/

http://ru.wikipedia.org/wiki/Oxygene_%28%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%29
Улучшенная поддержка циклов for.

а эт что такое?

← →
Дмитрий С © (2013-05-07 15:14) [79]

> oxffff © (07.05.13 08:40) [76]

Net-ы, жавы - все не то.

> В качестве такой среды фри паскаль (лазариус) неподходит?

Он с трудом до уровня delphi 5 дотягивает.

← →
DVM © (2013-05-07 15:56) [80]

> Дмитрий С © (07.05.13 15:14) [79]

> Он с трудом до уровня delphi 5 дотягивает.

Смотря в чем. Дженерики там есть, юникод есть, компилит под все платформы даже с GUI. Многие другие вещи которые появились не так давно тоже поддерживает, например inline и т.д. Но во многом сильно отличается от Delphi.

← →
Дмитрий С © (2013-05-07 16:36) [81]

С этим согласен, но среда разработки (лазарус) слабая.
Многие модули очень слабые, например http server.
Много внезапных багов. Например, TStringList.Write в середину стрима обрежет его.

← →
Дмитрий С © (2013-05-07 17:14) [82]

А еще такой вопрос о будущих объектах:
В таком коде:
var I: TSomeObject; begin I := TSomeObject.Create; I.SomeMethod(); // <-- Строка 5 ... // Тут код, который не использует, либо переопределяет I. end;
Неужели компилятор не сможет догадаться, что после строки 5 можно уже освободить объект?

← →
Rouse_ © (2013-05-07 20:00) [83]

> Неужели компилятор не сможет догадаться, что после строки
> 5 можно уже освободить объект?

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

← →
Дмитрий С © (2013-05-08 19:40) [84]

> Rouse_ © (07.05.13 20:00) [83]

Теоретически экономнее к памяти.

← →
Rouse_ © (2013-05-08 22:58) [85]

> Дмитрий С © (08.05.13 19:40) [84]
> Теоретически экономнее к памяти.

Врятли, ибо это приведет не к экономии, а к ее фрагментации, что на порядок хуже.

← →
Eraser © (2013-05-09 01:18) [86]

> Rouse_ © (07.05.13 20:00) [83]

> Один в один с интерфейсами-ж будет.

кстати да, в принципе, ARC они могли повсеместно внедрить еще в далеком 1999.

← →
TUser © (2013-05-09 01:29) [87]

Дмитрий С © (07.05.13 04:59) [74]

Я вот думаю, новый проект никакой на Delphi не начну. Python или Java, скорее всего. И FAR )) для отладки - какой-нибудь эклипс. Потому что миллион леммингов не ошибается, имхо. И этот миллион леммингов создал больше, чем все замечательные программисты на Delphi, хоть он и крут.

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

← →
Плохиш © (2013-05-09 22:44) [88]

> Неужели компилятор не сможет догадаться, что после строки
> 5 можно уже освободить объект?

Какое отношение имеет компилятор к сборщику мусора?
Ознакомились бы сначала с предметом, который берëтесь обсуждать.

← →
NoUser © (2013-05-10 00:27) [89]

Хм, посмотрел свежий Lazarus/fpc2.6.2 - очень позитивные впечатления(!), если что (with c pointer"ом забанят) - буду съезжать :)

> DVM © (07.05.13 15:56) [80]
> Но во многом сильно отличается от Delphi.

Сильно отличаются IDE ? , или и синтаксис - с {$mode delphi} дженерики, вроде, один в один.

> TUser © (09.05.13 01:29) [87]
> Я вот думаю, новый проект никакой на Delphi не начну. Python
> или Java, скорее всего

Вы это серьезно?

← →
Дмитрий С © (2013-05-10 02:07) [90]

> Какое отношение имеет компилятор к сборщику мусора?
> Ознакомились бы сначала с предметом, который берëтесь обсуждать.

1. В Delphi нет сборщика мусора, "Ознакомились бы сначала с предметом, который берëтесь обсуждать".
2. Именно компилятор решает когда нужно освобождать переменную, требующую освобождения. Сейчас это делается при выходе из процедуры или функции.

← →
Дмитрий С © (2013-05-10 02:22) [91]

Точнее, конечно, не освобождать, а финализировать.

← →
Германн © (2013-05-10 03:01) [92]

> Дмитрий С © (10.05.13 02:07) [90]
>
>
> > Какое отношение имеет компилятор к сборщику мусора?
> > Ознакомились бы сначала с предметом, который берëтесь
> обсуждать.
>
> 1. В Delphi нет сборщика мусора, "Ознакомились бы сначала
> с предметом, который берëтесь обсуждать".
> 2. Именно компилятор решает когда нужно освобождать переменную,
> требующую освобождения. Сейчас это делается при выходе
> из процедуры или функции.
>

???

Бред. Сборщик мусора работает в ран-тайм, когда компилятор давно уже спит мёртвым сном. Компилятор физически не может определить, когда "нужно освобождать переменную"! Ибо он не может сам найти все ссылки на неё, которые будут созданы в рантайм.
Но вроде в XE4 и далее сборщик мусора будет реализован.

← →
Игорь Шевченко © (2013-05-10 09:59) [93]

> Неужели компилятор не сможет догадаться, что после строки
> 5 можно уже освободить объект?

Не дай бог, если компилятор начнет догадываться о намерениях всех быдлокодеров

← →
Дмитрий С © (2013-05-10 12:50) [94]

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

Он же выполняет оптимизацию. И ничего! Никто не умер еще.

> Бред. Сборщик мусора работает в ран-тайм, когда компилятор
> давно уже спит мёртвым сном. Компилятор физически не может
> определить, когда "нужно освобождать переменную"! Ибо он
> не может сам найти все ссылки на неё, которые будут созданы
> в рантайм.

А никто и не спорит, компилятор ничего не ищет. Но именно компилятор решает где будет находится I._Release, FinalizeRecord или типа того, в зависимости от типа, это и есть финализация. Именно он может решить выполнить финализацию в конце процедуры или сразу после последнего использования переменной в процедуре.
Про сборщик мусора в delphi это уже другой разговор. Мне не понятно зачем он нужен delphi в прямом его смысле.

← →
NoUser © (2013-05-10 13:51) [95]

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

TTest = class class var sa: array of String; class constructor Init; class destructor Done; end; class constructor TTest.Init; begin SetLength(sa,1); sa[0]:="Test" ; end; class destructor TTest.Done; begin Finalize(sa[0]); // AV - sa уже растаял. Finalize(sa); end;

← →
Kilkennycat © (2013-05-10 16:07) [96]

> NoUser © (10.05.13 13:51) [95]

оптимизатор не увидел использование

← →
Kilkennycat © (2013-05-10 16:12) [97]

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

← →
DVM © (2013-05-10 17:27) [98]

Нет в Delphi сборщика мусора (такого как в .Net например) и не будет в ближайшем времени. Подсчет ссылок и автоматическое разрушение объектов при достижении счетчиком нужного значения - это далеко не сборщик мусора.

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

← →
Kilkennycat © (2013-05-10 17:38) [99]

> потребует вероятно нескольких проходов и снизит скорость
> компиляции.

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

← →
DVM © (2013-05-10 17:43) [100]

> NoUser © (10.05.13 00:27) [89]

>
> Сильно отличаются IDE ? , или и синтаксис - с {$mode delphi}
> дженерики, вроде, один в один.
>

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

← →
DVM © (2013-05-10 17:52) [101]

> Kilkennycat © (10.05.13 17:38) [99]

> большинство компиляторов для мк

мк - это микроконтроллеры что ли?
Во FreePascal тоже есть 4 уровня оптимизации, но как это связано и связано ли с числом проходов я не знаю.

← →
Kilkennycat © (2013-05-10 18:12) [102]

> мк - это микроконтроллеры что ли?

ага

← →
NoUser © (2013-05-10 23:56) [103]

> DVM © (10.05.13 17:43) [100]
Ясно, спасибо.
Ну я стандартными либами особо не пользуюсь, да и сеть своя.
Посмотрел, что интересовало, - собралось, запустилось - доволен.
А вот раньше смотрел, до XE2, с прицелом на х64, - не особо.
Да, и к Unicode GUI уже привык.

> Kilkennycat © (10.05.13 16:07) [96]
> оптимизатор не увидел использование

Да нет, такое поведение и в справке описано, но вот почему так, ведь не очень то логично?

Порадовался за class constructor/destructor, вот думаю, initialization/finalization можно и убрать, -
а там такую свинку подложили, пришлось выкрутится через указатель на динамическую переменную и вспомнить про New/Dispose

Кстати, как там в XE4, initialization/finalization и New/Dispose также deprecated или еще живы?

> и вообще, разве можно так уничтожать элемент массива? мне
> почему-то кажется, что это приведет к разрушению массива.

А как можно, вроде нормальная практика?

← →
Kilkennycat © (2013-05-11 00:03) [104]

>
> А как можно, вроде нормальная практика?

нормальная практика, как мне казалось, финализировать объект, содержащийся в элементе массива.

← →
Дмитрий С © (2013-05-11 01:16) [105]

> А как можно, вроде нормальная практика?

Вручную элементы массива нельзя финализировать в общем случае. Они финализируются сами при финализации или при обрезе массива.

← →
NoUser © (2013-05-11 16:02) [106]

> нормальная практика, как мне казалось, финализировать объект,
> содержащийся в элементе массива.

Ну вот, в элементе массива, в данном случаи - sa[0], и содержится объект, в данном случаи - String.

> Дмитрий С © (11.05.13 01:16) [105]
> Вручную элементы массива нельзя финализировать в общем случае.
> Они финализируются сами при финализации или при обрезе
> массива.

В общем случае, содержимое элементов динамического массива нужно финализировать вручную.
В случаи со следующими типами содержимого массива
tkLString tkWString tkUString tkVariant tkArray tkRecord tkInterface tkDynArray
финализация будет выполнена под капотом.

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

----------------------------
Перефразирую свой вопрос:

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

TTest = class class var Sa: array of String; class constructor Init; class destructor Done; end; class constructor TTest.Init; begin SetLength(Sa,123); end; class destructor TTest.Done; begin if ( Length(Sa) = 0 ) then ??? end;

← →
Дмитрий С © (2013-05-11 19:13) [107]

> В приведенном примере ручная финализация избыточна (сплю
> я так спокойнее) , но не нельзяшная.

Нельзяшная, т.к. в итоге ты получишь двойную финализацию, а это AV.

← →
NoUser © (2013-05-11 23:11) [108]

> Нельзяшная, т.к. в итоге ты получишь двойную финализацию,
> а это AV.

Ага.
function AvTest:String; var i : Integer; id: TGUID; s : String; begin CreateGUID(id); s:=GUIDToString(id); try for i := 1 to 100500 do Finalize(s); s := "Хух, пронесло!" except s := "Ай, ну больно же, больше так не буду."; end; Result:=s; end;

← →
jack128_ (2013-05-11 23:43) [109]

> Нельзяшная, т.к. в итоге ты получишь двойную финализацию,
> а это AV.

двойная файнализация - это никогда не AV.

← →
Cobalt © (2013-05-13 10:07) [110]

А в BC++ x64 уже строки иммутабельны? Он же на LLVM вроде как...

← →
Cobalt © (2013-05-13 11:22) [111]

Кстати, на XE4 что 32 что 64 бит прекрасно собирается
program ConsoleTest; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils; var s: AnsiString; begin try SetLength(s, 4); s[2] := "Я"; Writeln(s); Readln; except on E: Exception do Writeln(E.ClassName, ": ", E.Message); end; end.

← →
Cobalt © (2013-05-13 11:23) [112]

Да, кстати, буква "Я" там - второй символ.

← →
DVM © (2013-05-13 11:43) [113]

> Cobalt © (13.05.13 11:22) [111]
> Кстати, на XE4 что 32 что 64 бит прекрасно собирается

Так оно и должно. А вот если так:
{$ZEROBASEDSTRINGS ON}

← →
Cobalt © (2013-05-13 12:02) [114]

Я проверял на Win-платформе.
Если понадобится писать под IOS или MAC, то полюбому придется много чего переписывать (ассемблерные вставки, защита эл. ключом, обращение к портам, работу с сокетами)

← →
Дмитрий С © (2013-05-13 14:50) [115]

> NoUser ©

Убедил.

← →
jack128_ (2013-05-13 15:37) [116]

> А в BC++ x64 уже строки иммутабельны? Он же на LLVM вроде
> как...

маловероятно. По стандарту С++ - std::basic_string - мутабельная. Про иммутабельность строк - это заморочки эмбаркадеро, а не LLVM

> [116] jack128_ (13.05.13 15:37)
> мутабельная ... иммутабельность

Чем дальше в лес, тем страшнее слова.

Интересно откуда взялся такой синтаксис:
TComponent = class(TPersistent, IInterface, IInterfaceComponentReference) private [Weak] FOwner: TComponent; FName: TComponentName; FTag: NativeInt;

Логичнее же для паскаля было бы:
TComponent = class(TPersistent, IInterface, IInterfaceComponentReference) private FOwner: TComponent; weak; FName: TComponentName; FTag: NativeInt;

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

Как это непонятно? Ни на что как на атрибут это не похоже. Никого же не смущают, например, virtual для методов.

> то непонятно это метод или атрибут

а что, procedure или function уже необязательно? )

← →
Blaise (2013-05-19 11:43) [123]

Дмитрий С © (17.05.13 02:38) [118]

Интересно откуда взялся такой синтаксис:

Это ужасно. Серьезно.
Delphi все сильнее и сильнее уходит от лаконичного Pascal.
Интересно, в этом черном ящике с надписью Эмбаркадеро есть хоть кто-то разумный и последовательный, кто курирует работы по расширению и стилистике языка?
А то получится как у Паганеля, который вместо испанского изучал португальский. Через несколько лет разработчики компилятора внезапно откроют для себя, что, оказывается, все эти годы они должны были разрабатывать Pascal.

>> Blaise (19.05.13 11:43) [123]
А поподробнее?

> А поподробнее?

Смотри [118]

> Blaise (19.05.13 11:43) [123]

напомнило бородатый анекдот )

В публичный дом приходит посетитель — стра-а-ашный, аж жуть! Без содрогания сердца на такого и не взглянешь. Но что делать! И мадам отправляет к нему девушку. Через пару минут девушка пулей вылетает из комнаты и буквально слетает по лестнице, на ходу причитая: "Ужас! Ужас! Ужас!".

Тогда мадам отправляет к нему вторую девушку. Через минуту-другую сцена повторяется: девица чуть не кубарем слетает с лестницы, шепча в страхе: "Ужас! Ужас! Ужас!"

Мадам отправляет к нему третью девушку, но исход тот же: "Ужас! Ужас! Ужас!"

Что делать! Желания клиента — закон. И Мадам отправляется к нему сама. Девицы со страхом сгрудились внизу в ожидании того, что же сейчас произойдет. Но проходит две минуты, пять минут, десять, пятнадцать... В конце концов через двадцать минут мадам выходит из комнаты, победоносно спускается по лестнице и обращается к своему трудовому коллективу: "Ну, что?! Ну, да! Ну, ужас! Но не "ужас-ужас-ужас"!" :)

← →
jack128_ (2013-05-21 11:44) [127]

2дмитрий с.
В 118 предлагается ввести новое ключевое слово, вместо того, чтоб использовать уже существующую возможность языка. Чем это лучше то? Бенефиты по читабельности, на мой взгляд весьма сомнительны.

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

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

← →
jack128_ (2013-05-22 10:41) [130]

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

← →
jack128_ (2013-05-22 10:56) [132]

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

← →
ТимоховД (2013-05-22 16:15) [134]

по моим ощущениям, нет смысла переходить от дельфи 2007 (тем более от "семерочки") на что-то новое. вернее, можно перейти на Уникод. И все. Дальше, уже не надо - это просто новый язык какой-то, а не дельфи. с тем же успехом можно все переписать на другом языке - разницы не вижу.

← →
ТимоховД (2013-05-22 16:15) [135]

> ТимоховД (22.05.13 16:15) [135]

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

Получается дженерики ради дженериков. Ужас-ужас-ужас:)

не появились ли еще ++, += и т.д.?

Во фрипаскале что-то из этого уже есть:)

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

Не использовать что-то полезное из чистого принципа, без веских причин - это, конечно, глупо.

Но если человек умеет хорошо кодить, то он и дженерики легко освоит. А если не умеет, то и дженерики ему не помогут.

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

> если человек умеет хорошо кодить, то он и

без дженериков такого накодит...

> Eraser © (22.05.13 18:58) [136]
>
>
> > ТимоховД (22.05.13 16:15) [135]
>
> никто не мешает писать, не используя новый возможности.
> хотя, лично я такого человека, который упорно не желает
> использовать те же дженерики, гнал бы в шею.

Не дотянешься до моей шеи!
:)

Вот-вот, давайте поспорим еще и на тему "что такое "хорошо кодить"". И на тему "что значит "освоить дженерики"".

А то ветка недостаточно длинная, всего каких-то жалких полторы сотни постов.

> Юрий Зотов © (23.05.13 12:52) [147]
>
> Вот-вот, давайте поспорим еще и на тему "что такое "хорошо
> кодить"". И на тему "что значит "освоить дженерики"".

Если начальная посылка ("Но если человек умеет хорошо кодить, то он и дженерики легко освоит") совершенно не несет ни капли смысла, то спорить не о чем :)

← →
ТимоховД (2013-05-23 13:30) [149]

Коллеги (прошу извинить админов за дубль или трипль - видимо вебпрокси на работе задваивает-затраивает).

Не в дженериках дело. Конечно, использовал бы.
Проект дюже большой у меня, а я сейчас один)))
Жалко год на то, чтобы переводить с большими переписками.
Хотя... придется когда-то. А то совсем отстану.

Трансляция семинара у кого-нибудь работает?
http://softwarepeople.ru/delphixe4/

>DVM
Ясно (что ничего не ясно). У меня и соседей только колесико (загрузки?) крутится. Браузеры разные.

← →
Exception (2013-05-23 13:56) [153]

Mozilla Firefox 20.0.0.1 трансляция работает

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

> ТимоховД (23.05.13 13:30) [149]
>
> Не в дженериках дело. Конечно, использовал бы.
> Проект дюже большой у меня, а я сейчас один)))
> Жалко год на то, чтобы переводить с большими переписками.

Так зачем целенаправленно переводить-то? Можно использовать в новом коде или при случае при рефакторинге старого.

> Kerk © (23.05.13 13:08) [148]

> Если начальная посылка ("Но если человек умеет хорошо кодить, то он и
> дженерики легко освоит") совершенно не несет ни капли смысла, то спорить
> не о чем :)

Да если даже и несет, то спорить все равно не о чем. Даже если кто-то этой посылки не понял. Его проблемы, isn"t it?

да уж, мягко скажем, выбесил меня такой момент

TIdBytes = array of Byte; ... TBytes = TArray<Byte>;

тоже мне умники )

Ch := Str[Low(string)];
О-как!

← →
robt5 (2013-06-12 18:59) [160]

кто такой дженерик и как люди так долго жили без него?

← →
Василий Бабаев (2013-09-03 13:20) [161]

просто идет зговор производителей омпиляторов с производителями железа, вот вам и все! Аеще пару лет назад ругали 7 версию делфи за 300кб формы))) получайте XE4)))

← →
Василий Бабаев (2013-09-03 13:20) [162]

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

← →
Василий Бабаев (2013-09-03 13:20) [163]

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

← →
Василий Бабаев (2013-09-03 13:20) [164]

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

← →
Василий3446344 (2013-09-03 13:20) [165]

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

RadStudio XE4. Дожили... Найти похожие ветки