Hi Armando,
A BASIC "fixed length" string is what you'd normally call a "char" or "byte buffer" in "other languages". It's a contiguous chunk (in fact, a one-dimensional array) of bytes allocated in "unmanaged" memory via malloc() or its equivalent outside the scope of C++ std::string. Depending on the platform bitness and Unicode awareness, BASIC would regard such a buffer as a pre-allocated string of CHARs or WCHARs pre-filled with zeros, and would include all operations with the buffer in the category of string functions. Further, depending on the completeness and compliance of its design and implementation, a particular BASIC dialect may also include utility functions to convert (cast) the buffer to other composite data types such as CHAR/WCHAR arrays, UDTs (structures), etc. to enable non-string functions to operate on the buffer natively as well. The advantage of "fixed length" strings over "ordinary" strings preallocated dynamically via the STR()/STRING() allocation functions is that the former normally accept CHR(0) as a valid filler character.
For speed reasons many BASIC dialects, especially interpretative ones, would not at all times rely on literal comparison of string bytes (in fact, CHARs or WCHARs) with zero or each other alone when determining the string lengths or comparing them for (in)equality. A BASIC var structure would normally include a dedicated field to store the string length as set forth/determined at the moment of its creation or assignment. A "fixed length" string would have the buffer capacity (in CHARs or WCHARs) stored precisely in this field of its var structure regardless of the actual CHAR/WCHAR values (possibly zeros) written in the string by allocation, initially, or assignment, thereafter.
Thus, again depending on a particular BASIC dialect implementation,
DIM buffer AS STRING * 128: PRINT LEN(buffer) may very well yield 128 regardless of buffer having been filled with zeros initially at allocation time thus being of zero string length as ASCII
Z strings go. When comparing such buffers with "ordinary" strings for whatever purpose, measures should be taken transparently or explicitly by the language developer or the user to resolve possible data type ambiguity (e.g. dynamic string vs. fixed length string) and avoid related pitfalls as in John's example.
Examples of fixed length strings:
-- Visual Basic: DIM buffer AS STRING * 128 (128 zero bytes/CHARs)
-- ANSI FreeBASIC: DIM buffer AS STRING * 128 (ditto)
-- ANSI PowerBASIC: DIM buffer AS STRING * 128 (ditto)
-- Unicode FreeBASIC: DIM buffer AS WSTRING * 128 (256 zero bytes/128 WCHARs)
-- Unicode PowerBASIC: DIM buffer AS WSTRING * 128 (ditto)etc.
I see nothing esoteric in this paradigm. And that's what a BASIC-er would rely upon from their experience, faced with a necessity or challenge to write some BASIC-like code for a language translator program or library. BASIC has no official standard these days and tradition is what we have to rely heavily instead in order to keep on using our favorite "toy" language.
Hopefully this helps to make Jade more predictable and BASIC compliant regardless of the notorious semicolon line endings.
