Need help on TCHAR

[gshy2014]

Hi, all.
IN Windows, TCHAR is translated to be wchar or char according to
whether UNICODE is defined. Dose the complier handle the UNICODE(define
or not define) according to the OS ?

Many thanks

 

[Jonathan Mcdougall]

Hi, all.
IN Windows, TCHAR is translated to be wchar or char according to
whether UNICODE is defined. Dose the complier handle the UNICODE(define
or not define) according to the OS ?

This newsgroup deals with standard C++, not compiler specific features.
Please see
http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.9 for
newsgroup suggestions.


Jonathan

 

[Phlip]

IN Windows, TCHAR is translated to be wchar or char according to
whether UNICODE is defined. Dose the complier handle the UNICODE(define
or not define) according to the OS ?

The macro UNICODE (and _UNICODE) are compile time constants. That means they
are set at compile time. No program written in C++ can ever change a #define
or /D constant at run-time. Compiling with and without /DUNICODE will give
you two different executables that will behave differently when run on the
same machine.

Warning: C++ is the topic of this newsgroup. Not UNICODE, or Win32, or the
differences between Win98 and WinNT, or the VC++ compiler. You must ask
complete questions about these things, individually, on their appropriate
newsgroups, to get the best answers. Your current question is on-topic (by
accident), but your next question (how the compiler and header files respond
to the UNICODE flag) will be off-topic here, so you should use Google to
find the best newsgroup.

 

[Phlip]

This newsgroup deals with standard C++

Read the question again. ;-)

 

[Richard Herring]

Read the question again. ;-)

I read it three times and I still don't get it. The second word of the
introductory sentence is "Windows" and the third is "TCHAR". When we get
to the actual question, it refers to "the compiler" and "the OS". If
that's not platform-specific, what is?

 

[Alf P. Steinbach]

* Richard Herring:

I read it three times and I still don't get it. The second word of the
introductory sentence is "Windows" and the third is "TCHAR". When we get
to the actual question, it refers to "the compiler" and "the OS". If
that's not platform-specific, what is?

I think Phlip's point was the the OP was possibly asking /whether/ TCHAR
was a standard type with some built-in support, "Dose the compiler...".

 

[Phlip]

I read it three times and I still don't get it. The second word of the
introductory sentence is "Windows" and the third is "TCHAR".

Right. And then you pretended you knew nothing about them. This is an
example of why "it's not in the Standard" is sometimes not a useful detector
for topicality.

When we get to the actual question, it refers to "the compiler" and "the
OS". If that's not platform-specific, what is?

We will interpret "/D" in the following as "the thing that predefines things
as a command line argument to the compiler". I am aware little of that is
Standard; all compilers have such a thing, so we could add excess verbiage
in place of "/D" and get away with it...

The question was ambiguous, with two potential:

- does the current OS affect the compiler and turn on
a /D for a given macro?

- does the current OS affect the executing program and
turn a macro on for it?

The answer to the first one is that some "make" systems, which are
off-topic, will select which macros to compile with, but they never select
the optional ones; they leave them up to you.

The answer to the second one is the compiler locks in all #define and /D
values when it compiles, so nothing can ever change these at run-time.

The first answer is of marginal topicality, but it's something of interest
to all C++ programmers, and it would hopefully resolve this thread.

The second answer is on topic because it shows someone needs to understand
"compile-time constants".

Note I took the dreaded terms Windows, UNICODE, and TCHAR out of the
questions. The best way to improve newsgroup quality is to seek good
on-topic answers, if they are at all possible, while recommending other
newsgroups for the off-topic bits.

 

[Richard Herring]

Right. And then you pretended

In the case of "TCHAR", no pretence was necessary. I write a good deal
of code for Windows, but I've never had to deal with something called
TCHAR.

you knew nothing about them.

Actually, in the first instance I simply kept quiet, having nothing
useful to tell the original poster.

This is an
example of why "it's not in the Standard" is sometimes not a useful detector
for topicality.


We will interpret "/D" in the following as "the thing that predefines things
as a command line argument to the compiler". I am aware little of that is
Standard; all compilers have such a thing, so we could add excess verbiage
in place of "/D" and get away with it...

The question was ambiguous, with two potential:

- does the current OS affect the compiler and turn on
a /D for a given macro?

- does the current OS affect the executing program and
turn a macro on for it?

The answer to the first one is that some "make" systems, which are
off-topic, will select which macros to compile with,

And some compilers will do the same. I wouldn't be surprised to find
that the ones targeting Windows will make different selections according
to whether they are running under 95 or 98 or 2000 or NT or XP ...

but they never select
the optional ones; they leave them up to you.

Which is less than helpful unless you can determine _which_ ones are
optional.

The answer to the second one is the compiler locks in all #define and /D
values when it compiles, so nothing can ever change these at run-time.

The first answer is of marginal topicality, but it's something of interest
to all C++ programmers, and it would hopefully resolve this thread.

All it does is to describe the mechanism, not the actual outcome -
_which_ macros get defined as what in a given environment?

The second answer is on topic because it shows someone needs to understand
"compile-time constants".

Only *if* your interpretation of the second potential meaning of the
question is valid; otherwise it's just a confusing digression.

Note I took the dreaded terms Windows, UNICODE, and TCHAR out of the
questions. The best way to improve newsgroup quality is to seek good
on-topic answers,

Of course

if they are at all possible,

.... and there's the rub...

while recommending other
newsgroups for the off-topic bits.

The degree of _useful_ on-topic information you can supply rapidly
becomes marginal.

Compare:

"some systems will select which macros to compile with, but they never
select the optional ones. They don't change at run-time"

"under compiler X and OS Y, the following macros are automatically
defined and therefore TCHAR is compiled as..."

 

[Noah Roberts]

I think Phlip's point was the the OP was possibly asking /whether/ TCHAR
was a standard type with some built-in support...

Which in the end it is as it's just a define for either wchar or char.
TCHAR itself is an non-standard define but you can use it and still
remain 100% within the standard. Of course this wouldn't be
adventageous as the typedef is meant to be used in conjunction with
non-standard libraries on a very particular platform.

 

[gshy2014]

Thank you all for explanations.
Philp got my question: does the current OS affect the complier and turn
on a /D for a given macro. However, I am not clear about Philp's
answer. Philp, your answer is 'yes' or 'no'?

Richard Herring, Does you mean that some compliers and OS will
automatically determine what TCHAR is compiled as: wchar or char, and
the programmers need not turn on '/D' when compling?

Maybe, I posted an off-topic questions here. However, I think some C++
programmers will benefit from it.

 

[Phlip]

Philp got my question: does the current OS affect the complier and turn
on a /D for a given macro. However, I am not clear about Philp's
answer. Philp, your answer is 'yes' or 'no'?

Now I don't know the question. Pick one:

A> At compile time, does the compiler detect the OS type and turn on
/DUNICODE?

B> At runtime, does the UNICODE macro change?

The answer to A is "Some compilation systems do that to some /D macros, and
they are all off-topic. I know of no Win32 compiler which does that for
UNICODE, and doing it would defeat the (off-topic) purpose of the UNICODE
macro, which is to compile for a target _different_ from the current OS -
either Win95-derived or WinNT-derived.

You will get a much better answer if you use Google Groups to find a topical
newsgroup, and then post a new, complete question to it.

(And the time has finally come to forget about any platform derived from
Win95!)

The answer to B is (on-topic) never ever ever, because all macros get
compiled at compile time. When they trigger "conditional compilation" (look
it up) the resulting code locks-down and never changes at runtime. Generally
speaking, only an 'if' statement will change things at runtime!

Richard Herring, Does you mean that some compliers and OS will
automatically determine what TCHAR is compiled as: wchar or char, and
the programmers need not turn on '/D' when compling?

No, they never will, and don't ask him that question again. Please read our
thread carefully to understand that we cannot give good answers to off-topic
questions here. We generally do our best to give bad answers, as a
cautionary tale. ;-)

Maybe, I posted an off-topic questions here. However, I think some C++
programmers will benefit from it.

Thanks, but that's not the point of topicality. I can review Richard's
answer, and he mine, when we answer an _on_topic_ question. But if you ask
an off-topic question about a system I know and Richard does not, he cannot
review or correct my answer. So posting to the most topical newsgroup (
probably ) is in everyone's best interests
here.