Re: How to LPCTSTR Convert to char *



That external hardware is one of the "rare and exotic" situations "imposed by external
specifications" that I referred to. The number of people who do this are vanishingly
small (and I'm one of them...I deal with embedded systems all the time) compared to the
number of people who use 'char' because they've never grown beyond their first programming
course.

These are the people who are getting nuked by VS2005 which defaults to Unicode apps.

The compelling reason for some of my clients to move to VS.NET is that they can use
CStringA to create and handle the messages to their embedded systems while using the
normal CString (which might be CStringW) for the rest of the programming. A bit of
handwave at the interfaces suffices to transform representations, and we don't support
Unicode in the embedded systems. But for captions, labels, etc., we have to support it,
and when I coded these I made sure that all uses of 'char' had the property that they were
isolated to the embedded interface (rare and exotic situation imposed by external
specifications) but never escaped into the rest of the program. When I finally had to
convert one to Unicode, I did have, as I had designed in, a couple compilation errors,
which had the comment
// deal with Unicode issues here
and three lines of coding later it all worked, ready to be translated to languages whose
alphabets I cannot read.

But I think it is important, particuarly for new programmers, that people realize that the
world has changed, and the old 'char' data type is obsolete in most contexts. I've been
coding Unicode-aware for many years now (probably close to ten) and the number of times
this has saved me is astonishing. My clients are moving into international markets, and
they need a lot of work. Most of my work is cleaning up my old non-localized date, time,
and number-format stuff, whcih I try to be more careful of these days. But I've rarely
had serious problems turning on Unicode and recompiling, and in some cases, as I say, at
the boundaries, I did not make the effort to be fully Unicode-aware, but I made sure the
code wouldn't compile at all.
joe

joe
On Wed, 06 Dec 2006 14:01:00 -0500, r norman <r_s_norman@xxxxxxxxxxxx> wrote:

On Wed, 06 Dec 2006 13:12:20 -0500, Joseph M. Newcomer
<newcomer@xxxxxxxxxxxx> wrote:

An LPCTSTR is a const TCHAR *, so do you mean you want to remove the const attribute, or
you really want a 'char *' data type (remember that char and char* represent an obsolete
technology that should be used only in very rare and exotic situations where you are
absolutely guarnteed because of external specs to be using 8-bit characters, and should
never be coded as a matter of course in any program).

If you really want a 'char *', that is, a pointer to an 8-bit character string, then you
have to explain why you need it and how you plan to handle the down-conversion from
Unicode characters that have no 8-bit equivalents.

There are those of us who must interface with external hardware in
which the communication interface specifies ASCII character set
messages. For us, creating char[] messages and filling specific
fields with char strings is quite essential. I was enormously taken
aback by switching to the latest Visual Studio and finding all my
strings defaulting to Unicode. So far my applications do not need
internationalization and I am working hard to separate strings used
for user interface from strings used for device communications, though
they are closely inter-related. Still, legacy code including pieces
dating back to DOS days, makes for hard work which is hard to get
somebody to pay for since it does not produce visible enhancements to
performance or add features.
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.



Relevant Pages

  • Re: Sets and portability (was) Re: Is ISO Pascal compatible with J&W (original) Pascal ?
    ... strings, the user can control the length by the data they process; ... >> The computer world is more complex than it's ever been (eg Unicode) ... The Pascal `Char' type can be this size (unlike C, ... > Note that ansi->wide conversion is codepage sensitive. ...
    (comp.lang.pascal.misc)
  • Re: Unicode strings vs. traditional C strings
    ... Compiler does what you'd expect it to. ... internally with a char *, ... It's really only the Win32 API that is primarily UNICODE. ... T or F - A function such as strchrfor ANSI strings does not exist but I ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: How to LPCTSTR Convert to char *
    ... I would just change it to an ANSI project by turning ... Unicode characters that have no 8-bit equivalents. ... which the communication interface specifies ASCII character set ... fields with char strings is quite essential. ...
    (microsoft.public.vc.mfc)
  • Re: Unable to see Russian Strings in .RC file.
    ... > UNICODE i am not able to see the Russian strings and instead seeing ... I then created a sample MFC app and included _UNICODE ... > atoito wtoietc i.e. use the wide char methods instead of ANSII ...
    (microsoft.public.vc.mfc)
  • Re: problems with passing arguments to an interface
    ... It is a very bad idea to use TCHAR in a COM interface. ... will change depending on whether you compile with or without Unicode, ... method on a component compiled as Unicode, ... use CHAR or WCHAR. ...
    (microsoft.public.vc.atl)