Peter N Lewis wrote:
It seems it is not possible to use a conformant or open array to operator overloading, ie:
operator + ( const s1: array[n1..m1: Integer] of char; const s2: array[n2..m2: Integer] of char ) = ADD : Str255;
operator + ( const s1: array of char; const s2: array of char ) = ADD : Str255;
Whoa! That's a strange case even I hadn't thought of so far.
both fail with "operator must have two arguments", presumably because the conformant/open array passes hidden arguments for n1,m1 or High(s1) etc.
Is the error actually correct, or is the error just erroneously complaining about the hidden arguments (since there are two real arguments).
If the latter, it'd be nice to get this fixed since it would make porting of short strings a lot easier. If the former, are there any plans to remove this restriction?
The error message is indeed due to the hidden arguments, and removing it would be possible. But there are deeper problems. In the current implementation, overloaded operators are identified by type names, and conformant arrays have none. Solving that would require at least some extra code to make up special "names".
However, overloading shall be reimplemented sometime (though it's not a top priority for me). Also then I suppose conformant/open arrays would require some extra code, but quite different from what's required now.
So doing it now would in the long run be wasted effort, and I'm not actually sure of it's usefulness (see below).
Failing his, if I have six or seven string types (of different lengths), and I make an operator + and = for each pair, that is n**2 for each (perhaps 49 + operators and 49 = operators). Would doing this be stretching the compiler beyond it's design or would it be a perfectly reasonable thing to do?
I think the former. Writing 98 operators is not a problem by itself, but it's not a sign of good design.
Also, there's a rule of thumb, whenever there are already 7 items of something, more are likely to be added over time (well, weekdays may be an exception ;-) ...
Besides, an operator as above would accept too much (any array [with integer index] of char, not only the special "short strings"). You could check the lower index at runtime (so exclude 1-based "fixed strings"), but you'll get into trouble with BP-style "CString arrays" which are also 0-based.
Also, I noticed that := cannot be overloaded as an operator. This would also be a handy addition, although quite possibly it'd have to be a special case.
I don't think so. In Pascal (unlike C), `:=' is not an operator.
And I think it wouldn't really help you here. What about parameter passing? You'd need to convert them, so built-in routines like Length, Copy, SubStr, ... and RTS routines (a long list of string functions and another one of file name routines, etc.) will work. (Even if GPC supported function overloading, this would not be a realistic thing to do with so many functions, leave alone user-defined routines ...)
I once thought of something like "type cast operators" (as in C++), though I haven't thought about any details (syntax, how to implement it, probably not exactly easy) ...
All in all, I think implementing short strings in "user space" is a non-starter. You might have some limited success with quite some effort, but there will probably be restrictions and limitations all around. It's better done within the compiler.
Frank