When working with ABAP, understanding pass by reference and pass by value is crucial for optimizing performance and ensuring the correct behavior of methods and functions.

In modern ABAP Object Oriented Programming, we define method parameters using the IMPORTING, EXPORTING keywords, each of which can use pass by value or pass by reference, as well as the RETURNING keyword, which is always pass by value, and the CHANGING keyword, which is always pass by reference.

Let’s understand the difference between them.

1. Pass by Value

When a parameter is passed by value, a copy of the data is made.

This means any changes inside the method do not affect the original variable outside the method. In methods we explicitly define pass by value using the VALUE keyword.

Example 1) of Pass by Value

Explanation:

• The VALUE keyword ensures lv_number is passed by value, thus a copy of the data is made inside the method.
• Any modifications to the copied data within change_value do not affect lv_number outside the method.

That’s great, but what if instead of:

We have:

We have IMPORTING VALUE(), which is implicitly pass-by-value, so it creates a copy of the data, but now we don’t have TYPE i but TYPE REF TO i as our type.

Let’s take a look.

Example 2) of Pass by Value

Explanation

• Even though lv_number is a reference, it is passed by value, meaning that a copy of the reference is passed.
• The original lo_number still points to lv_number.
• Inside change_value , iv_number points to the same memory as lo_number , but iv_number itself is a separate reference.

Next, let’s check out pass-by-reference in methods.

2. Pass by Reference

When a parameter is passed by reference, no copy of the data is created.

Instead, the method copies the memory address of the data as a reference and operates directly on the original variable, meaning any changes made inside the method will reflect outside the method, as the original data was changed via this reference.

Example 1) of Pass by Reference

Explanation:

• lv_number is passed by reference to the method, thus the method acts directly on the data behind the reference.
• The changes to iv_number reflect outside the method on lv_number.

Example 2) of Pass by Reference

Explanation:

• The parameter lo_number is a reference to an integer (TYPE REF TO i), meaning it holds the memory address of an integer.
• lo_number = NEW i( lv_number ) creates a new reference to/a new memory address of lv_number, causing the original memory to stay unchanged.
• Pass by reference causes lo_number to change outside the method.
• ->* dereferences the object and accesses the data behind the memory address.
• Modifying number->* affects number->*, which reflects outside the method.

3. Field-Symbols

We’ve pretty much covered pass-by-value and pass-by-reference in the context of methods and their parameters, and we’ve also talked about variables and ref variables.

I know some readers are going to be wondering: “What about Field-Symbols?”

So let’s briefly discuss them as well and you’ll find more details in the performance comparisons below.

What are field-symbols?

Field-symbols are pass-by-reference. Their syntax differs a bit from references, but basically they’re pointers in ABAP, allowing dynamic access to memory locations without copying data or needing to be dereferenced.

While field-symbols offer a slight performance advantage due to not needing to be dereferenced, which is a negligible performance cost, they are becoming obsolete and will no longer be supported in ABAP Cloud.

Hence, why I only wanted to mention them briefly.

4. Performance Comparisons

Aspect	Pass by Value	Pass by Reference
Memory Usage	Higher (creates a copy)	Lower (uses original memory)
Performance	Slower for large data	Faster, especially for tables
Data Integrity	Safer (no unintended modifications)	Risk of unintended modifications

Aspect	Field Symbols (< >)	References (REF #( ))
Concept	Acts like a pointer, referencing existing memory directly	Creates a reference object pointing to data
Memory Usage	No new memory allocation	Requires memory for the reference itself
Performance	Very fast (direct access)	Slightly slower due to dereferencing
Scope	Only valid within the block where assigned	Persistent across method calls
Usage	Good for internal table processing, loops, dynamic access	Useful for object-oriented design, method parameters
Dereferencing	Implicit (no extra step needed)	Explicit (lo_ref->*)
Modifications	Changes the original data directly	Changes data via the reference
Flexibility	More flexible for direct memory operations	Better for passing objects and structured data

Dereferencing is very fast, operating at memory access speed. The performance cost is negligible compared to large data copies or database accesses.

5. Overview of Behaviour

1. In ABAP OOP, using VALUE() or not in your IMPORTING and EXPORTING parameters determines whether the method implicitly behaves as pass-by-value or pass-by-reference.
2. A reference to an object is the memory address of an object via which the object can be accessed (dereferenced, ->*) and acted upon. Passing only memory addresses requires less computation than copying the entire datasets around.
3. Pass-by-value methods create a copy of the object, even when the object itself is a reference. Thus the original object stays unchanged outside the method.
4. Pass-by-reference methods access the memory address of the original object and may act upon its data by dereferencing. The original object doesn’t stay unchanged outside the method. This can sometimes lead to unexpected behavior, when appending to EXPORTING tables in separate method calls throughout a program where one would expect the parameter to be automatically cleared with each call, but isn’t. Manual clearing of EXPORTING parameters for tables, may be necessary, when appending to pass-by-reference variables.
5. CHANGING is always pass-by-reference and RETURNING is always pass-by-value. IMPORTING and EXPORTING can be either.

Conclusion

Modern ABAP OOP syntax allows clear control over pass by reference vs. pass by value, influencing performance and data integrity. By understanding these principles, developers can write more efficient and maintainable code in ABAP.

 

Let’s Keep the Conversation Going!

Do you have questions or your own experiences on this topic? Feel free to reach out to Jonathan Rumpl on LinkedIn!

Stay up to date! Sign up for our Cadaxo newsletter and receive regular insights, best practices, and news from the SAP world.