How to LPCTSTR Convert to char *
in [MFC]
|
Prev: why is CoUninitialize being called in CDHtmlDialog::Navigate
Next: A little help with a LNK2019 error?
From: Ajay Kalra on 6 Dec 2006 16:24 > But I am also trying to be "forward > looking" and "modern", not to mention anticipating having to deal with > the need to interface with Unicode systems soon, now. Well then... welcome to UNICODE. You have to pay the piper for being "modern". --- Ajay
From: Tom Serface on 6 Dec 2006 16:52 I'm actually making all new programs Unicode. It's not really that much difference once you get into it (at least it hasn't been for us). You do have to remember that a "char" is now more than one byte so things like strlen() won't work as they did before. This article might help you some: http://msdn2.microsoft.com/en-us/library/805c56f8(VS.80).aspx http://www.i18nguy.com/unicode/c-unicode.html Tom "r norman" <r_s_norman@_comcast.net> wrote in message news:7scen2pci9tfqp28vja72s7ee003umofnd(a)4ax.com... > On Wed, 6 Dec 2006 13:14:18 -0800, "Tom Serface" <tserface(a)msn.com> > wrote: > >>I agree with Ajay... I would just change it to an ANSI project by turning >>Unicode off in the Project Properties. That will be the easiest solution >>since you have no internationalization needs. >> > > That is actually what I do. But I am also trying to be "forward > looking" and "modern", not to mention anticipating having to deal with > the need to interface with Unicode systems soon, now. > >
From: Joseph M. Newcomer on 6 Dec 2006 16:52 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@_comcast.net> wrote: >On Wed, 06 Dec 2006 13:12:20 -0500, Joseph M. Newcomer ><newcomer(a)flounder.com> 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(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: r norman on 6 Dec 2006 17:14 On Wed, 6 Dec 2006 13:52:19 -0800, "Tom Serface" <tserface(a)msn.com> wrote: >I'm actually making all new programs Unicode. It's not really that much >difference once you get into it (at least it hasn't been for us). You do >have to remember that a "char" is now more than one byte so things like >strlen() won't work as they did before. This article might help you some: > >http://msdn2.microsoft.com/en-us/library/805c56f8(VS.80).aspx >http://www.i18nguy.com/unicode/c-unicode.html > I have no problem with all Unicode. That is fairly easy by avoiding all "old-fashioned" strxxx" functions and using CString. It is my having to deal with protocols specifying ASCII chars that is the issue. One approach I am seriously considering is to put all hardware interface code with those needs into independent processes and write all user interface as a separate process purely in Unicode. That would also simplify the modifications as the hardware vendors modify their systems and change their protocols. I do have a pretty good separation of modules within my code but separate processes would help greatly. Then all the Unicode-ASCII conversions would occur at one point: the interprocess communication system.
From: Joseph M. Newcomer on 6 Dec 2006 16:56
One of the things I learned is that "no internationalization" is a transient state, subject to change without notice. The hardest problem we had to deal with was a Win16 app that had to be completely rewritten, but the international sales paid for it in the first year. Otherwise, it has been the case that, out of the blue, a client calls and says "We need Unicode support, what's it going to cost?" They are ecstatic when the answer involves making a new configuration and setting UNICODE/_UNICODE. (Alas, then they learn that localization is more than just Unicode, but I've now learned to be a lot more localization-aware) joe On Wed, 6 Dec 2006 13:14:18 -0800, "Tom Serface" <tserface(a)msn.com> wrote: >I agree with Ajay... I would just change it to an ANSI project by turning >Unicode off in the Project Properties. That will be the easiest solution >since you have no internationalization needs. > >Tom > >"r norman" <r_s_norman@_comcast.net> wrote in message >news:4e4en21dq26inbns39jaeq5ngk7ekvborc(a)4ax.com... >> On Wed, 06 Dec 2006 13:12:20 -0500, Joseph M. Newcomer >> <newcomer(a)flounder.com> 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(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |