From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Tue Nov 23 2010 - 04:25:00 CST
On 11/23/2010 1:58 AM, sowmya satyanarayana wrote:
>
>
> This what I am actually looking for. My ODBC application supports
> UTF-16, which is 2 byte width characters. This application is
> completely oriented around using _T(x) macro as Asmus Freytag figured out.
Yeah, it's nice when you can do without, but if your code is filled with
_T() macros for function arguments or static initializes, you've got to
find a way to make it work.
In 2003 there was an attempt to introduce u"x" to mean treat "x" as
UTF-16 (and U"x" to mean treat "X" as UTF-32).
With these extensions beyond "L" you can write a _T() macro to be
precisely UTF-16.
I don't know whether any recent compilers, especially in the Unix world
have taken up that convention, but it's worth a try to check out whether
that solves your problem. At the same time there was an attempt to
introduce char16_t and char32_t with guaranteed size and support as
UTF-16 and UTF-32. If your compiler supports these, then it may support
u and U for initializers.
Otherwise, I'm afraid you may be stuck with your solution - but the
problem is that you introduce temporary allocations and have memory
lifetime issues. I think your sample code would leak memory.
In C++ you can define a simple object that's useful for wrapping static
strings that are used as function arguments - the object will live just
as long as needed (i.e. until the function returns). For other strings,
your objects would have to be of global scope. But it's a pain nevertheless.
A./
This archive was generated by hypermail 2.1.5 : Tue Nov 23 2010 - 04:27:50 CST