Confirmed users
497
edits
Nnethercote (talk | contribs) |
(→Namespaces: Update rules per IRC conversation.) |
||
| Line 298: | Line 298: | ||
== Namespaces == | == Namespaces == | ||
* | * Public functions and types should be in the JS:: namespace, in preference to the old JS/JS_ name prefixes. | ||
* Library-private and friend functions should be in the js:: namespace, in preference to the old js_ name prefix. | |||
* | * Compile-time-evaluated functions (i.e., template meta-functions) should be in 'js::tl::', the "template library" namespace, to avoid collision with their runtime counterparts. | ||
* In SpiderMonkey .cpp files, it is okay to have 'using namespace js;', but it is not okay to do the same with any other namespace, like JS:: or mozilla::. These can introduce ambiguities that come and go depending on which .cpp files the build system decides to unify. | |||
* Compile-time-evaluated functions (i.e., template meta-functions) | * If you do have names in JS:: that should be readily available throughout SpiderMonkey, you may add a 'using' declaration to js/src/NamespaceImports.h. | ||
* Avoid unnamed namespaces unless they are necessary to give a class's members internal linkage. Although the C++ standard officially deprecates 'static' on functions, 'static' has the following advantages over unnamed namespaces: | |||
* Avoid unnamed namespaces unless they are necessary to give a class's members internal linkage. Although the C++ standard officially deprecates 'static' on functions, 'static' has the following advantages: | |||
** It is difficult to name functions in unnamed namespaces in gdb. | ** It is difficult to name functions in unnamed namespaces in gdb. | ||
** Static says "this is a translation-unit-local helper function" on the function, without having to look around for an enclosing "namespace {". | ** Static says "this is a translation-unit-local helper function" on the function, without having to look around for an enclosing "namespace {". | ||
== Enums == | == Enums == | ||