[lmikle]

Динамические массивы используются, когда заранее неизвестно кол-во элементов. В принципе, для любого типа можно использовать списки, НО! для простых типов, не указателей, надо специально создавать указатель и выделять память, что ведет еще к большей фрагментации памяти. Хотя для динамического массива возможны скрытые расходы на получение нового блока памяти и копирование элементов из старого в новый массив.

А вообще, можно любую синтаксическую конструкцию использовать так, что захочется руки оторвать. И что теперь, минимизировать возможности языков?

[Freeman]

Сообщение от lmikle

И что теперь, минимизировать возможности языков?

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

[Aristarh Dark]

Сообщение от Freeman

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

Ага, пусть компилятор сам думает. C# получится тогда, или ПыХыПы

[angvelem]

Сообщение от Freeman

.. какой-нибудь механизм финализации...

Finalize и SetLength(xx, 0) никто не отменял.

[Freeman]

Сообщение от angvelem

Finalize и SetLength(xx, 0) никто не отменял.

Я не проводил опытов, но из справки вижу, что деструкторы в них не вызываются.

[angvelem]

И не должны, так при создании динамического массива и Create не вызывается. Он просто не существует.

[M.A.D.M.A.N.]

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

[Freeman]

Сообщение от angvelem

при создании динамического массива и Create не вызывается.

Ломать -- не строить, как говорят в народе. Структуры данных и объекты могут создаваться сколь угодно сложно, но способов уничтожения всего два -- FreeMem и TObject.Free. На это намекает и единственность деструктора при широком использовании перегрузки конструкторов.

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

Код:

type
  TObjects = array of class TObject; // первый вариант

Сообщение от M.A.D.M.A.N.

массивы - это наследие из паскаля, в котором не было понятия объекта.

В теме речь про динамические массивы. К статическим у меня претензий нет. Динамические массивы были добавлены именно в Delphi, да не сразу, а где-то в 3-4-й версии, став расширением реализации AnsiString на произвольный тип данных.

[PhoeniX]

Хорошо. Поставим задачу так:
У нас есть какие-то объекты, которые мы как-то создали. И есть массив. Динамический. Мы добавляем в него эти объекты. Созданные ранее. А потом удаляем из этого массива. Вопрос: объекты должны удалиться? Ответ - нет.

Массив - в данном случае просто список чего угодно. array of integer - динамический массив чисел. array of string - динамический массив строк. array of TPoint - динамический массив точек на плоскости (при этом TPoint есть record, а не class).

А array of TObject - это массив объектов. И программист сам должен заботиться о создании и уничтожении этих объектов.

[M.A.D.M.A.N.]

Не вариант?

Код:

type
  IMyIntf = interface
  ['{D5901C23-79CD-45A7-904B-5966ACE5ACCF}']
  end;

  TMyIntfClass = class(TInterfacedObject, IMyIntf)
  private
  public
    destructor Destroy; override;
  end;

procedure TForm1.btn1Click(Sender: TObject);
var
  foo: array of IMyIntf;
  i: Integer;
begin
  SetLength(foo, 4);
  for i := 0 to 3 do
    foo[i] := TMyIntfClass.Create;
end;

{ TMyIntfClass }

destructor TMyIntfClass.Destroy;
begin
  ShowMessage('destructed');
  inherited;
end;

"К массивам интерфейсов у меня претензий нет" expected;

Код:

procedure _FinalizeArray(p: Pointer; typeInfo: Pointer; elemCount: Cardinal);
{$IFDEF PUREPASCAL}
var
  FT: PFieldTable;
begin
  if elemCount = 0 then Exit;
  case PTypeInfo(typeInfo).Kind of
    tkLString: _LStrArrayClr(P^, elemCount);
    tkWString: _WStrArrayClr(P^, elemCount);
    tkVariant:
      while elemCount > 0 do
      begin
        _VarClr(PVarData(P)^);
        Inc(Integer(P), sizeof(Variant));
        Dec(elemCount);
      end;
    tkArray:
      begin
        FT := PFieldTable(Integer(typeInfo) + Byte(PTypeInfo(typeInfo).Name[0]));
        while elemCount > 0 do
        begin
          _FinalizeArray(P, FT.Fields[0].TypeInfo^, FT.Count);
          Inc(Integer(P), FT.Size);
          Dec(elemCount);
        end;
      end;
    tkRecord:
      begin
        FT := PFieldTable(Integer(typeInfo) + Byte(PTypeInfo(typeInfo).Name[0]));
        while elemCount > 0 do
        begin
          _FinalizeRecord(P, typeInfo);
          Inc(Integer(P), FT.Size);
          Dec(elemCount);
        end;
      end;
    tkInterface:
      while elemCount > 0 do
      begin
        _IntfClear(IInterface(P^));
        Inc(Integer(P), 4);
        Dec(elemCount);
      end;
    tkDynArray:
      while elemCount > 0 do
      begin
        _DynArrayClr(P);
        Inc(Integer(P), 4);
        Dec(elemCount);
      end;
  else
    Error(reInvalidPtr);
  end;
end;

Можно финалайзаррэй на свой подменить.

[M.A.D.M.A.N.]

Кстати, попутно в ХЕ5 баг нашел, еще в пятницу на работе обнаружили странное поведение у TValues с объектами, дак вот, смысл в том, что дельфи ХЕ5 класс-наследник от TObject определяет как UString и пытается с ним как со строками работать, соответственно выдает ошибки

[NumLock]

да, странно что компилятор не вызывает конструкторы при инициализации динмассива объектов и деструкторы при финализации. как легко было б программистам

[Freeman]

Сообщение от PhoeniX

А array of TObject - это массив объектов. И программист сам должен заботиться о создании и уничтожении этих объектов.

Хорошо. Я страшную вещь спрошу: чем динамический массив отличается от статического? Возможностью установки размера во время выполнения, не так ли? И размер ведь можно не только увеличивать, но и уменьшать. Тогда получается, что абсолютно штатный вызов абсолютно штатной SetLength приведет к утечке памяти. Это больше на Си похоже, где в каждой строчке подстава может быть, не?

Сообщение от M.A.D.M.A.N.

"К массивам интерфейсов у меня претензий нет" expected;

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

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

[angvelem]

Сообщение от Freeman

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

А ты посмотри модуль system.pas и поймёшь, что никакой утечки не будет. Если и это не убедит, воспользуйся, к примеру, программой AQTime.

[poli-smen]

Сообщение от Freeman

Хорошо. Я страшную вещь спрошу: чем динамический массив отличается от статического? Возможностью установки размера во время выполнения, не так ли? И размер ведь можно не только увеличивать, но и уменьшать. Тогда получается, что абсолютно штатный вызов абсолютно штатной SetLength приведет к утечке памяти. Это больше на Си похоже, где в каждой строчке подстава может быть, не?

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

Сообщение от Freeman

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

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