Merging fex-1.1.txt and fubi.log (from DS2Mod) -- 1 question about datatypes
| Submitted by the.gray.fox on Tue, 2010-12-07 13:11 | ||
Hello. In fex-1.1.txt I see the "gpstring" and the "gpwstring" datatypes. More specifically: The question: But in skrit code... do you have both the "string" and the "wstring" datatypes? I thank you in advance. forums: |
||
|
» |
||
Not sure if it would be a syntax error, but it's probably just be unneeded. Depends on what you are using it for really. I cannot find the "wstring" qualifier in any gp code that I have ever looked at.
Some good reading on this question can be found at: http://bytes.com/topic/c/answers/509137-support-std-wstring
That is good enough, thank you.
I will assume that the tokens:
-- gpwstring
-- gpstring
-- wstring
-- string
all ultimately evaluate to the "string" skrit token.
Collaterally it makes the thing much more comfortable to read.
Side note:
Whether or not I treat "string" and "wstring" as the same, of the 2278 functions defined within fex-1.1.txt, only 654 do match(*) the signatures of class methods and global functions defined within fubi.log.
I was hoping for many more :-/
___
(*) = the matching is done by ignoring the static, the const, the star, and the ampersand tokens -- for their placement changes completely across the two files.
I got 1 more question.
Is there any use for References (&) and Pointers (*) in skrit?
I notice pretty much every param in fubi functions want either a & or a *.
But what little skrit I have seen does not make use of either.
This confuses me.
If nothing is passed "by value", then why export the extra & and * info in fubi.log anyway?
Is there a reason I am not seeing? -- thank you
In the original skrit code of DS2 you hardly will find pointers or references as used/possible C++. Only some variable types leave the impression that they are handled internally as a pointer, like the id of a data collection.
However the & and * after the parameters in the fubi.log often help to read/understand how the functions may work.
For example, const string* should not be replaced with an empty variable, while it's ok to replace const string& with an empty variable (in both cases you also can add a term in quotes).
The skrit compiler most probably will compile the skrit code anyway regardless if your variables are empty or not. The complier only will complain if you replace string* (without a leading const) with a term in quotes because a variable is expected to write back the function result.
Besides of this, fubi.log misses of some transparency. A few functions that seem to be read-only cause errors in the logs like 'this function does not allow reading' for no evident reason.
Also it's not clear how to find unlisted functions like SetDoesBlockPath( bool ) resp. that the complier sometimes accepts skrit commands like DoesBlockPath = true to write/change the related propriety.