The proposal was to search-n-replace std::wstring to string16. We would have to invent a macro to replace L"" usage. Most usages of string literals are in unit tests, so it doesn't seem to matter if there is cost associated with the macro. My belief is that there isn't much fruit to be had by converting everything to UTF-8. I fear people passing non-UTF-8 strings around using std::string and the bugs that ensue from that. We've had those problems in areas that deal with UTF-8 and non-UTF-8 byte arrays.
Whenever we have a string16 or a wstring, it means implicitly that we have unicode that can be displayed to the user. So, the compiler helps us not screw up. If someone can make a compelling performance argument for changing Chrome's UI over to UTF-8 and also invent a solution that avoids the problem I described above, then converting to UTF-8 would seem OK to me. But, right now... it just looks like cost for not much benefit. -Darin On Wed, Feb 4, 2009 at 8:21 AM, Evan Martin <[email protected]> wrote: > > On Wed, Feb 4, 2009 at 6:53 AM, Dean McNamee <[email protected]> wrote: > > I apologize for missing this discussion, I'm sure that I'm not seeing > > the entire picture and the pros of this argument. I mentioned before > > that I'm in support of utf-8 everywhere we can get it. > > I lost this argument, so I will defer this response to someone else. :) > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
