Board index » delphi » PChar <--> string conversions

PChar <--> string conversions

I'm currently playing around with the DOS FindFirst and
FindNext
functions. In the help, FindFirst is shown to accept a
PChar
parameter:

   FindFirst(PathSpec : PChar; Attrib : word; var DirInfo :
SearchRec)

or something like that. But I seem to remember that the old
version
TP6 had PathSpec : PathStr, a string[79].

Now I haven't changed any code, and my old TP6 programs are
still
compiling. So is BP doing a conversion for me? from PathStr
to
PChar?

So to what extent does BP do this for me? If I have two
PChar
variables P1 and P2, can I generate a third PChar variable
with
P3 := P1 + P2;  ?? Does it do the memory allocation?
Or P3 := Copy(P3,2,6);  ?? Does it free the memory
previously
allocated? What about locally defined variables? Does it
free them
at the end of the function?

Particularly with the advent of long filenames (or long-ish
filenames),
the 255 character string limitation may bring a few
programs unstuck.
So should all PathStrs be blindly converted to PChars?

Simon
--
Simon Carter                      Home: 14 Canterbury Rd,
Heathmont, Victoria 3135, Australia
TUSC Computer Systems Pty Ltd    Email: s...@tusc.com.au
666 Doncaster Road               Voice: 613 9840-4492 (BH)
613 9729-8836 (AH)
Doncaster 3105                     Fax: 613 9840-2277 (BH)
613 9729-8836 (AH)
Victoria, AUSTRALIA                WWW:
http://www.cs.monash.edu.au/~simonc

 

Re:PChar <--> string conversions


Quote
In article <314F46CA.2...@tusc.com.au> Simon Carter <s...@tusc.com.au> writes:
>I'm currently playing around with the DOS FindFirst and
>FindNext
>functions. In the help, FindFirst is shown to accept a
>PChar
>parameter:
>   FindFirst(PathSpec : PChar; Attrib : word; var DirInfo :
>SearchRec)

That's the definition of FindFirst as defined in the WinDOS unit, not the
DOS unit.  the DOS unit's FindFirst uses a string.

Quote
>or something like that. But I seem to remember that the old
>version
>TP6 had PathSpec : PathStr, a string[79].
>Now I haven't changed any code, and my old TP6 programs are
>still
>compiling. So is BP doing a conversion for me? from PathStr
>to
>PChar?

Nope, see above.

Quote
>So to what extent does BP do this for me? If I have two
>PChar
>variables P1 and P2, can I generate a third PChar variable
>with
>P3 := P1 + P2;  ?? Does it do the memory allocation?

This doesn't work.  You can't concatenate PChar strings this way.  Use
strcat() instead (in the Strings unit).

Quote
>Or P3 := Copy(P3,2,6);  ?? Does it free the memory
>previously
>allocated? What about locally defined variables? Does it
>free them
>at the end of the function?

No.  Again, use strcat().  There's a sample in the manual and should also be
in the online help.

Quote
>Particularly with the advent of long filenames (or long-ish
>filenames),
>the 255 character string limitation may bring a few
>programs unstuck.
>So should all PathStrs be blindly converted to PChars?

No need to.  Long file names (I'm assuming you're referring to Windows 95's
long names) are accessed with an entirely different set of DOS calls, and
are not directly supported by TP.  Since TP's DOS unit uses Pascal-style
strings, there's no need to convert, unless you feel so inclined to do
so.  :-)

Quote
>Simon
>--
>Simon Carter                      Home: 14 Canterbury Rd,
>Heathmont, Victoria 3135, Australia
>TUSC Computer Systems Pty Ltd    Email: s...@tusc.com.au
>666 Doncaster Road               Voice: 613 9840-4492 (BH)
>613 9729-8836 (AH)
>Doncaster 3105                     Fax: 613 9840-2277 (BH)
>613 9729-8836 (AH)
>Victoria, AUSTRALIA                WWW:
>http://www.cs.monash.edu.au/~simonc

--
Scott F. Earnest            | We now return you to our regularly scheduled
sco...@whiplash.res.cmu.edu | chaos and mayhem. . . .

Re:PChar <--> string conversions


Quote
In article <314F46CA.2...@tusc.com.au> Simon Carter wrote:

>I'm currently playing around with the DOS FindFirst and FindNext
>functions. In the help, FindFirst is shown to accept a PChar
>parameter:

>   FindFirst(PathSpec : PChar; Attrib : word; var DirInfo :SearchRec)

>or something like that. But I seem to remember that the old version
>TP6 had PathSpec : PathStr, a string[79].

Help states the function is available for both DOS and WINDOS Units but lists
only the WINDOS version of the function. BP7's DOS Unit still has FindFirst
declared as:

    procedure FindFirst(Path: PathStr; Attr: Word; var F: SearchRec);

Quote
>Now I haven't changed any code, and my old TP6 programs are still
>compiling. So is BP doing a conversion for me? from PathStr to
>PChar?

It is not converting the PathStr to a PChar for the call to FindFirst.  
Howver, DOS itself wants a PChar, so FindFirst is converting the string
before it calls the system's FindFirst.

Quote

>So to what extent does BP do this for me? If I have two PChar
>variables P1 and P2, can I generate a third PChar variable with
>P3 := P1 + P2;  ?? Does it do the memory allocation?

For some reason the compiler allows this statement, but the code will
generate some strange results.  To get the results you want, use:

        StrCopy(StrECopy(p3, p1), p2);

Quote
>Or P3 := Copy(P3,2,6);  ?? Does it free the memory previously
>allocated? What about locally defined variables? Does it free them
>at the end of the function?

     StrLCopy(p3, p3+2, 6);  

Assumes the first two chars are never nul, otherwise use:

        If StrLen(p3) > 2 Then
           StrLCopy(p3, p3+2, 6)
        Else p3^ := #0;

Or:     StrPCopy(p3, Copy(StrPas(p3), 2, 6));

Quote

>Particularly with the advent of long filenames (or long-ish filenames),
>the 255 character string limitation may bring a few programs unstuck.
>So should all PathStrs be blindly converted to PChars?

>Simon

Simon, welcome to the world of PChar.  BP and TPW have two types of strings.

The old Pascal style is an array [0..n] of Char with the 0th character
specifying the length or number of valid characters in the string.  It has
the advantage of allowing a string to contain any of the 256 characters and
being able to quickly determine the actual length of a string.  It has the
disadvantage of not being able to define strings longer than 255 characters.

The new string type is also an array[0..n] of Char, but in this case the
string begins with the 0th character and is terminated by a #0.  This type
of string (often called ASCIIZ or C-String) has the advantage of being able
to define long strings.  It has the disadvantage of not being able to
contain a #0 and requiring its length to be computed.

You would do best to think of them as two separate and distinct types much
in the same way that you think of Char and Byte.  Pascal's strong typing
requires you to use Char and Byte or Ord to convert between Char and Byte
variables.  This conversion is done at compile type and is more a statement
to the compiler saying that you know what you are doing.

Converting between the two types of strings is just as easy, but in this
case it must be done at run time.  Managing and manipulating strings is some
of the magic of BP that we have taken for granted over the years.  Using
PChar and C-Strings will make you appreciate the range checking, auto
truncation, and other features of string handling that you never had to be
concerned with.

When working with PChar and C-Strings think in terms of the STRING Unit.  
Remember that _you_ are now responsible for everything!  The R+ option does
nothing to prevent you from copying too much into a buffer.  You have to put
on your "C" thinking cap because it doesn't take much to generate wild
pointers and run-away strings.

Use StrPas to convert a PChar to a Pascal string: s := StrPas(p1);
Use StrPCopy to convert a Pascal string to a C-String: StrPCopy(p1, s);

Mixing PChar and Pascal string is akin to mixing oil and water.  If you keep
the two separate and remember to use StrPas and StrPCopy to make the
conversions, you'll have no problems.

                ..red

Quote
>--
>Simon Carter                      Home: 14 Canterbury Rd,
>Heathmont, Victoria 3135, Australia
>TUSC Computer Systems Pty Ltd    Email: s...@tusc.com.au
>666 Doncaster Road               Voice: 613 9840-4492 (BH)
>613 9729-8836 (AH)
>Doncaster 3105                     Fax: 613 9840-2277 (BH)
>613 9729-8836 (AH)
>Victoria, AUSTRALIA                WWW:
>http://www.cs.monash.edu.au/~simonc

Other Threads