For 1 and 2: records are value types, while classes are reference types. They re allocated on the stack, or directly in the memory space of any larger variable that contains them, instead of through a pointer, and automatically cleaned up by the compiler when they go out of scope.

As for your third question, a TList<TMyRecord> internally declares an array of TMyRecord for storage space. All the records in it will be cleaned up when the list is destroyed. If you want to delete a specific one, use the Delete method to delete by index, or the Remove method to find and delete. But be aware that since it s a value type, everything you do will be making copies of the record, not copying references to it.

There are lots of differences between records and classes; and no "Pointer to record" <> "Class". Each has its own pros and cons; one of the important things about software development is to understand these so you can more easily choose the most appropriate for a given situation.

1. This question is based on a false premise. Records are not almost like classes, in the same way that Integers are not almost like Doubles.
   • Classes must always be dynamically instantiated, whereas this is a possibility, but not a requirement for records.
   • Instances of classes (which we call objects) are always passed around by reference, meaning that multiple sections of code will share and act on the same instance. This is something important to remember, because you may unintentionally modify an object as a side-effect; although when done intentionally it s a powerful feature. Records on the other hand are passed by value; you need to explicitly indicate if you re passing them by reference.
   • Classes do not copy as easily as records . When I say copy, I mean a separate instance duplicating a source. (This should be obvious in light of the value/reference comment above).
   • Records tend to work very nicely with typed files (because they re so easy to copy).
   • Records can overlay fields with other fields (case x of/unions)
   • These were comments on certain situational benefits of records; conversely, there are also situational benefits for classes that I ll not elaborate on.
2. Perhaps the easiest way to understand this is to be a little pedantic about it. Let s clarify; memory is not really allocated when its declared , it s allocated when the variable is in scope, and deallocated when it goes out of scope. So for a local variable, it s allocated just before the start of the routine, and deallocated just after the end. For a class field, it s allocated when the object is created, and deallocated when it s destroyed.
3. Again, there are pros and cons...
   • It can be slower and require more memory to copy entire records (as with generics) than to just copy the references.
   • Passing records around by reference (using pointers) is a powerful technique whereby you can easily have something else modify your copy of the record. Without this, you d have to pass your record by value (i.e. copy it) receive the changed record as a result, copy it again to your own structures.
4. Are pointers to records like classes? No, not at all. Just two of the differences:
   • Classes support polymorphic inheritance.
   • Classes can implement interfaces.

One of the main benefits of records is, when you have a large "array of record". This is created in memory by allocating space for all records in one contiguous RAM space, which is extremely fast. If you had used "array of TClass" instead, each object in the array would have to be allocated by itself, which is slow.

There has been a lot of work to improve the speed of allocating memory, in order to improve the speed of strings and objects, but it will never be as fast as replacing 100,000 memory allocations with 1 memory allocation.

However, if you use array of record, don t copy the record around in local variables. That may easily kill the speed benefit.

1) To allow for inheritance and polymorphism, classes have some overhead. Records do not allow them, and in some situations may be somewhat faster and simpler to use. Unlike classes, that are always allocated in the heap and managed through references, records can be allocated on the stack also, accessed directly, and assigned each other without requiring to call an "Assign" method. Also records are useful to access memory blocks with a given structure, because their memory layout is exactly how you define it. A class instance memory layout is controlled by the compiler and has additional data to make objects work (i.e. the pointer to the Virtual Method Table).

2) Unless you allocate records dynamically, using New() or GetMem(), record s memory is managed by the compiler as ordinals, floats or static arrays: global variables memory is allocated at startup and released when the program terminates, and local variables are allocated on the stack entering a function/procedure/method and released exiting. Allocating/releasing memory in the stack is faster because it doesn t require calls to the memory manager, it s just very few assembler instructions to change the stack registers. But be aware that allocating large structure on the stack may cause a stack overflow, because the maximum stack size is fixed and not very large (see linker options). If records are fields of a class, they are allocated when the class is created and released when the class is freed.

3) One of the advantages of generics is to eliminate the need of low-level pointer management - but be aware of the inner workings.

There are a few other differences between a class and a record. Classes can use polymorphism, and expose interfaces. Records can not implement destructors (although since Delphi 2006 they can now implement constructors and methods).

Records are very useful in segmenting memory into a more logical structure since the first data item in the record is at the same address point of the pointer to the record itself. This is not the case for classes.