Yes, I'd like to finish this PR off; it's fairly close to the top of my todo list to get this finished and merged in.
Originally, the 'ustring.bi' was pretty much copy+paste from Jose's WinFBX followed by some hack+slash. It might be in use for quite a while so I think it is worth taking it's development as far as is reasonably possible before formally adopting it's use, rather than just throwing it out there because it "works".
I think need to explore what this thing is and why we are adding it:
- probably a long time before var-len wstring is natively supported by fbc
- would be helpful to users to have an equivalent even if implemented as an #include
- would help development in other areas of var-len wstring support
- we are not building a framework or data type system
What we want here is a place holder that will work a lot like a native var-len wstring would work. Which for symmetry, should likely have many similar characteristics as already existing STRING:
- minimal field: data, length, size
- null descriptor if no string is allocated
- fixed growth rate (STRING uses 12.5%)
- similar operations allowed or restricted as STRING
- declaration separate from implementation (especially if supporting code is large)
As is 'ustring.bi' has these extra characteristics:
- pre-allocates 260 bytes, even for empty strings
- growth rate field is stored with every string
- implicit conversion construction like 'dim x as ustring = 1'
- executable code in the include (duplicates code in multi-module compilations)
- the actual type is FB_USTRING.DWSTR, but has `#define ustring FB_USTRING.DWSTR` indirection
- overloads CAST() AS ANY PTR allowing ustring to be passed to any pointer type without warning/error.
- no awareness of CONST qualifiers
I'd kind of like to get 'ustring.bi' down to just the minimum needed. Simple use, easy to maintain & document, etc.