operator overloading with conformant or

Frank Heckenbach frank at g-n-u.de
Wed Mar 12 03:30:49 CET 2003


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

-- 
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
GPC download signing key: 51FF C1F0 1A77 C6C2 4482  4DDC 117A 9773 7F88 1707




More information about the Gpc mailing list