Re: Converting MBCS project to UNICODE compliant.. Pros and Cons
- From: "Tom Serface" <tom@xxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 3 Feb 2009 21:16:58 -0800
"sachin" <sachin@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:6BAF6EEB-E4D6-475E-A25C-50C5E212BD55@xxxxxxxxxxxxxxxx
hi Tom
cn you please elaborate your point about
I've never dug this deep, but I've been told that much of the OS relies on Unicode strings so when passing strings to a control, or whatever, they are converted to Unicode somewhere along the line. If that is true that conversion would not have to be done. I also know the strings in the newer string tables are Unicode.
but there are some conversions for SDK functions thatdon't have to happen
HI All >
using TCHAR or _T will only help to save code modification time when you
switch back to ASCII. in my case i will never go back to ASCII version as
internationalization is basic requirement . My concern was should switch all
my data structure into wstring or WCHAR ? or should i do it selectively
only for needed business object classes .
I would just use CString whever possible and let it do the work for you unless you have a specific need for wchar_t buffers. From you example, using the STL functions you may be better off with wstring if you don't need any of the "stuff" CString does for you.
For example :
I have STD::map<int, string> where string is a hash Code of some files now
we do not need to keep this map in unicode version std::map<int, wstring>
because hash value will always be within 0 - F ( ASCII )
this table to huge in size ( say for all the files which i am crawling from
desktop machine )
Should i keep this in ASCII form or converting it to Unicode string wont eat
much memory ?
Just my opinion, but there are two ways to look at it. I don't know what 'huge' means exactly. I have lists in my program that hold hundreds of thousands of entries and I didn't see any performance difference going to Unicode. However, you are right that the memory used is doubled and if that ever causes any sort of paging of memory to occur that would make a big difference. On the other hand, if the strings are already ASCII and it works and there is no reason to convert it (comparisons or whatever) then I'd likely leave that part alone. You can always convert from ANSI to Unicode as needed at run time.
If the filenames you're retrieving are already in Unicode there may be some performance difference in converting them to ANSI to store them in your map.
Tom
.
- References:
- Prev by Date: Re: Converting MBCS project to UNICODE compliant.. Pros and Cons
- Next by Date: what is "Not enough quota is available to process this command" ?
- Previous by thread: Re: Converting MBCS project to UNICODE compliant.. Pros and Cons
- Next by thread: Re: Converting MBCS project to UNICODE compliant.. Pros and Cons
- Index(es):
Relevant Pages
|
