Re: UTF8 and std::string
Alf P. Steinbach wrote:
{This thread is drifting too far off topic, follow-ups are likely
to be
rejected unless they include Standard C++ relevant content. -mod/fwg}
* Pete Becker:
Alf P. Steinbach wrote:
As a practical matter consider wide character literals.
FooW( L"Hello, hello?" );
where FooW is some API function.
If wchar_t isn't what the API level expects, this won't compile.
Why should it compile? The idiomatic way to write this is
Foo(_T("Hello, hello?"));
I'm sorry, no.
I'm not sure how topical this is, but we're talking about a library
(the
Windows API)
No, it's an operating system interface. Libraries can impose whatever
application-level policies their writers like; if you don't want to
write things their way you don't have to use the library. OS interfaces
should be far less restrictive. Some application writers may prefer wide
characters that are wider than 16 bits, and the OS interface should not
make that significantly harder.
Once you abandon that indirection layer
you're locked into a specific choice of type.
I'm sorry, no. There is no indirection layer (an indirection layer
would be what many higher level libraries provide through smart string
classes).
I'm the one who used the term, so you don't get to redefine it. An
indirection layer is anything that lets you change the meaning of code
that uses it, without rewriting that code.
There is however a C/C++ "choice" layer, if a set of macros
might be called a layer, choosing between only wchar_t or only char,
which does not work for functions that come in only one variant, and
which in modern versions of the OS has no benefits; in particular, the
choice layer does not remove the coupling between wchar_t and a
particular OS-defined size.
Macros can provide a far broader range of functionality than merely
choosing between char and wchar_t. The fact that the MS _T macro only
does these two is not inherent in macros, but is the result of a
decision made by the writer of that macro. It would be possible to write
that macro that converted literal character strings into a
compiler-specific array type that could be passed to the Windows API.
That approach would not impose an application-wide requirement that
wchar_t be 16 bits wide.
To restate my earlier point, which none of the above addresses, it's not
a disaster if FooW(L"Hello, hello?"); doesn't compile. So it's not
self-evident that the argument to a function that traffics in UTF-16
should be wchar_t*.
--
Pete Becker
Roundhouse Consulting, Ltd.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]