caseih wrote:I'm not sure what you mean about "free for real." When you use FB delete, memory is released--it *is* freed for real. The pointers that may have pointed to the memory have nothing to do with that. The OS can't help it if you try to refer to some memory that you shouldn't be. FB is not FreePascal; don't assume that FreePascal's idioms and ways of doing things are going to be the same in FB, or C, C++, or even Java.
(somebody called, but I didn't hear till half an year later :-)
Anyway, Delphi (and FPC) has several memory strategies, in decreasing order of usage:
- The base is manual memory management simple allocate() and deallocate(). Very old FPCs (<1998) were TP compatible in the sense that deallocate required the exact size in bytes to deallocate, but since Delphi compatibility emerged, this is managed internally (as in the heap manager keeps track of the block size and just freeing it is good enough, the heapmgr will know the size, size arguments are ignored)
- Some types are reference counted (strings, dynamic(ly sized) arrays and interfaces. Less bother for the user, but not a fundamentally different strategy.
- COM objects have their lifetime management overridden so that the refcount and allocation happens in COM space. However this is often hidden by generated, normal Delphi/pascal wrappers that are normally allocated. COM is also the reason that interfaces are refcounted (so that their refcount and their corresponding object's lifetime can be mananged by COM)
- Free Pascal on top has some zeroing/RAII of statically allocated stack structs/records/objects like in C++. This is the rarest form though.
So it is all normal malloc like allocating with automated ref counted and some windows specific features thrown in.