[webkit-dev] "using" statement clarifications

Darin Adler darin at apple.com
Mon Dec 7 09:30:32 PST 2009


Sorry, I wasn’t able to follow all the logic in the style guideline and the email message nor fully understand what the script enforces. So I’ll give my view on this and hope it helps.

- The rule against "using namespace xxx" in headers in namespace scope exists because of the notion that someone might be building software that depends on a header without being able to modify the header. Combining the namespace may create name conflicts that are not fixable.

The assumption that clients are using a header and can’t modify it may not in fact be true for headers inside WebKit. Most are designed for use only within WebKit and so in theory that guideline could be limited only to headers intended for use outside WebKit. On the other hand, I have the impression that on some platforms such as Qt it is common for clients to directly use internal headers, such as the ones in WebCore.

I can’t think of a concrete example where a "using xxx::yyy" would be a problem inside a class or function scope in a header, so it seems fine to permit those. I suppose there’s a chance that "using namespace xxx" could still cause a problem even inside a function, but again it’s hard for me to think of a real example.

- Inside non-header files, there is the guideline of preferring "using namespace std" to "using std::min". This suggestion comes from me.

It does not seem worthwhile to maintain a list of "using" statements at the top of the file mentioning each imported identifier. In theory we could avoid some rare conflicts this way, but in practice it just seems like a lot of unhelpful bookkeeping.

At first, I did the "using std::min" thing, but now I prefer "using namespace std" inside implementation files, and I suggest we retain that guideline.

I also don’t see a need for "using" statements of either kind further down in the file. It seems they can go at the top, right after the includes. But maybe I’ve missed some useful case.

    -- Darin



More information about the webkit-dev mailing list