1

I alread know, that a dynamic array is automatically deallocated/freed after use. Does the same applies for resizing, especially decreasing? The manual and most help sites only cover increasing the array size.

test: array of TLabel;
SetLength(test, 10);
// fill array here
SetLength(test, 2);     // <=== are entries 3-10 are automatically destroyed?
casiosmu
  • 797
  • 1
  • 8
  • 22
  • 1
    Well, you need to be careful what you mean here. This is an array of pointers, so the memory of the array itself is managed, but that does not mean that what it points to is also destroyed. So the TLabel objects will not be automatically freed. And indeed it would be very dangerous if they were! – Dsm Feb 22 '18 at 10:09
  • ok, I understand. Thanks – casiosmu Feb 22 '18 at 10:15
  • It's not at all clear what you are asking here. You need to edit the question to clarify what you mean. – David Heffernan Feb 22 '18 at 10:19
  • 4
    @casiosmu: if you want that functionality, you need TObjectlist or TObjectlist – whosrdaddy Feb 22 '18 at 10:52
  • Just like the TLabel objects will not be automatically created, they will not be automatically freed either, **unless your compiler has ARC for objects**, i.e. mobile or Linux compilers. – Rudy Velthuis Feb 22 '18 at 19:32

1 Answers1

3

are entries 3-10 are automatically destroyed?

No, they are not automatically destroyed because those entries are dynamically allocated (and are not managed types). Only the pointers that refer to those items are released. It is your responsibility to destroy the items if necessary, because the compiler has no way to guarantee you wouldn't still use them from another reference (or have already destroyed them).

I must also point out that technically items "3-10" is wrong. Dynamic array are zero based. So the references for entries 2 to 9 are the ones released.

I alread know, that a dynamic array is automatically deallocated/freed after use

In addition, your question indicates you don't properly understand this. It seems you believed that when your array goes out of scope the labels referenced would be automatically destroyed. This is incorrect!

No matter where how or why some/all dynamic array entries are released Delphi won't automatically destroy objects types or any dynamically allocated pointer memory. Delphi only automatically releases memory for primitives (Integer, TDateTime, Double short strings), records and managed types1 (interfaces, long strings, other dynamic arrays).

1 Of course this is via reference counting. I.e. reference is reduced by 1; and the underlying object/string/array is released if and only if refCount is reduced to zero.

As whosrdaddy pointed out, if you want automatic destruction of contained objects, then you need to use a container that implements an ownership concept. TObjectList is an example. Although it doesn't work exactly like a dynamic array, it's behaviour is similar enough that it can usually be used as a replacement very easily.

Disillusioned
  • 14,635
  • 3
  • 43
  • 77
  • I think it is important to emphasisze that the memory for the *object references* is (eventually) freed, but *not the objects that they reference*.That only happens for managed references. Unless you are under ARC, an object reference is also a primitive type (in fact, a pointer). – Rudy Velthuis Feb 22 '18 at 19:30
  • 1
    @Rudy Immediately not eventually. It is freed during the call to SetLength. – David Heffernan Feb 22 '18 at 20:53
  • @david: only if SetLength actually causes a new allocation. I am not so sure whether that happens if a dynarray is actually shortened. – Rudy Velthuis Feb 22 '18 at 23:07
  • @Rudy No. The memory is freed in the sense that it is no longer available to the program. The memory manager may make certain optimisations behind the scenes but those are implementation detail. – David Heffernan Feb 23 '18 at 06:26
  • The memory manager has nothing to do with this. It is System.pas code like DynArraySetLength that governs the memory. It is not necessarily freed (returned to the memory manager), hence my use of eventually. – Rudy Velthuis Feb 23 '18 at 10:02