current stable: 0.99.6 unstable: cvs (0.99.7) |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Working With VariablesAccessing a Variable's DataBefore we get into the specifics you should know that ferite internally represents all variables using FeriteVariable *'s, and they can safely represent any native type within ferite. The builder and the return macros you've already seen are in place to perform conversions for the sake of convenience. But sometimes you just need to stick your finger in the pudding, so here is how to do it without breaking ferite. There are a few bits of general information you can get from a FeriteVariable * without looking specifically into one variable type. The internal variable name is accessible, although it really isn't as useful as it sounds. Usually the variable name has been automatically generated by an operator or a function. But if you'd really like to have it, you can access is by: [it is a null terminated c string]
Much more useful than the variable name is the variable type. This will tell you if the data held is a number (and what kind), a ferite string, an object, an array, or void (nothing at all). It is accessible by:
It is an integer that can be any one of the following values:
There are a number of additional macros available for accessing the actual data within different variable types. You should use these macros as much as possible when working with ferite variables. Internal structures may change, but these macros should always be up to date and provide exactly the same semantics when it comes to value access.
Changing a Variable's TypeYou can change a variable's type by changing the var->type value to the desired type, but converting the variable's contents is entirely up to you. You should be especially careful when changing the type of strings, objects and arrays, as they have a lot of extra data that goes along with them. However changing a number between types is quite easy. For example, to change a double to a long, you can simply do this:
And to change it back:
It is considered bad for to simply change the type of a variable and is therefore not encouraged at all. It is therefore on your own head to keep things correct. Creating and Destroying VariablesCreating variables is quite simple. Each variable type has a 'create' function that returns a FeriteVariable *, which will be encapsulating the type you requested. The only thing difficult about creating variables is remembering that the returned object will always be a FeriteVariable *, rather than the specific struct type that you wanted. This is because the FeriteVariable * is encapsulating the variable type you had wanted. This is actually quite convenient, since you would have to stuff the specific variable type into a FeriteVariable * before giving it back to the ferite engine anyhow. You already know how to manipulate these variables (or at least get to the information needed to manipulate them), so I'll just quickly run through the variable types available, and their creation functions. The parameters should be pretty self explanitary, if not please refer the the C api document. It should be noted though that they all take the same argument "alloc", this tells ferite whether or not the name of the variable should be allocated or whether it is static.
Deleting variables is actually easier than creating them, if you can believe it. To delete any ferite variable, you simply use the ferite_variable_destroy() function. This function takes the current script and a FeriteVariable * as parameters, and it returns void.
You can use this function on any type of variable, each will be handled in the appropriate manner according to it's type. Strings will have their c-string data freed by ffree() and will then be destroyed. Objects will have their destructor called before they are destroyed. Lastly, unified arrays will have the variables at each of its indexes destroyed in the appropriate manner according to their type and will then, themselves, be destroyed.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
ferite et al © 2000-2004, Chris Ross |