[DUG] String Concatenation

[John Bird]

That might explain something I found once when code in D5 like

   teststr:=uppercase(trim(line));

Would produce unpredictable stuff in the string teststr in one program
consistently, yet if I removed the trim or prcessed the string a different
way it worked,  yet this sort of code works in other places as expected.  

Do you have references to what to look out for in D5?

John 


-----Original Message-----
From: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz] On
Behalf Of Rohit Gupta
Sent: Friday, 4 November 2005 12:51 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] String Concatenation


You havent mentioned what version you are using.  D5 has a severe 
problem where it gets confused between shortstring and ansistring.  It 
just shows up at random, when you examine the assembler code, you can 
see the fault.  The only solution I found was to explicitly declare 
ansistring and shortstring instead of using string.  Of course thsi 
still stuffs up because all vcl uses string.

I havent had any problems with D7 or D2005.

You dont have any timers or events stuffing things up ? 

Note you really wanted maxDataIndex-1

Allan, Samuel wrote:

> We have a weird problem where we are building a string up. It is quite
> a large string, but not exceptionally large. About maybe 1000 
> characters. The code to create the string approximates:
>  
> insertString, finalString: string;
>  
> for i := 0 to maxDataIndex do
>    insertString := insertString + dataItem[i];
>  
> finalString := CONSTANT_A + insertString + CONSTANT_B + insertString +
> CONSTANT_C;
>  
> Without throwing an overflow warning or any other warning, this code
> results in a finalString where the first instance of insertString is 
> whole and complete. The second instance is interrupted half-way by 
> what looks like a random memory dump, and there is no CONSTANT_C 
> afterwards. insertString remains pristine and untouched.
>  
> We have also tried several variations on the above code:
>  
> Using Copy() to create two additional strings, one for each insert.
> Same result for finalString, both additional insert strings are fine.
>  
> Putting placeholder tokens in the finalString, then running
> StringReplace(). Same result.
>  
> We tried to isolate the code in a separate application. The separate
> application works fine, as you would expect. So we think it may be 
> something to do not with the code itself, but with the structure of 
> our application. However, code like this is widely used within this 
> application and elsewhere works fine.
>  
> Our application implicitly compiles several packages into itself. The
> code in question is in one of these packages. So compiling any change 
> to it requires compiling the package, then compiling the application.
>  
> We have searched the web, and found an exact match for this posted in
> some newsgroup in 1998, but there were no responses. The match does 
> not mention packages however.
>  
>
>-----------------------------------------------------------------------
>-
>
>_______________________________________________
>Delphi mailing list
>Delphi at ns3.123.co.nz http://ns3.123.co.nz/mailman/listinfo/delphi
>  
>


_______________________________________________
Delphi mailing list
Delphi at ns3.123.co.nz http://ns3.123.co.nz/mailman/listinfo/delphi