I received a good question today from a developer who asked:
Why should one not use pointer arithmetic for string length calculation, access to string elements, or string manipulation ?
The main reason pointer arithmetic is not a good idea is that not all characters are represented by the same number of bytes. For example in some code pages (like Japanese) some characters (a, b, c ... and half-size katakana) are represented by one byte, while kanji characters are represented by two bytes. Thus you can not compute where the fifth character in a string is by simply adding 4 to the beginning byte pointer of the string. The fifth character could be as much as 8 bytes offset from the beginning pointer (5 kanji characters - 2 bytes each)
Even using Unicode you can not assume that each character is 16 bits (or a word), because if you are using the UTF-16 encoding, then some characters (supplementary characters) are represented by surrogate pairs (two 16 bit words). Some single characters are represent as a base character (like "a") plus one or more combining characters (such as some diacritic "^'). And if you are using UTF-8, then a character can be 1, 2, 3 or 4 bytes long.
That is why it is better to use APIs that are aware of these differences to walk through a string than to use pointer arithmetic. (See: StringInfo Class) In globalization best practices, you never assume that all characters are the same byte size.
Because sometimes, 0 (beginning pointer to a string array) + 4 (a high surrogate and a low surrogate [4 bytes]) = 1 (a single Unicode character).