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

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

> 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]

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

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

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

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

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

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

и

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

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

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

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

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

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

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

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

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

> deprecated

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

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

> 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

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

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