Graf Zahl wrote:1): No. A memset equivalent is far too dangerous in the context of a scripted language and
2): Again no. Since type sizes can vary depending on the current platform, making this available runs a high risk of breaking things.
3): Double can be formatted with String.Format or Console.Printf. 64 bit integer types are currentlly not supported by the VM so it makes no sense implementing them in the language.
4): No. You have to rebuild the vector exoplicitly.
5): Unsigned types exist for bytes, shorts and ints. You format them just like in C: %u instead of %i.
6): The only non-integral built-in data types are Vector2, Vector3 and Color. Vector2 has fields x and y, Vector3 has x, y, z and xy (a Vector2 subvector of the first two components) Color has r, g, b, a.
Thank you for your answer, As far as the first 2 answers, They are bogus if you are going to emulate a C/C++ like languages as a scripting language
which promotes static typing, If that is actually the case in your first and second arguments, you are already going to run into problems
with zscript (if zscript could store/read compiled binaries) -> if one is to make a build under let's say the now dead ALPHA dec processor or the still alive and kicking powerPC/ARM processors using the "double" datatype (depends on the language gzdoom is compiled against and its version), you will run into accuracy discrepancies (And all of that would actually be the case if zscript was storing binaries, but it compiles the scripts in runtime as far as i know)
And compiling the scripts in runtime does actually give you another protection layer, because it will be compiled against the given architecture its running on
(if you are using any form of a C/C++ standard library and compiler when compiling gzdoom).
Your first two arguments would probably hold more water if zscript could store and load compiled data and not compile things at runtime.
If you are still worried about size, support for preprocessing directives and some macros to query the architecture will do just fine,
Now i can see the conflict here, it will add more of a headace to the scripters, But if you are guys are going for a pseudo-like C family language
what do you think that will happen? people will expect that.
Now of course, I think that the way zscript works is ok but describing some practices/methods as bad in the context of a SCRIPTING language, while the scripting language is trying to emulate a real low-level language, while claiming in the documentation that it handles things like in C/C++ , seems a bit inconsistent.