On Thu, Jan 7, 2010 at 3:45 PM, Aaron Boodman <a...@google.com> wrote:
> Out of curiosity, what is wrong with using EmptyString() in those
> cases? Is there a correctness problem? Unnecessary inclusion of
> string_util.h?
There are a couple reasons. Code clarity and consistency is a primary one;
using EmptyString() implies you _need_ EmptyString() and that the default
constructor won't work, which can be confusing. (I am especially frustrated
with code like "std::string x(EmptyString());".) For folks used to using
WebKit string classes, which differentiate between empty and NULL, this can
look like you're saying more about the semantics of the statement than you
actually are. If you see code with hundreds of EmptyString()s you begin
wondering whether your code should use it too.
Another reason is that EmptyString() does a threadsafe access to a global
object, whereas the default constructor is a comparatively simple block of
inlinable code that the compiler understands and may frequently be able to
optimize better.
There is not a correctness issue, which is why uses of this can seep into
the codebase without people noticing. It is, of course, nice to avoid
including string_util.h as you mention, though I'd consider that a minor
benefit.
The totality of the reasons is somewhat lost (to me at least) in the mists
of time; EmptyString() dates from the earliest days of the codebase, and at
the time we went round and round a number of times to determine the best
solutions for each situation.
PK
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
