The above is part of Graf Zahls response to my addition of (nigh) unlimited (and unmanaged) string support to ACS. My intention was also to provide actual automated management through an ACS-compiler, but this was (sensibly) considered an excessive effort. As Graf pointed out, we don't need real dynamic strings as anything but function input/output.Graf Zahl (snippets) wrote:What do you need dynamic strings for?
- implementing functions returning string values (e.g. getActorClass, getCurrentWeapon etc.
- creating string parameters for functions like SpawnSpot on the fly.
store game status stuff. For this char arrays would be much more suitable. If necessary, add a function to copy a string to an array and all should be well.
The string only needs to exist very briefly: Long enough to be consumed by a function (or transferred to an array).
Spoiler: Addition and basic idea
Spoiler: Inside detailsI only downloaded the ACC-source yesterday, and I don't know how to provide a good svn-diff for it. If that, or any violations of best practice I might have made, poses a problem; let us work on it. This time I think the basic concept is simple and safe.
Side note: No new save data is introduced. The dynamic strings don't live enough to become part of the saved gamestate.
Spoiler: Draft user documentation, mark 2EDIT: A modified version has been packaged and uploaded alongside the original submission. "ZDOOM_ACC_StrParam_implicit.zip" contains an ACC project and a ZDoom diff, as well as an overview of changes to ACC.
Spoiler: Under the hoodEdit: Replaced all versions with the latest one. String stack handling is implicit and automatic, and strparam can be called as a statement.