On Sat, 11 Oct 1997 01:23:15 +0200 Frank Heckenbach heckenb@mi.uni-erlangen.de wrote:
The African Chief wrote:
[...]
AFAIK, since the characters after Length(x) in a string are undefined.)
Which is why you should only copy to length(s).
You probably should, but (AFAIK) you don't have to.
Agreed.
If I do "str1 := str2" , I do not expect an optimiser to make it into; "str1 := str2 + any junk after the length of str2, up till str2.capacity".
Not "str2 + any junk", it's still only "str2", according to the definition of (this kind of) strings. Generally, a string always contains "junk" after the length till the capacity, and you shouldn't rely on anything about this junk.
No, you shouldn't.
(E.g., I recently modified the WriteStr procedure so that it will not fill a (normal) string with spaces, #0's or whatever as it did before. Only arrays of char are padded with spaces, unless treated as CStrings. I don't think such a change should matter to any "good" program.)
No, it shouldn't. Maybe we are at cross purposes here. My original meaning was: if I write "str1 := str2", that is precisely what I should get - no more, no less. I should get in "str1" the exact number of characters that are in "str2", in the exact order - no more, no less. If an optimiser gives me that, I don't really care what else it does ...
A possible "fix" for the second problem (not the first one, though the appearance of the problem will be different then) would be "s[Length(s)+1]:=#0" (also, it's much more efficient).
I am not sure how this solves the problem.
When you explicitly write a #0 into the "junk" area, you can be sure that it will be there (because you don't use any string functions, such as assignments between strings). And it's more efficient because you don't have to copy the contents of the string (twice) and don't need any temp variables. Therefore, you don't have to limit the length of the string (in system.pas it's limited to 255 chars).
Okay, I understand that now ;-). However, this solution will not work if there is a maximum length for the string, and the string that is passed to the function has already reached that length.
program x;
uses strings;
Function Str2pChar ( s : String ) : pChar; Begin Str2pChar := StrNew ( StrCopy ( @s [1], @s[1] ) );
I don't understand this line. What do you expect "StrCopy ( @s [1], @s[1] )" to do? AFAICS, it copies a string into itself!?
More or less. Since it is already itself, nothing really should happen, but the side effect is that it provides the input for StrNew to work with, and it also saves on using another temporary variable. Perhaps this is a misguided saving?
OTOH, if you're using the strings unit anyway, is there anything wrong with StrPCopy?
If I used this routine in the system unit, I would not be using the strings unit there - but I can import "strcpy" from the C library, and call it "StrCopy". Even if I wanted to use StrpCopy, I would still need 2 variables - and you would also need more code. But if I used this in the system unit, I would not need
const s:string=' '+ ' '+ ' '+ ' '+ ' '#13#10'This program is OK.';
t:string=#8#8#8#8' wrong, sorry.'#0;
var p:pchar; begin p:=str2pchar(s); writeln(p); StrDispose(p); { need to dispose of the memory! } end.
This program does not work correctly in my BP.
It works correctly under my BP (BPW) and also under GPC.
It might seem to work for you because you pass s by value now, so now there will not be t after s in memory (on the stack), but something else.
Okay. I will do more tests then!
Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v4.01 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@keele.ac.uk