I've been doing some of the wstring -> string conversions Peter mentioned. I changed Value to use UTF-8 strings, and as a result all classes that depend on it are in the process of being updated. See: http://groups.google.com/group/chromium-dev/browse_thread/thread/53b7fef96ca24212 For the most part I've tackled self-contained changes, and in some cases found classes were already using UTF-8 strings but calling UTF8ToWide() in order to use Value. JSONReader/Writer and the preferences manager are two pieces using wide strings with Value I haven't converted yet. I expect the refactors to push WideToUTF8 calls further and further away from calls to the Value class, hopefully until they're gone.
On Thu, Jan 15, 2009 at 1:03 PM, Peter Kasting <[email protected]> wrote: > On Thu, Jan 15, 2009 at 10:55 AM, Dean McNamee <[email protected]> wrote: > >> I think a good example is chrome_constants.cc, I don't see why any of >> these should have to be wide. Some of them may make their way into >> filenames, etc, in which case they could be easily converted or be >> handled directly by FilePath methods, etc. >> >> Another good example would be chrome_switches, these will always be ASCII. > > > In principle I agree that things that will always be ASCII should just be > stored as strings, not wstrings. The caveat is that if they can be supplied > as arguments to functions which also take wide strings from elsewhere, they > introduce conversions somewhere, which usually doesn't matter from an > efficiency perspective, but makes code uglier and makes it trickier to know > what representation a given API really ought to use. > > String representations spread in the same way const does, so the > consistency argument is a pretty strong argument IMO, even though I > completely agree with you that it can waste memory. OTOH, last time we > discussed this we figured most string usage was in the renderer, and the > savings in the browser would be fairly minimal. For example, changing those > constants and switches you mention above barely saves anything, > > So far I just mentioned constants, but I think this also applies to a >> lot of other parts to our code, and it makes sense to shift to UTF8 in >> a lot of our internal representations. > > > I think in speed-critical bits we're currently trying to use whatever > results in the fewest conversions, which makes some sense to me. (Like, I > thought some stuff came out of the renderer as UTF-16.) > > >> Just wanted to solicit thoughts, and make sure there is some sort of >> agreement and support if we start trying to UTF8 some pieces of >> Chrome. > > > I'm not opposed so much as not-terribly-convinced we'll get wins out of it. > If we do, the change seems worth it. > > My biggest concern after memory usage (where a significant savings would > make me strongly support this) is code readability. Using different string > types and conversions in the Gecko codebase almost made me kill myself. > We're not nearly so bad, but some of the recent changes I've reviewed to > convert some wstrings to strings and insert UTF8ToWide() calls have made > code harder to read and suggested that larger refactorings of APIs and > members (which lead to even more refactorings, chain-reaction-style) would > be better. > > Also, when this has come up before, I've heard the argument that this >> means strings are no longer directly indexable (ie blah[3] gets you >> the 4th character). Well, this isn't true for wchar_t on Windows >> either. Since it is UTF16, it can have surrogate pairs (Unicode is >> current defined for something like 20-21 bits?). > > > I thought our wstrings were frequently UCS-2 instead of UTF-16, so this > property _does_ hold? > > Your point is well-taken, though, and I agree with everything you say > afterwards. > > PK > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
