Why no tstring, tcerr, tostringstream, etc

Discussion in 'C++' started by Bill Davy, Nov 27, 2008.

  1. Bill Davy

    Bill Davy Guest

    Just curious. I often define them myself.

    Bill
     
    Bill Davy, Nov 27, 2008
    #1
    1. Advertising

  2. Bill Davy

    Bill Davy Guest

    Xxxx <=> char
    wXxxx <=> wchar
    tXxxx <=> TCHAR

    By analogy with:

    int _tmain(int argc, _TCHAR* argv[])

    {

    if ( argc < 3 )

    {

    tostringstream s;

    s << argv[0] << _T(": need priority and command arguments at least\n");

    It's tedious getting hex numbers when you write "cerr < argv[0]"


    "Pete Becker" <> wrote in message
    news:2008112706433916807-pete@versatilecodingcom...
    > On 2008-11-27 05:34:10 -0500, "Bill Davy" <> said:
    >
    >> Just curious. I often define them myself.
    >>

    >
    > What do you want them to mean?
    >
    > --
    > Pete
    > Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
    > Standard C++ Library Extensions: a Tutorial and Reference
    > (www.petebecker.com/tr1book)
    >
     
    Bill Davy, Nov 27, 2008
    #2
    1. Advertising

  3. Bill Davy wrote:
    > Xxxx <=> char
    > wXxxx <=> wchar
    > tXxxx <=> TCHAR
    >
    > By analogy with:
    >
    > int _tmain(int argc, _TCHAR* argv[])
    >
    > {
    >
    > if ( argc < 3 )
    >
    > {
    >
    > tostringstream s;
    >
    > s << argv[0] << _T(": need priority and command arguments at least\n");
    >
    > It's tedious getting hex numbers when you write "cerr < argv[0]"


    There's no TCHAR or _tmain in C++, it's a Microsoft specific extension.
    It's meant to simplify the migration from Ansi/ASCII to Unicode for
    Application that also must run on older Windows version without Unicode
    support.

    You would have to ask on a Microsoft or VC++ related forum, why they
    didn't also provide typedefs for tstring, tcerr etc.

    The easiest solution is to use Unicode (wchar_t) or non-Unicode (char)
    exclusively. If a program should support Unicode, use wchar_t, otherwide
    use char.

    --
    Thomas
     
    Thomas J. Gritzan, Nov 27, 2008
    #3
  4. On 2008-11-27 13:47, Thomas J. Gritzan wrote:
    > Bill Davy wrote:
    >> Xxxx <=> char
    >> wXxxx <=> wchar
    >> tXxxx <=> TCHAR
    >>
    >> By analogy with:
    >>
    >> int _tmain(int argc, _TCHAR* argv[])
    >>
    >> {
    >>
    >> if ( argc < 3 )
    >>
    >> {
    >>
    >> tostringstream s;
    >>
    >> s << argv[0] << _T(": need priority and command arguments at least\n");
    >>
    >> It's tedious getting hex numbers when you write "cerr < argv[0]"

    >
    > There's no TCHAR or _tmain in C++, it's a Microsoft specific extension.
    > It's meant to simplify the migration from Ansi/ASCII to Unicode for
    > Application that also must run on older Windows version without Unicode
    > support.
    >
    > You would have to ask on a Microsoft or VC++ related forum, why they
    > didn't also provide typedefs for tstring, tcerr etc.
    >
    > The easiest solution is to use Unicode (wchar_t) or non-Unicode (char)
    > exclusively. If a program should support Unicode, use wchar_t, otherwide
    > use char.


    Just a note of caution, wchar_t is not guaranteed to work with or
    represent Unicode codepoints. You have to check the documentation of the
    development tools you are using to be sure.

    --
    Erik Wikström
     
    Erik Wikström, Nov 27, 2008
    #4
  5. Bill Davy

    James Kanze Guest

    On Nov 28, 12:05 am, Paavo Helde <> wrote:
    > "Thomas J. Gritzan" <> kirjutas:


    > > The easiest solution is to use Unicode (wchar_t) or
    > > non-Unicode (char) exclusively. If a program should support
    > > Unicode, use wchar_t, otherwide use char.


    > Or use char and UTF-8 exclusively, to support Unicode. UTF-8
    > seems to be the preferred encoding in network and XML world,
    > as well as on Linux desktops. The drawback is that on Windows,
    > you might have to translate to UTF-16 (that's what Windows is
    > using) and back often.


    Unicode is the universally preferred external encoding: files,
    network, etc. (although XML requires support for UTF-16 as
    well). Within the program, there are legitimate arguments for
    all three: UTF-8, UTF-16 and UTF-32.

    > Using wchar_t does not guarantee Unicode automatically, as it
    > might be mapped to UTF-16 on Windows and to UTF-32 on other
    > platforms, which are totally different things and need
    > different approach.


    UTF-16 and UTF-32 are both Unicode, and for some (many?, most?)
    applications, can be handled exactly the same. UTF-8 is also
    Unicode, but depending on the application, may introduce
    additional complexities. If you're only doing very simple
    things, just copying the strings and comparing for equality, for
    example, UTF-8 is no more work than the others. Interestingly
    enough, if you're doing very complex things, like typography,
    UTF-8 is also not significantly more difficult. Between the two
    extremes, however, there are cases where UTF-16 or UTF-32 can
    make life easier.

    Of course, on a lot of systems, wchar_t isn't Unicode. If you
    want to be sure of any one particular encoding, you'll have to
    use a typedef, and write a lot of code yourself. I've not
    looked at it lately, but at least in the past, the best library
    around for Unicode was ICU, see http://icu-project.org/; this
    uses UTF-16.

    > If you are coding for Windows only, then the wise thing (which
    > does not mean I'm actually recommending it!) would be to use
    > their TCHAR and friends, they most probably will remain
    > back-compatible to some extent.


    The problem is that they promote a lie; the give the impression
    that you can easily switch to and from Unicode, just by changing
    a typedef.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Nov 28, 2008
    #5
  6. Bill Davy

    James Kanze Guest

    On Nov 28, 12:44 pm, Hendrik Schober <> wrote:
    > James Kanze wrote:
    > > On Nov 28, 12:05 am, Paavo Helde <> wrote:
    > > [...]


    > >> If you are coding for Windows only, then the wise thing
    > >> (which does not mean I'm actually recommending it!) would
    > >> be to use their TCHAR and friends, they most probably will
    > >> remain back-compatible to some extent.


    > > The problem is that they promote a lie; the give the
    > > impression that you can easily switch to and from Unicode,
    > > just by changing a typedef.


    > I've done this, although not using 'TCHAR', and across
    > several platforms. What makes this impossible IYO?


    The fact that the way the encodings work is different.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Nov 28, 2008
    #6
  7. Bill Davy

    James Kanze Guest

    On Nov 28, 8:39 pm, Hendrik Schober <> wrote:
    > James Kanze wrote:
    > > On Nov 28, 12:44 pm, Hendrik Schober <> wrote:
    > >> James Kanze wrote:
    > >>> On Nov 28, 12:05 am, Paavo Helde <> wrote:
    > >>> [...]


    > >>>> If you are coding for Windows only, then the wise thing
    > >>>> (which does not mean I'm actually recommending it!) would
    > >>>> be to use their TCHAR and friends, they most probably
    > >>>> will remain back-compatible to some extent.


    > >>> The problem is that they promote a lie; the give the
    > >>> impression that you can easily switch to and from Unicode,
    > >>> just by changing a typedef.


    > >>   I've done this, although not using 'TCHAR', and across
    > >>   several platforms. What makes this impossible IYO?


    > > The fact that the way the encodings work is different.


    >   Um, I guess the confusion stems from your "just by changing
    >   a typedef". Of course, there's a lot more required than just
    >   changing a typedef, but it can be done so that just changing
    >   a typedef does all this. I suppose you referred to the former
    >   (it needs more), while I referred to the latter (it can be
    >   done so that changing a typedef does everything that needs to
    >   be done).


    If all of the manipulation (starting with just incrementing)
    goes through functions, and you have overloads for these
    functions, with different implementations, then you're probably
    right. The idea that the typedef seems to give, however, is
    that that's all that changes.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Nov 29, 2008
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Robin Cull
    Replies:
    5
    Views:
    442
    Andrew Dalke
    Jul 31, 2003
  2. Daniel Joyce

    Python Audio (Alpy, Fastaudio, Etc Etc)

    Daniel Joyce, Sep 16, 2003, in forum: Python
    Replies:
    1
    Views:
    951
    Markus Wankus
    Sep 16, 2003
  3. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    984
    Mark Rae
    Dec 21, 2006
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,234
    Smokey Grindel
    Dec 2, 2006
  5. Kevin Walzer

    Re: PIL (etc etc etc) on OS X

    Kevin Walzer, Aug 1, 2008, in forum: Python
    Replies:
    4
    Views:
    451
    Fredrik Lundh
    Aug 13, 2008
Loading...

Share This Page