Unicode compile question
in [MFC]
|
Prev: StringCchCopy question
Next: Finding Memory Leaks
From: RB on 26 Apr 2010 10:39 Thanks for the link I am going there now.
From: RB on 26 Apr 2010 10:38 > For VS6, _MBCS is defined with the rest of the preprocessor symbols in the Project Settings, C/C++ tab, Category: General, > "Preprocessor definitions". Ok so I don't have to delete them ? I thought they had something to do with oriental characters and was confused as to why they were set at default. But I probably missed something on that browsing read.
From: David Ching on 26 Apr 2010 10:55 "RB" <NoMail(a)NoSpam> wrote in message news:eK3Tr4U5KHA.3184(a)TK2MSFTNGP05.phx.gbl... >> For VS6, _MBCS is defined with the rest of the preprocessor symbols in >> the Project Settings, C/C++ tab, Category: General, "Preprocessor >> definitions". > > Ok so I don't have to delete them ? I thought they had something to do > with oriental > characters and was confused as to why they were set at default. But I > probably missed > something on that browsing read. > > The processor predefinitions should only have either a) _MBCS or b) _UNICODE and UNICODE Both a) and b) will properly handle oriental characters (that use more than one byte per character), but b) is easier because you don't have to diddle with something called "code page" in order to make sure the character appears properly. If neither a) or b) are defined, it used to default to single byte character set (only one byte per character like ASCII or ANSI), but I don't think programs are normally built with this anymore. -- David
From: Joseph M. Newcomer on 26 Apr 2010 17:06 I'd suggest deleting the _MBCS option for a Unicode build. At least I always have. joe On Mon, 26 Apr 2010 10:37:26 -0400, "RB" <NoMail(a)NoSpam> wrote: >>For purposes of testing, you really should create a new configuration, so you >>have Debug, Release, Unicode Debug and Unicode Release as options. >>This will let you test out your code easily under a number of scenarios. > >Thanks, that is a good idea. > >> _MBCS is defined in VS6 and < VS2005 by default because that is what they are >> defined to do. No deeper reason. > >Ok so I don't have to delete them ? I thought they had something to do with oriental >characters and was confused as to why they were set at default. But I probably missed >something on that browsing read. > >> Note that the need to specify wWinMainCRTStartup is sort of an ugly hack; in a real >> system, this would have been properly handled without it being "in your face" as it is in >> VS. There is *always* such a startup routine; it is just that by default you never see it >> in a normal build. There is always "further initialization" in any application; > >Thanks again > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Tom Serface on 26 Apr 2010 20:36
I think that the UNICODE and _UNICODE settings will supersede the _MBCS define, but it's safe to delete it in that configuration of the project build. Unless you don't care about MBCS any more, then the multiple project build idea is a waste of time. I only use the multiple build these days for libraries that other people may use. Tom "RB" <NoMail(a)NoSpam> wrote in message news:eXQI$3U5KHA.1932(a)TK2MSFTNGP05.phx.gbl... >>For purposes of testing, you really should create a new configuration, so >>you >>have Debug, Release, Unicode Debug and Unicode Release as options. >>This will let you test out your code easily under a number of scenarios. > > Thanks, that is a good idea. > >> _MBCS is defined in VS6 and < VS2005 by default because that is what they >> are >> defined to do. No deeper reason. > > Ok so I don't have to delete them ? I thought they had something to do > with oriental > characters and was confused as to why they were set at default. But I > probably missed > something on that browsing read. > >> Note that the need to specify wWinMainCRTStartup is sort of an ugly hack; >> in a real >> system, this would have been properly handled without it being "in your >> face" as it is in >> VS. There is *always* such a startup routine; it is just that by default >> you never see it >> in a normal build. There is always "further initialization" in any >> application; > > Thanks again > |