Ошибка Delphi XE8 в TList <T>, требуется обходной путь

Question

Ошибка Delphi XE8 в TList <T>, требуется обходной путь

38

После обновления до XE8 некоторые из наших проектов начинают разрывать данные. Похож на ошибку в реализации TList.

program XE8Bug1;
{$APPTYPE CONSOLE}

uses
  System.SysUtils, Generics.Collections;

type
  TRecord = record
    A: Integer;
    B: Int64;
  end;

var
  FRecord: TRecord;
  FList: TList<TRecord>;

begin
  FList := TList<TRecord>.Create;
  FRecord.A := 1;
  FList.Insert(0, FRecord);
  FRecord.A := 3;
  FList.Insert(1, FRecord);
  FRecord.A := 2;
  FList.Insert(1, FRecord);
  Writeln(IntToStr(FList[0].A) + IntToStr(FList[1].A) + IntToStr(FList[2].A));

end.

Этот код печатает "123" в XE7 и раньше (как и должно быть), но в XE8 он печатает "120". Может быть, кто-то знает, что это значит?

Обновление: Неофициальное исправление здесь

BofA 27 апр. 2015, в 23:33

Источник

9

Общие коллекции были повторно реализованы в XE8. Возможно, у них нет юнит-тестов в Эмбе. Если это так, как вы описываете, и кажется вероятным, ваше решение - остаться на XE7. Вам необходимо отправить сообщение об ошибке.
David Heffernan 27 апр. 2015, в 22:11
3

Отмечено как регрессия: TList <T>. Вставка не работает .
LU RD 28 апр. 2015, в 04:56
10

Так что, похоже, у Embarcadero нет эффективного режима тестирования. Как же они могли ошибиться? Такой фундаментальный класс. Хорошо разработанная команда разработчиков провела бы комплексное тестирование. Такая ошибка никогда не должна пройти это испытание. Мрачный.
David Heffernan 28 апр. 2015, в 06:14
6

И мне пришлось бы доплатить, чтобы этот (4-недельный) продукт был исправлен.
robsoft 28 апр. 2015, в 07:47
1

Связанный: stackoverflow.com/questions/30850911/… Я думаю, они решили, что никто не должен использовать Insert поэтому они никогда не проверяли это.
Jerry Dodge 15 июнь 2015, в 18:59
0

@JerryDodge, fmx.TlistView, кажется, использует TList <T> внутри с размерами T> 8. Я не удосужился узнать, использует ли какой-либо из них метод Insert хотя. Вы можете отслеживать с помощью отладчика с точкой останова в TListHelper.InternalInsertN, если хотите.
LU RD 15 июнь 2015, в 20:46
0

Это исправлено в XE8 upd 1, включая некоторые ошибки в TListHelper.
LU RD 19 июнь 2015, в 11:10

Показать ещё 5 комментариев

Теги:

generics

delphi

delphi-xe8

tlist

1 ответ

Ещё вопросы

Общие коллекции были повторно реализованы в XE8. Возможно, у них нет юнит-тестов в Эмбе. Если это так, как вы описываете, и кажется вероятным, ваше решение - остаться на XE7. Вам необходимо отправить сообщение об ошибке.
Отмечено как регрессия: TList <T>. Вставка не работает .
Так что, похоже, у Embarcadero нет эффективного режима тестирования. Как же они могли ошибиться? Такой фундаментальный класс. Хорошо разработанная команда разработчиков провела бы комплексное тестирование. Такая ошибка никогда не должна пройти это испытание. Мрачный.
И мне пришлось бы доплатить, чтобы этот (4-недельный) продукт был исправлен.
Связанный: stackoverflow.com/questions/30850911/… Я думаю, они решили, что никто не должен использовать Insert поэтому они никогда не проверяли это.
@JerryDodge, fmx.TlistView, кажется, использует TList <T> внутри с размерами T> 8. Я не удосужился узнать, использует ли какой-либо из них метод Insert хотя. Вы можете отслеживать с помощью отладчика с точкой останова в TListHelper.InternalInsertN, если хотите.
Это исправлено в XE8 upd 1, включая некоторые ошибки в TListHelper.

BofA · Accepted Answer · 2015-04-28T00-14-00.000Z

Я обнаружил, что теперь вызов метода TList<T>.Insert TListHelper.InternalInsertX зависит от размера данных, в моем случае:

procedure TListHelper.InternalInsertN(AIndex: Integer; const Value);
var
  ElemSize: Integer;
begin
  CheckInsertRange(AIndex);

  InternalGrowCheck(FCount + 1);
  ElemSize := ElSize;
  if AIndex <> FCount then
    Move(PByte(FItems^)[AIndex * ElemSize], PByte(FItems^)[(AIndex * ElemSize) + 1], (FCount - AIndex) * ElemSize);
  Move(Value, PByte(FItems^)[AIndex * ElemSize], ElemSize);
  Inc(FCount);
  FNotify(Value, cnAdded);
end;

Я вижу проблему в первом вызове Move. Назначение должно быть:

PByte(FItems^)[(AIndex + 1) * ElemSize]

not

PByte(FItems^)[(AIndex * ElemSize) + 1]

Aaargh!

Наконец, я использовал модули System.Generics.Defaults.pas и System.Generics.Collections.pas из Delphi XE7 в своих проектах, и теперь все работает как ожидалось.

Обновление: как я вижу, RTL не затрагивается, так как он не использует TList<T>.Insert для T с SizeOf > 8 (или, может быть, я что-то пропустил?)

Исправление путем восстановления реализации XE7 не такая уж плохая идея. Вы больше доверяете этому. Да, вы можете исправить этот один метод, но вам не интересно, что еще они ошиблись?
Хотя, если вы замените целые блоки, было бы разумно сделать это таким образом, чтобы RTL / VCL / FMX и т. Д. Также использовали фиксированные блоки. В противном случае вы можете пострадать от других проявлений этого дефекта.
Мантра неопытных разработчиков: «зачем заботиться о старом коде, когда вы можете писать новый код« намного лучше »» ;-) (у меня было слишком много разработчиков такого рода, и это разочаровывает, что Embarcadero у них вообще)
В RTL есть много мест, где используется TList <T> .Insert. Как же это могло пройти незамеченным?
Эта ошибка сохраняется только тогда, когда SizeOf (T)> 8, поэтому в RTL затронуты только несколько мест, большинство из которых округлены {$ IFDEF POSIX} :)
@BofA SizeOf(T)>8 и тип неуправляемый. Возможно, Emba сходит с рук, предпочитая dyn-распределенные классы автоматически распределяемым записям.