Is this string function efficient?

[Thaddy]

As I said: it is only the fastest in very simple scenario's where ASCII 0..127 is guaranteed. My point is assignments are safer and prevent users (Lazarus users in particularl) from making mistakes.
AND the buffer size is still wrong as I already explained.

But given ASCII 0.127, OK, you have my blessing although if you need that much string copying to save so little time I guess you would should be fired...

Normal users should use direct assignment. period.

For lower ASCII both naive solutions gain some speed over assignment, that is true.

[munair]

UTF-8 is backwards compatible with plain ASCII. You can iterate the data using the good old byte offsets. Just ignore anything outside ASCII.

Provided we speak of the first 128 bytes.

[SymbolicFrank]

Even with UTF-32 not all Unicode chars have the same length (I wish they did, but they don't).

[Thaddy]

Even with UTF-32 not all Unicode chars have the same length (I wish they did, but they don't).

Wrong: UTF32 is a fixed length format: 4 bytes. As per the standard.

[munair]

Even with UTF-32 not all Unicode chars have the same length (I wish they did, but they don't).

Thaddy is correct. UTF-32 causes the least conversion problems, even though it's not ASCII-compatible. The only downside is that ASCII files converted to UTF-32 would be four times the size, which is probably why UTF-8 has become the internet and UNIX standard.

[SymbolicFrank]

Nope. That was before they allowed composite characters.

[Thaddy]

Nope. That was before they allowed composite characters.

Wrong:
Yes:
http://www.unicode.org/versions/Unicode5.0.0/ch03.pdf  // "The Standard"
http://www.unicode.org/faq/utf_bom.html  See the table....
https://en.wikipedia.org/wiki/UTF-32
UTF32 is fixed length, UCS(2) is fixed length. Ansi is fixed length
UTF8 is variable length, UTF16 is variable length.
You are mixing things up. Probably confuse  UCS2 (Delphi "unicode16") and UTF16.

You may also be confused because FPC has no native UTF32String type yet, AFAIK.

Any of UTF16 + all extensions to it can be expressed in a single 4 byte UTF32 and there is room to spare to repeat that whole process at least 16 times, even if reserved is taken into account.
The actual space is a power function to UTF16 or UTF8, were it not for reserved entries. The theoretical limit is 2^ 32 or 4.294.967.296 or 4 billion (4294 million) pictures. These - of course - do not all exist....
Even if we include all Martian dialects and languages, we have still room to spare for several other planets. Withdraw your remark. (or prove me wrong, which you can't)

[SymbolicFrank]

Ask Juha.

[JuhaManninen]

Ask Juha.

This thread is locked for some reason. Replies must go to a new thread or somewhere. I can still add a comment.
Please see the older thread:
 http://forum.lazarus.freepascal.org/index.php/topic,39045.msg268507.html#msg268507
Shortly put: Only codepoints are encoded!
See e.g. characters: ÓÓ
One of them is composed of 2 separate codepoints. If you encode it with UTF-32, it will still be 2 codepoints.
The true complexity of Unicode is outside of codepoints. People should not concentrate on encodings so much, codepoints are easy to get right anyway.