Yes, that is the advantage of having ansistring, you can call the functions who takes pchars.
But not the other way around, thus it is better, if all your functions take pchars.
You *can* convert PChar to AnsiString easily. But it involves copying the characters (if you want to do it 100% safely), so it may have a speed penalty.
RTL and LCL convert back and forth between PChar and AnsiString, to interface with WinAPI, GTK... It definitely works. The only question is performance, but it's not as critical in my experience.
What I just realized last week, when you use strings the entire function gets wrapped in a try .. finally block, at least on linux amd64. That is really bad.
It has always been this way, and is necessary on all platforms. You can turn it off like Thaddy writes, but be careful -- if the routine exits with exception, the AnsiString will not be correctly finalized.
See also
http://wiki.freepascal.org/Avoiding_implicit_try_finally_section (man, an old wiki page that I myself started > 10 years ago...
The real issue are slices. E.g. you have a 1000 character string s and want to do something with the middle, characters s[400] to s[600]. With a pchar, you can just point in the middle and use a smaller length. With a string, everything in that range needs to be copied.
If you do it naively, using Copy on a string, then indeed it will have a cost.
Then again, doing it naively on PChar also has a cost.
Your solution with addressing something in the midde can be used with PChar or AnsiString, no matter. You can take a pointer to the middle of AnsiString contents, and iterate over it. In all cases, it requires special treatment, since the result has to be bounded by some variable specifying slice length, not by a #0 character.
In general, I do agree that PChars can achieve higher performance. As often, if you do things manually, then you can squeeze much better performance than a solution that tries to manage memory automatically.
I just don't feel that doing this for the whole application, and resigning from AnsiStrings everywhere, is justified. I would limit this only to the actual bottle-neck in your application.
Anyway, this depends on the type of applications you're writing (whether your bottle-neck does any string processing).
One minor correction. "As in all object-oriented languages", should be "most" instead of "all" in section 4.5
Fixed. Indeed, at least Python doesn't have them:)