Make unit_tests pass with pt_BR.UTF-8 locale.

Make unit_tests pass with pt_BR.UTF-8 locale.

BUG=3675
Patch from Paweł Hajdan jr <phajdan.jr@gmail.com>;
original issue: http://codereview.chromium.org/9509

[tony, 2008-11-12 02:06:53]

Hi Mark and Amanda,

This is a patch from Paweł that add's David M Gay's dtoa code as a third party
library and adds methods to string_util to use it.  I have it working on Windows
and Linux, but will need a new xcode project for this to work on mac.  Would one
of you be so kind as to create the xcode project for me?  I can do the actual
commit and watch the tree for breakage, I just don't know how to do the xcode
stuff.

[please use my chromium address, 2008-11-12 10:16:17]

I saw two minor issue after removing "= true" and "= false" from enum
LocaleDependence definition. Please check.

http://codereview.chromium.org/11002/diff/201/52
File base/string_util.cc (right):

http://codereview.chromium.org/11002/diff/201/52#newcode1014
Line 1014: if (locale_dependent) {
I would suggest making this an explicit check (locale_dependent ==
LOCALE_DEPENDENT). "= true" and "= false" have been removed from definition of
LocaleDependence.

http://codereview.chromium.org/11002/diff/201/53
File base/string_util.h (right):

http://codereview.chromium.org/11002/diff/201/53#newcode130
Line 130: // When some function takes an optional parameter to control locale
This comment may no longer be as relevant as it was before. Please review it.

- in some functions this parameter is required (so maybe "takes a parameter")
- but as they are not booleans now, the enum values probably have to be used
anyway, so this comment wouldn't make sense

[tony, 2008-11-12 18:17:30]

I fixed these and added the functions and enums to the base namespace.

I'm looking into the mac changes now...

On 2008/11/12 10:16:17, phajdan.jr wrote:
> I saw two minor issue after removing "= true" and "= false" from enum
> LocaleDependence definition. Please check.
> 
> http://codereview.chromium.org/11002/diff/201/52
> File base/string_util.cc (right):
> 
> http://codereview.chromium.org/11002/diff/201/52#newcode1014
> Line 1014: if (locale_dependent) {
> I would suggest making this an explicit check (locale_dependent ==
> LOCALE_DEPENDENT). "= true" and "= false" have been removed from definition of
> LocaleDependence.
> 
> http://codereview.chromium.org/11002/diff/201/53
> File base/string_util.h (right):
> 
> http://codereview.chromium.org/11002/diff/201/53#newcode130
> Line 130: // When some function takes an optional parameter to control locale
> This comment may no longer be as relevant as it was before. Please review it.
> 
> - in some functions this parameter is required (so maybe "takes a parameter")
> - but as they are not booleans now, the enum values probably have to be used
> anyway, so this comment wouldn't make sense

[tony, 2008-11-12 20:08:44]

Now with mac build updates.  I'll send it to the try bots and commit if ok.

On 2008/11/12 18:17:30, tony wrote:
> I fixed these and added the functions and enums to the base namespace.
> 
> I'm looking into the mac changes now...
> 
> On 2008/11/12 10:16:17, phajdan.jr wrote:
> > I saw two minor issue after removing "= true" and "= false" from enum
> > LocaleDependence definition. Please check.
> > 
> > http://codereview.chromium.org/11002/diff/201/52
> > File base/string_util.cc (right):
> > 
> > http://codereview.chromium.org/11002/diff/201/52#newcode1014
> > Line 1014: if (locale_dependent) {
> > I would suggest making this an explicit check (locale_dependent ==
> > LOCALE_DEPENDENT). "= true" and "= false" have been removed from definition
of
> > LocaleDependence.
> > 
> > http://codereview.chromium.org/11002/diff/201/53
> > File base/string_util.h (right):
> > 
> > http://codereview.chromium.org/11002/diff/201/53#newcode130
> > Line 130: // When some function takes an optional parameter to control
locale
> > This comment may no longer be as relevant as it was before. Please review
it.
> > 
> > - in some functions this parameter is required (so maybe "takes a
parameter")
> > - but as they are not booleans now, the enum values probably have to be used
> > anyway, so this comment wouldn't make sense