[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

Why no tstring, tcerr, tostringstream, etc

Bill Davy

11/27/2008 10:34:00 AM

Just curious. I often define them myself.

Bill


10 Answers

Pete Becker

11/27/2008 11:44:00 AM

0

On 2008-11-27 05:34:10 -0500, "Bill Davy" <Bill@XchelSys.co.uk> 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

11/27/2008 12:37:00 PM

0

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" <pete@versatilecoding.com> wrote in message
news:2008112706433916807-pete@versatilecodingcom...
> On 2008-11-27 05:34:10 -0500, "Bill Davy" <Bill@XchelSys.co.uk> 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)
>


Thomas J. Gritzan

11/27/2008 12:47:00 PM

0

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

Erik Wikström

11/27/2008 6:28:00 PM

0

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

Paavo Helde

11/27/2008 11:06:00 PM

0

"Thomas J. Gritzan" <phygon_antispam@gmx.de> 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.

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

Paavo

James Kanze

11/28/2008 8:53:00 AM

0

On Nov 28, 12:05 am, Paavo Helde <pa...@nospam.please.ee> wrote:
> "Thomas J. Gritzan" <phygon_antis...@gmx.de> 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-pro... 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:james.kanze@gmail.com
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

Hendrik Schober

11/28/2008 11:45:00 AM

0

James Kanze wrote:
> On Nov 28, 12:05 am, Paavo Helde <pa...@nospam.please.ee> 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?

Schobi

James Kanze

11/28/2008 2:45:00 PM

0

On Nov 28, 12:44 pm, Hendrik Schober <spamt...@gmx.de> wrote:
> James Kanze wrote:
> > On Nov 28, 12:05 am, Paavo Helde <pa...@nospam.please.ee> 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:james.kanze@gmail.com
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

Hendrik Schober

11/28/2008 7:40:00 PM

0

James Kanze wrote:
> On Nov 28, 12:44 pm, Hendrik Schober <spamt...@gmx.de> wrote:
>> James Kanze wrote:
>>> On Nov 28, 12:05 am, Paavo Helde <pa...@nospam.please.ee> 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).

Schobi

James Kanze

11/29/2008 12:58:00 PM

0

On Nov 28, 8:39 pm, Hendrik Schober <spamt...@gmx.de> wrote:
> James Kanze wrote:
> > On Nov 28, 12:44 pm, Hendrik Schober <spamt...@gmx.de> wrote:
> >> James Kanze wrote:
> >>> On Nov 28, 12:05 am, Paavo Helde <pa...@nospam.please.ee> 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:james.kanze@gmail.com
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