Re: UNICODE version of _T(x) macro

From: Asmus Freytag (
Date: Tue Nov 23 2010 - 04:25:00 CST

  • Next message: Michael Everson: "Re: Are Latin and Cyrillic essentially the same script?"

    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.


    This archive was generated by hypermail 2.1.5 : Tue Nov 23 2010 - 04:27:50 CST