This lesson is about the types of variables we can declare, what they store, and the differences between a
native type and an object.
There are many types we use even in GUI that you probably recognize. We can use these types in VJass as well for locals, arguments, and return values.
- integer - stores a negative or positive whole number
- real - stores a negative or positive decimal number
- boolean - stores either true or false
Those are native types. There are also object types (we will get to the difference between these soon):
- string - letters and words
- item - an ingame item
- unit - an ingame unit
- group - a unit group
- player - an ingame player
- timer - same as GUI timer
- force - a player group
As well as many objects that are not declarable in GUI
- trigger - this is an object we must declare in VJass. In GUI we cannot explicitly declare these.
- trackable - used to track mouse. In GUI these cannot be used in any way.
To understand the difference between an object variable and native variable, you must first understand how
these variables are stores on your computer. In your computer, there is something called memory, which is a
series of bytes. When you declare a variable, a space in memory is allocated - how large this space is
depends on the type declared - and then the program remembers this space, and writes and reads from it as
required. For example, when an integer is declared, 4 bytes of memory are allocated to store it.
The native types of data are written directly into memory. When you save a variable with an integer value of - for example - 10, this value will be converted into binary and then stored in those bytes. Or, a boolean will be written into memory as either a 1 (true) or 0 (false). Consider this memory diagram for declaring an integer value:
In this diagram, MyInteger is stored at an arbitrary memory location (0x10000)
Objects on the other hand behave completely differently. When we declare an object, the variable itself actually does not store the object at all. Rather, it stores a reference to the memory location where the object actually exists. Consider the memory diagram:
In this case, MyUnit points to the actual unit at memory address 0x10500
At first, this difference may not seem important - but this is the actual reason why some things can leak in
VJass (and GUI as well). Let's say we create a unit group. This creates the real group in memory and a
pointer to that group. Now, if we re-assign that variable to a new group, it will create a new unit group
and reassign that pointer to the new group. But the old unit group still remains lost in memory! That memory
is still allocated to it, even though it will never again be accessed. Consider the following diagram for an
example of a unit group leak:
In this case, the reference is overwritten by the new object, and group@10500 is leaked.
Not all object type variables leak, due to various reasons in the language, but only object type variables can leak. To deal with an object leak, do the same thing you do in GUI: call the appropriate destructor to destroy the actual object (for example, call DestroyGroup(myGroup)). There also is an additional local leak we can have in VJass which we will get to later.
- Some commonly used types in vjass are: integer, real, boolean, string, unit, item, trigger, group, force
- Some objects type variables can leave a memory leak if the reference to them is reassigned before they are destroyed
Back to lessons