New GPC beta: gpc-971001_(re)

Sat, 11 Oct 1997 13:17:47 +0100 (BST)

On Sat, 11 Oct 1997 01:23:15 +0200 Frank Heckenbach  
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


The African Chief (laa12@cc.keele.ac.uk)