Why no tstring, tcerr, tostringstream, etc

[Bill Davy]

Just curious. I often define them myself.

Bill

 

[Bill Davy]

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]"

 

[Thomas J. Gritzan]

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.

 

[Erik Wikström]

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.

 

[James Kanze]

"Thomas J. Gritzan" <[email protected]> kirjutas:

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]

[...]

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]

James Kanze 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.