Страницы: 1 2 3 4 5 вся ветка
Форум: "Прочее";
Поиск по всему сайту: delphimaster.net;
Текущий архив: 2014.02.16;
Скачать: [xml.tar.bz2];




Вниз

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)




Страницы: 1 2 3 4 5 вся ветка
Форум: "Прочее";
Поиск по всему сайту: delphimaster.net;
Текущий архив: 2014.02.16;
Скачать: [xml.tar.bz2];




Наверх





Память: 0.83 MB
Время: 0.223 c
15-1378280205     Empleado              2013-09-04 11:36  2014.02.16  
Frederik Pohl


2-1365823333      NBAH1990              2013-04-13 07:22  2014.02.16  
idhttp проблема с кодировкой


2-1366625537      novai                 2013-04-22 14:12  2014.02.16  
проблемма с BorderStyle:= bsNone;


2-1365771933      novai                 2013-04-12 17:05  2014.02.16  
TStringList дефолтное значение


2-1365138690      alexdn                2013-04-05 09:11  2014.02.16  
Сохраненеие картинки из paintbox