C++ tips: remove guidance for hiding static details in implementation.
The current guidance recommends a construct that generates a global constructor / destructor, which is forbidden. Since this is similar enough to the previous section on inner classes, just remove it since a separate section shouldn't be needed. Change-Id: Ie3150e6e85bb700d17f802fbe71c244329feb660 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1524338 Commit-Queue: Daniel Cheng <dcheng@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Cr-Commit-Position: refs/heads/master@{#641003}
This commit is contained in:
@ -14,7 +14,7 @@ author/reviewer/OWNERS agree that another course is better.
|
|||||||
If a file isn't using the symbols from some header, remove the header. It turns
|
If a file isn't using the symbols from some header, remove the header. It turns
|
||||||
out that this happens frequently in the Chromium codebase due to refactoring.
|
out that this happens frequently in the Chromium codebase due to refactoring.
|
||||||
|
|
||||||
### Move inner classes into the implementation
|
### Move helper / inner classes into the implementation
|
||||||
|
|
||||||
You can also forward declare classes inside a class:
|
You can also forward declare classes inside a class:
|
||||||
|
|
||||||
@ -42,39 +42,6 @@ Note that sometimes you can't do this because certain STL data structures
|
|||||||
require the full definition at declaration time (most notably, std::deque and
|
require the full definition at declaration time (most notably, std::deque and
|
||||||
the STL adapters that wrap it).
|
the STL adapters that wrap it).
|
||||||
|
|
||||||
### Move static implementation details to the implementation whenever possible
|
|
||||||
|
|
||||||
If you have the class in a header file, you should try to move that from a class
|
|
||||||
member into the anonymous namespace in the implementation file.
|
|
||||||
|
|
||||||
DON'T:
|
|
||||||
|
|
||||||
```cpp
|
|
||||||
#include "BigImplementationDetail.h"
|
|
||||||
class PublicInterface {
|
|
||||||
public:
|
|
||||||
/* ... */
|
|
||||||
private:
|
|
||||||
static BigImplementationDetail detail_;
|
|
||||||
};
|
|
||||||
```
|
|
||||||
|
|
||||||
DO:
|
|
||||||
|
|
||||||
```cpp
|
|
||||||
namespace {
|
|
||||||
BigImplementationDetail g_detail;
|
|
||||||
} // namespace
|
|
||||||
```
|
|
||||||
|
|
||||||
That way, people who don't use your interface don't need to know about or care
|
|
||||||
about `BigImplementationDetail`.
|
|
||||||
|
|
||||||
You can do this for helper functions, too. Note that if there is more than one
|
|
||||||
class in the .cc file, it can aid clarity to define your translation-unit-scope
|
|
||||||
helpers in an anonymous namespace just above the class that uses them, instead
|
|
||||||
of at the top of the file.
|
|
||||||
|
|
||||||
## Stop inlining code in headers
|
## Stop inlining code in headers
|
||||||
|
|
||||||
*** note
|
*** note
|
||||||
@ -700,4 +667,4 @@ The common ways to represent names in comments are as follows:
|
|||||||
```cpp
|
```cpp
|
||||||
// FooImpl implements the FooBase class.
|
// FooImpl implements the FooBase class.
|
||||||
// FooFunction() modifies |foo_member_|.
|
// FooFunction() modifies |foo_member_|.
|
||||||
```
|
```
|
||||||
|
Reference in New Issue
Block a user