4D v16.3Using Compiler Directives |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
4D v16.3
Using Compiler Directives
Using Compiler Directives
4D has three categories of variables:
For more information about this point, refer to the Variables section. Process and interprocess variables are structurally the same for the compiler. Since the compiler cannot determine the process in which the variable will be used, process variables should be used with more care than interprocess variables. All process variables are systematically duplicated when a new process begins. A process variable can have a different value in each process, but it has the same type for the entire database. All variables have a type. As described in the Data Types section, there are several different types of variables:
Here are the different types of arrays:
Notes: In interpreted mode, a variable can have more than one data type. This is possible because the code is interpreted rather than compiled. 4D interprets each statement separately and comprehends its context. When you work in a compiled environment, the situation is different. While interpretation is performed line by line, the compilation process looks at a database in its entirety. The compiler's approach is the following:
If the compiler comes across the same variable name and two different data types, it has no reason to favor any particular one. In other words, in order to type an object and give it a memory address, the compiler must know the precise identity of that object (i.e., its name and its data type). The compiler determines its size from the data type. For every compiled database, the compiler creates a map that lists, for each variable, its name (or identifier), its location (or memory address), and the space it occupies (indicated by its data type). This map is called the symbol table. An option in the Preferences lets you choose whether to generate this table in the form of a file during compilation. If you want the compiler to check the typing of your variables or to type them itself, it is easy to place a compiler directive for this purpose. You can choose between two different possibilities, depending on your working methods:
When variables are typed by means of a compiler directive, they receive a default value, which they will keep during the session as long as they have not been assigned. The default value depends on the variable type and category, its execution context (interpreted or compiled), as well as, for compiled mode, the compilation options defined on the Compiler page of the Database settings:
The following table illustrates these default values:
Compiler directives are useful in two cases:
Furthermore, using compiler directives allows you to reduce compilation time. Sometimes the compiler cannot determine the data type of a variable. Whenever it cannot make a determination, the compiler generates an appropriate error message. in method A, Variable:=True in method B, Variable:="The moon is green" If method A is compiled before method B, the compiler considers the statement Variable:="The moon is green" as a data type change in a previously encountered variable. The compiler notifies you that retyping has occurred. It generates an error for you to correct. In most cases, the problem can be fixed by renaming the second occurrence of the variable. Ambiguity on a forced deduction Here is an example using the default values for an active object: In a form, you can assign default values for the following objects: combo boxes, pop-up menus, tab controls, drop-down lists, menu/drop-down lists and scrollable areas using the Edit button for the Value List (under the Entry Control theme of the Property List) (for more information, refer to the 4D Design Reference manual). The default values are automatically loaded into an array whose name is the same as the name of the object. If the object is not used in a method, the compiler can deduce the type, without ambiguity, as a text array. However, if a display initialization must be performed, the sequence could be: Case of In this case, the ambiguity appears––when parsing methods, the compiler will deduce a Real data type for the object MyPopUp. In this case, it is necessary to explicitly declare the array in the form method or in a compiler method: Case of Inability to determine a data type
Pointers Var1:=5.2(1) Although (2) defines the type of variable pointed to by Pointer, the type of Var2 is not determined. During compilation, the compiler can recognize a pointer, but it has no way of knowing what type of variable it is pointing to. Therefore it cannot deduce the data type of Var2. A compiler directive is needed, for example C_REAL(Var2). Multi-syntax commands Commands with optional parameters of different data types Methods called via URLs If all the variables used in the database are explicitly declared, it is not necessary for the compiler to check the typing. In this case, you can set the options so that the compiler only executes the translation phase of the method. This saves at least 50% in compilation time. You can speed up your methods by using compiler directives. For more details on this subject, refer to the Optimization Hints section. To give a simple example, suppose you need to increment a counter using a local variable. If you do not declare the variable, the compiler assumes that is a Real. If you declare it as a Longint, the compiled database will perform more efficiently. On a PC, for instance, a Real takes 8 bytes, but if you type the counter as a Longint, it only uses 4 bytes. Incrementing an 8-byte counter obviously takes longer than incrementing a 4-byte one. Compiler directives can be handled in two different ways, depending on whether or not you want the compiler to type your variables. The compiler must respect the identification criteria of the variables. V1:=True the compiler determines that variable V1 is of data type Boolean. By the same token, if you write: V2:="This is a sample phrase" the compiler determines that V2 is a Text type variable. The compiler is also capable of establishing the data type of a variable in less straightforward situations: V3:=V1 `V3 is of the same type as V1 The compiler also determines the data type of your variables according to calls to 4D commands and according to your methods. For example if you pass a Boolean type parameter and a Date type parameter to a method, the compiler assigns the Boolean type and the Date type to the local variables $1 and $2 in the called method. When the compiler determines the data type by inference, unless indicated otherwise in the Preferences, it never assigns the limiting data types: Integer, Longint or String. The default type assigned by the compiler is always the widest possible. For example, if you write: Number:=4 the compiler assigns the Real data type to Number, even though 4 happens to be an integer. In other words, the compiler does not rule out the possibility that, under other circumstances, the variable's value might be 4.5. If you have already typed your variables and are sure that your typing is coherent and complete, you may explicitly ask the compiler not to redo this work, using the compilation Preferences. In case your typing was not complete and exhaustive, at the time of compilation, the compiler will return errors requesting you to make the necessary modifications. 2) The compiler directive commands enable you to explicitly declare the variables used in your databases. They are used in the following manner: C_BOOLEAN(Var) Through such directives, you inform the compiler to create a variable Var that will be a Boolean. A compiler directive has priority over deductions made from assignments or use. If you do not want the compiler to check your typing, you must give it a code to identify the compiler directives. Note: The syntax for declaring these parameters is the following: Particular parameters
C_LONGINT($0) Compiler directives remove any ambiguity concerning data types. Although a certain rigor is necessary, this does not necessarily mean that the compiler is intolerant of any and every inconsistency. C_LONGINT(vInteger) The compiler does not regard it as a data type conflict that will prevent compilation; instead, the compiler simply rounds off to the closest integer value (3 instead of 2.6).
See also
Error messages
|
PROPERTIES
Product: 4D
HISTORY
ARTICLE USAGE
4D Language Reference ( 4D v16) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||