According to Frank Heckenbach:

Well, the problem is, I said "efficiently". I don't assume, gpc would optimize statements like s:=s+'a' where s is a (possibly quite long) string, so I'd have O(n) where actually O(1) is possible.

I would say: GPC *does* optimize this. Just type `gpc -O -S foo.pas' and look at `foo.s' ...

E.g. the examples from the documentation about converting CStrings to Pascal strings append char by char in a loop -- O(n^2) instead of O(n). I don't think that should be left as it is.

You mean the routines in the FAQ? I think they are O(n) because "S:= S + Src^" is inlined and optimized. But of course, feel free to improve those routines and send the result to Jan-Jaap ... ;-)

I'd have to do it like this if there's no other way... But shouldn't it be possible to access the fields of the "string record" in a direct way? Perhaps in the course of the schema project?

It would not be too difficult to make "MyStr.length" and "MyStr.String" accessible "record fields" of strings. Would it be desireable? I am not sure how this fits into the standard ...

Another thing *is* planned: A new data type `ShortString' (or `ShortStr'?) which will be the UCSD/Borland version of Strings. In many contexts, they are better than Extended Pascal string schemata because they have only 1 byte overhead instead of 8. (But this will be a lot of work. Anybody interested to help here???)

(Are you planning to make strings regular schema types then -- regular except for the extended syntax that allows s[n]?)

No. They are exceptions in yet another way because they have the implicit read-only "length" field.

Greetings,

Peter

Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125]