I don't quite understand when to use FIELD-SYMBOLS. They are like the Pointers in C/C++ but we are using them everywhere in that language. Simply:
What is the difference between using
DATA gt_mara LIKE TABLE OF mara.
DATA gs_mara LIKE LINE OF gt_mara.
LOOP AT gt_mara INTO gs_mara.
"code
ENDLOOP.
and
DATA gt_mara LIKE TABLE OF mara.
FIELD-SYMBOLS <gs_mara> like LINE OF gt_mara.
LOOP AT gt_mara ASSIGNING <gs_mara>.
"code
ENDLOOP.
Your question boils down to Value vs. Reference Semantics, I'll quote some parts of that article:
Reference semantics are A Good Thing. We can’t live without pointers. We just don’t want our software to be One Gigantic Rats Nest Of Pointers. In C++, you can pick and choose where you want reference semantics (pointers/references) and where you’d like value semantics (where objects physically contain other objects etc). In a large system, there should be a balance. However if you implement absolutely everything as a pointer, you’ll get enormous speed hits. Objects near the problem skin are larger than higher level objects. The identity of these “problem space” abstractions is usually more important than their “value.” Thus reference semantics should be used for problem-space objects.
In ABAP you'd model "problem-space objects" either as structures or classes, thus those are values for which one would generally use reference semantics. For referencing class instances one has to use references, which can also be used to reference structures. So for references in ABAP, one would generally use references instead of the more limited field symbols.
Now with references you usually have the problem of memory management,
as as long as a value on the heap is referenced, it cannot be garbage collected and references onto the stack can only be accessed till the stack is popped off. Thus there is always some overhead for managing the referenced memory and checking whether references are still valid. The ABAP Documentation states:
From a technical perspective, the field symbols are implemented by references or pointers, which are comparable to references in data reference variables. A data reference variable is declared in the same way as every other data object and the memory area for the reference it contains is in the data area of the ABAP program. However, the pointer assigned to a field symbol is exclusively managed by the ABAP runtime environment and is located in a memory area, which cannot be accessed directly in an ABAP program.
Additionally (local) field symbols can only be declared inside a procedure (and not e.g. as an instance member), and as such the lifetime of a field symbol is never longer than that of a local variable. This is also true for references to table lines as long as nothing is deleted from the table. These guarantees probably allow the ABAP Kernel to handle field symbols in such cases more efficiently (e.g. this discussion).
So field symbols make sense where performance is crucial and copying a structure² is way more expensive than passing around a reference (although you want to keep value semantics). The prime example for that are loops over large tables. When writing back into the table a field symbol is also easier than a MODIFY
to copy back the values into the table.
TLDR: Prefer FIELD-SYMBOLS inside of loops!
²When passing around other large data objects such as internal tables or strings it would also always make sense to pass by reference instead of copying. Fortunately ABAP already does that under the hood for these types, and copies when they're mutated (to keep the value semantics).