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./
