At 1:09 +0200 4/7/06, Frank Heckenbach wrote:
CBFalconer wrote:
Peter N Lewis wrote:
So basically, I'm just saying that the lack of short strings is seriously hindering GPC adoption on the Mac, and that that should probably be taken in to account when pondering the priority of their implementation.
On a tangent, what do you think is the future of short strings anyway? For one, there's the 255 chars limitation. While still enough for many purposes, it might not be for some, e.g. file names with several long directories etc. could get longer. Does Mac OS support those at all, with a different interface, or what? Secondly, charsets. When 16-bit charsets (i.e., Unicode) become common (or are already), will/should there be a 16-bit "short" string (i.e., max. 65535 characters)? Or else, if the interfaces will/do use UTF-8, we'll need conversions (automatic and/or manual) between Unicode and UTF-8 anyway? (As discussed before, UTF-8 doesn't make for a string type in Pascal.) Just to figure out if supporting short strings will only be a short-lived solution and more work in this area will be required soon anyway ...
The current and future APIs use CFStrings (CF = Core Foundation), which are an opaque (or real under Objective C) object that handles strings with arbitrary lengths and encodings. Pretty much all future uses of strings with the API will be CFStrings, which I tell people when advocating for GPC. But that doesn't help them porting to GPC in the first place (and as I'd also advocate, make changes one at a time where possible (eg, port to GPC, get it working, then port to newer APIs), that makes for a conflict). There remains a lot of old "short string" uses in the APIs and quite often in file structures as well (since storing a fixed Str31 in a fixed 32 bytes is a lot easier than having to deal with a variable data structure, even if it does waste space, often ease of programming outweighs minimum storage space).
AIUI, the Mac Pascal interfaces make heavy use of such short strings. One option would be conversion to/from them for every input/output parameter (wouldn't work for true reference parameters -- don't know if that's required). This would generally require copying the whole string. Ironically, converting to C-Strings (input parameters only, as long as the strings do not contain Chr (0)) is easier, since one can keep the string in place and only has to add a Chr (0) if space is reserved in advance (as GPC does). That's why we have less of such problems with C-string based OS interfaces (POSIX, Dos, Windows, ...), as most strings parameters are input, and extra work is only required for the few other cases.
Yes, there are basically two ways of handling it in GPC currently - either use fake short strings throughout your program, converting to/from real GPC strings as needed for string operations and using the overloaded operators and such, or convert to/from fake short strings for API/file system access. Adriaan advocates the former, I advocate the latter, but either one makes for a fair amount of work initially. After you get the work done and get used to it, it is not too bad, but that doesn't sway newcomers making a choice between an easy FPC port or a harder GPC port. Explaining all the Extended Pascal goodness in GPC rarely sways people in such a position.
In any event, as I said up front, I'm not intending to advocate that short strings are wonderful or that there aren't any other alternatives, or any such thing - I love the long string support in GPC, it more than made up from the short term pain of conversion. What I am saying is that it is turning away people with traditional Mac code to port before they get a chance to find out how cool GPC is.
Thanks, Peter.