Qore Programming Language Reference Manual 1.13.0
|
Unless parse option %allow-bare-refs or %new-style are set, variables are Qore identifiers prefixed by a "$"
sign, similar to Perl. If a variable is declared without any type restriction, then it is assumed to have type any. In this case, variables so declared can hold any data type.
A few variables are set by the Qore language during the execution of Qore programs. These are normal variables that can be reassigned to other values by the user if necessary.
Special Qore Variables
Variable | Scope | Data Type | Explanation |
argv | Local | *list | automatically assigned local variable containing the list of function or method arguments that were not assigned to parameter variables (see Implicit Argument References for more information) |
Qore::ARGV | Global | list | script command-line arguments (use the Qore::GetOpt class to parse command-line arguments) |
Qore::QORE_ARGV | Global | list | complete qore command-line arguments |
Qore::ENV | Global | hash | UNIX program environment |
Unless the %assume-local or %new-style parse directives are used, variables not in a parameter list automatically have global scope unless the first reference is prefixed with The "my" Keyword. Variable names in a parameter list are always local to their associated function, method, or catch block. Global variables can be explicitly declared with The "our" Keyword. The The "our" Keyword keyword is required if the parse option %require-our (-O
or –require-our
command-line option) is set for the parent program. See Parse Option Constants for more information.
When the %assume-local or %new-style parse directive is used, variables without an explicit scope declaration (i.e. The "my" Keyword or The "our" Keyword) are assumed to be local variables.
Variables may be assigned any value unless restricted with a type declaration. If no type declaration is given, then the variable is assumed to be type any. Note that type declarations are required for all variables (and for function and method parameters and class members) when the %require-types parse option is set.
Local variables are not shared between threads (local variables have a distinct value in each thread, with some very particular exceptions), however global variables are. See Threading (and in particular Threading and Variables) for more information.
Global variables are members of namespaces; if a global variable is declared anywhere outside a namespace declaration, and a namespace path is not given, then the global variable will be assumed to be in the root namespace.
For example (in the following script, the The "our" Keyword keyword is optional unless %require-our is set):
The first printf() statement will output:
local a = 2
The second printf() statement will output:
global a = 1
Variables with supported type declarations can be instantiated with a special syntax as follows: [my|our] var_type var_name(
[arg_expression, ...]);
This allows a variable to be declared with a specific type and initialized at the same time.
The following types can be used for var_type:
object<
class_name>
for object instantiation (the class name may have a namespace-prefixed path)hash<
hashdecl_name>
for type-safe hash instantiation (the type-safe hash name may have a namespace-prefixed path)hash<string,
type>
for complex hash instantiation with type-safe keyslist<
type>
for complex list instantiation with type-safe elementsThis provides type information to the parser which allows more errors to be caught at parse time (instead of at run time), and furthermore allows Qore to improve performance by performing more work at parse time rather than for every time the object is accessed at run time (for example, method and variant resolution), and normally requires less typing. This is preferred to using the new operator with a variable declaration.
Local variables are local to the block in which they are declared; they are also thread-local, meaning that each thread will have its own value of a local variable.
Local variables are generally accessed without any mutual-exclusion locking (with the exception of local variables bound in closures and local variables that have a reference taken of them).
Variables declared with my are always local variables.
my Example
The my keyword is not required if the %assume-local or %new-style parse directive is set. In this case, all variables are assumed to be local unless explicitly declared with our.
Variables declared with our have global scope and are subject to mutual exclusion locks with each access. Therefore even in single-threaded programs, it's more efficient to use local variables (even local variables with global scope - where a local variable is declared in the top-level block) if the value of the variable does not need to be shared among other threads.
our Example
Note that the our keyword is required when declaring a global variable if the parse option %require-our (-O
or –require-our
command-line option) is set for the parent program. See Parse Option Constants for more information.
Unlike local variables, global variables are members of namespaces; if a namespace path is not given, then the global variable will be assumed to be in the root namespace. Global variables declared in namespaces cannot be initialized at the same time as the declaration, but instead have to be initialized elsewhere.
When defining a user module, the our keyword can be preceded by public, which means that the global variable will be available (imported) in the Program object importing the module. See public for more information.
Variables declared with thread_local have global scope and are additionally thread local; they are never subject to mutual exclusion locks. Each Qore thread will have a different value for the variable, for example.
thread_local Example
Note that the thread_local
keyword is always required when declaring a global thread-local variable.
Like standard global variables but unlike local variables, thread-local variables are members of namespaces; if a namespace path is not given, then the thread-local variable will be assumed to be in the unnamed root namespace. Thread-local variables declared in namespaces cannot be initialized at the same time as the declaration, but instead have to be initialized elsewhere.
When defining a user module, the thread_local
keyword can be preceded by public, which means that the thread_local
variable will be available (imported) in Program objects importing the module. See public for more information.
thread_local
global variables are always thread local, even if referenced in a closure or if an lvalue reference is taken of a thread_local
variable