It's an old programming principle that one should avoid global data as possible and instead work better with parameterized blocks of code (methods, functions, ...) and local variables. To the pros and to understand the various disadvantages of variable scope, is also a look at the foundations of their deployment makes sense.
When speaking in ABAP of global data, we mean not - as is also common - application-wide hidden data, but variables declared on a code unit , so a class, program or function group, suitable and valid . The access is - except for public class attributes - modular: limited to the procedures of each unit of code. is packed only in the classical monolith in which all the code into a single report, the two concepts coincide: Program Global data Then, application-wide global. [1] this difference between application-wide data and global data must be kept in mind when we follow the literature in discussions of global data. In the C / C + + literature with global data often meant the application-wide data. These are particularly problematic. Many of the problems but they have in common with each unit of code data defined. Even if access is restricted, remains reserved for global variables memory area for the life of the unit of code received. For programs, function groups, and static class attributes means that for the entire application. Only instance attributes are usually short-lived - if not a reference to the instance is gone, the instance is removed along with their attributes. The main difficulty with global data is the so-called "Reentrance" problem: If a procedure is called in a unit of code, changed global variables in the rule (otherwise if they had been declared more sense not as variables but as constants). In a later call to the value of the variable is therefore determined by the call-history of the procedure, it is uncertain from the perspective of the later call. This makes the code more difficult to reconstruct. Reentrant code however, does exactly the same each time, it generates no side effects. In programming languages such as Java or C + +, in which the same code path can be run by different threads is, Reentrance a necessary criterion for concurrent programming dar. In ABAP there is indeed
Shared Objects 
and the "parallelized" calling a function module in multiple processes with the addition
starting new task - a Reentrance problem you have with these concepts but not, must be locked against changes, if you want to change their global data and the "parallelized" calling a function module in multiple processes with the addition Shared Objects - the naive attempt to change within a method leads to global data, the program is canceled when you are in normal read mode of the object is located. While changing engage other consumers back to the early, consistent version of the object. Each process is therefore working at any time with a consistent data data object.starting new task
The
CallFunction with the addition
in general is no concurrency, because the function module is executed for each call in a new, spotlessly clean mode, present in which all code units again in the initial state.
Global variables are convenient, because its values always has access. But this convenience has a price: Because of the scattered use in a variety of procedures increases the complexity of each global variable of the program. It is much easier to refactor a procedure that is not using global data. Therefore, there is the following rule:
Global variables should be introduced only if there are no alternatives.
course, there are also cases where the use of global variables makes sense. For example, you need global data common to the holding of
session data, such as to remember in a transaction, a user inputs: Each dialog step of the transaction is the first control to the user, then passed back to the computer. The computer must, however, keep the entries made previously in memory. Local variables are, of course, this is not possible since been removed at the handover of control to the user all the call stacks. The next input trigger then the PAI modules new call stack. But in the code units that are run here, must be available earlier entries - that's only if they are marked as global (or static) variables. But even if global variables are justified in some situations and useful are the local variables are usually the better alternative dar. are called local variables and "variables on the stack. Why? "The Stack" is a virtual machine for microprocessors and conventional memory construct with which the system is noted in procedure calls, the return addresses. There is a stack pointer
is the address of the current top of stack and built
push - and
pop operations to copy data into the stack and take from him. It is this stack is used to manage local data: The need for local data storage space is easy on the current stack pointer is added [2] This is very quick and shall, at the deepest level, that local data actually used only within a procedure. can be. A simple example - a routine for adding two integers is to illustrate how this works at the machine level on. The obvious source for such a routine in C for
int add (int x, int y) { return x + y; } would, however, of any optimizer immediately as inline detected worthy, that the complete call of the function would be optimized away. Instead, the command processor add for adding two numbers would be generated directly in the bytecode into the call position. Even if we write the same thing a bit complicated, int add (int x, int y) {int z
;
z = x + y; return z;}
add (1,1); would have the procedure under current Compilers are not good chances of survival. If it still creates - for example by changing the settings and the optimizer inlining prohibits [3], we obtain in x86 assembly code such as the following result.
start:; sample call: Calculate 1 + 1
push 1; parameters y and ...
push 1; ... Parameter x on the stack layleave; makes implicit POP EBP EBP - ret> ESP
call _add; is in EAX after executing the value 2
...
_add:
push ebp; save register of references EBP mov ebp, esp; Top of Stack noted add esp, 0FFFFFFFCh , Subtract 4 bytes from ESP (for z)
mov eax, [ebp +8]; Load parameters x in
EAX add eax, [ebp +0 Ch]; parameter y
add add mov [ebp-4], eax; result in local variable store z
8; return value is always EAX
, ie 8 bytes for call parameters purge
of the processor used stack pointer in the x86 processor family ESP
. The auxiliary register
EBP is used during a procedure as a reference, it contains the contents of the stack immediately after jumping to the routine.
The above code line shows the first example of call in the main program: you want to add one and one. These two ones must first be placed on the stack. Then the routine is called for adding. The call
command will then internally the return address of the instruction pointer on the stack and sets the instruction pointer to the beginning of Addierroutine. There, the
EBP is saved to the stack and then overwritten with the current value of ESP
.
The next statement is interesting: it simply be deducted 4 bytes from the stack pointer. Since the stack with push
descends in the address space, ie this: These four bytes are reserved by the simple subtraction
. Way local variables are treated in assembler, for this subtraction is the translation of C statement int z; follows further below to access the local variable:
mov [ebp-4], eax; result z in a local variable store
The variable is then accessed with indirect addressing on their own, the assembler known offset.
Exactly the same stack, which is used for subroutine calls to remember the return addresses, is thus used for the management of procedure parameters and local variables. This is ensure that these variables in the current call level, but not available at higher levels, since leaving the routine, the stack pointer so degraded along with the transfer parameters.
What happens now when a subroutine call in the subroutine? On the stack are other parameters, local variables and return address. The data of the calling subroutine, but all are still on the stack and therefore in principle available. If the calling sub-program would tell the called subprogram, the addresses of its local data and call parameters, this could also access it. That would be a passing parameters using the standard "call by reference" as in ABAP for all procedure calls is the default.
This example shows that the speech, local variables and procedure parameters "live on the stack is taken too literally. Binding to the call stack has many advantages that characterize the local variables before alternatives such as static or global variables. For example, local variables are automatically "thread-safe" because the call stack is specific to a process that he can never share with other processes. In addition, there is never a problem Reentrance: The content of local variables is not on the call history. If the local variables in ABAP on entering the procedure implicitly initialized are, their value can be changed only by the code itself of the procedure, so any time is imminent.
[1] For functional groups has come to be used in the ABAP world the way of speaking, their global data represent the "global mind" of the functional group.
[2] In
x86 Assembler
is subtracted, as the stack from top to bottom "is growing, a
push operation so the stack pointer decreases. But those are implementation details.
[3] or, as I did it, encodes the same routine in assembly language.
0 comments:
Post a Comment