"On the face of it, UTF-32 would seem to be the obvious choice of Unicode encoding forms for an internal processing code because it is a fixed-width encoding form. It can be conformantly bound to the C and C++ wchar_t, which means that such programming languages may offer built-in support and ready-made string APIs that programmers can take advantage of."

I don't understand how a 32 bit code can be conformantly bound to a wchar_t in C and C++, as sizeof(wchar_t) = 16.

Of course I was referring to Microsoft compilers where sizeof(wchar_t) = 2 bytes = 16 bits,

It is clear to me that the statement that I reproduced above in the Unicode doc is in explicit contradiction with this

"The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers."

If my understanding is not correct please let me know why, so I can improve to meet your high standards,

Your second quote points out that binding UTF-32 to wchar_t is not portable. Nobody disagrees with that. That binding is also a decision by the compiler vendor, and not usually something the user of the compiler (C++ programmer) can configure.

The documentation in the Unicode Standard has to cover anybody using or implementing the standard - that includes compiler vendors adding Unicode support to their compilers - and yes, they could bind their wchar_t support to UFT-32 and still be conformant to the C/C++ standards.

However, I believe the original text passage you cite from the Unicode Standard does not recommend simply to bind UTF-32 to wchar_t.

Quote:

On the face of it, UTF-32 would seem to be the obvious choice ...

(emphasis added).

That clearly implies that, despite first appearances, some other choices would most likely be better, so there's no actual contradiction between the text snippet you quote from chapter 2 and best implementation practices.

I appreciate your careful reading of the standard, but my take is that this is just an introductory sentence to a longer discussion and isn't as problematic as it may appear.

Who is online

Users browsing this forum: No registered users and 5 guests

Quick-mod tools:

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum