The documentation isn't clear on this, but GetLength() returns the number of XCHARs used in allocating the string. For the CSimpleStringA template specialization, XCHAR is defined as CHAR (8 bits each). For the CSimpleStringW template specialization, XCHAR is defined as WCHAR (16 bits each).

This is why the documentation notes the behavior of lead and trail bytes in a multi-byte character--but that's only the CHAR/MCBS side.

Its behavior for Unicode has similar problems. Windows NT (since Windows 2000) handles Unicode in UTF-16 encoding, and uses arrays of WCHAR (or wchar_t, if you prefer) to contain Unicode strings. Since a single WCHAR value can't represent all possible Unicode codepoints, some codepoints will need to be represented as two WCHAR values.

This means that GetLength() does not guarantee an accurate character count for either MBCS or Unicode, as some characters in both encodings will require more bits than CHAR or WCHAR, respectively, will provide them. Instead, GetLength() returns a derivation of byte count of the string, which is still useful.

To find the byte length of a CSimpleStringA specialization of CSimpleStringT, call GetLength() and use the value directly; that's your byte length.

To find the byte length of a CSimpleStringW specialization of CSimpleStringT, call GetLength() and multiply the value by sizeof(WCHAR); that's your byte length.

If you can get at the class's definition of XCHAR, then you can multiply by sizeof(XCHAR) as a generalization that works for both cases.

To find the character length, you'll need to use some other function. There are functions within Windows which are intended as safe means of parsing MBCS and UTF-16 for character counts, but you'll need the source string's byte length in order to use them appropriately. Now you know how to find that.