Okay, Just looked at the Decomplied code.
Was quite interesting.
PChar( AString )^ does as expected and passes the address of the first
character in the AString, as explained in the help, and hence the caution of
using this if more than one string variable references the "AString". Is
very quick as is just a plain typecast.
AString[1] ends up doing the same, but first calls uniquestring, and then
passes in the address of the unique string just created,
and updates the address of the AString, eg the address of AString is changed
by making a copy of "AString" if there is more than one reference.
In essence, both work the same and have the same effect.
They are both allocated on the heap, and the address is always absolute.
Myles.
> -----Original Message-----
> From: Aaron Scott-Boddendijk [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, August 06, 1999 4:31 PM
> To: Multiple recipients of list delphi
> Subject: Re: [DUG]: Strings, PChars, and TFileStream.Read
>
> > Ok, that does work. I'm confused about buffers and buffer locations
> > though. If passing LChar[1] as an untyped var parameter passes a
> > (constructed on the fly?) address pointing to the first character in
> > LChar, which is then used as the address to Read into by TFileStream,
> > shouldn't passing PChar(LChar)^ as an untyped var parameter do the same
> > thing?
>
> I'm suspecting that it's actually sending a dereference to the LChar[0]
> rather
> than LChar[1] which is not valid since I think there's some synthesizing
> of
> data done by the compiler for casting string to pchar since (as I
> understand it)
> string points into a heap location (an offset or absolute address?) where
> the
> first part is the length of the string.
>
> > Or is the problem one of scoping, that the register or memory
> > location or whatever which holds the address which has been constructed
> > by the cast PChar(LChar) isn't persistent inside the call, so that it's
>
> Traditionally Casts are 'doing' anything they're just indicating to the
> compiler
> which type references to look up in the symbol table.
>
> The issue isn't one of persistence ;)... I'm fairly sure it's changing
> between
> absolute addressing and an offset into a heap...
>
> Confirmation from anyone that actually has looked at code generation of
> Pchar(String) casts in D4?
>
> --
> Aaron Scott-Boddendijk
> Jump Productions
> (07) 838-3371 Voice
> (07) 838-3372 Fax
>
>
> --------------------------------------------------------------------------
> -
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
application/ms-tnef
