StarMirror/CppCoreGuidelines
1
0
Fork 0
mirror of https://github.com/isocpp/CppCoreGuidelines.git synced 2024-03-22 13:30:58 +08:00
Code Issues Projects Releases Wiki Activity

Merge pull request #172 from miyuki-chan/master

Browse Source 
Indent some code examples for correct rendering
This commit is contained in:
Gabriel Dos Reis 2015-09-27 09:29:45 -07:00
commit 4332e0790a
1 changed files with 12 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
CppCoreGuidelines.md
View File

@ -12235,7 +12235,7 @@ This class is a resource handle. It manages the lifetime of the `T`s. To do so,
If `i==0` the file handle for `a file` is leaked. On the other hand, the `ifstream` for `another file` will correctly close its file (upon destruction). If you must use an explicit pointer, rather than a resource handle with specific semantics, use a `unique_ptr` or a `shared_ptr`: If `i==0` the file handle for `a file` is leaked. On the other hand, the `ifstream` for `another file` will correctly close its file (upon destruction). If you must use an explicit pointer, rather than a resource handle with specific semantics, use a `unique_ptr` or a `shared_ptr`:
void f(int i) void f(int i)
{ {
unique_ptr<FILE> f = fopen("a file","r"); unique_ptr<FILE> f = fopen("a file","r");
// ... // ...
@ -12377,19 +12377,19 @@ Aternatively, we will decide that no change is needed and delete the entry.
* What to do with leaks out of temporaries? : `p = (s1+s2).c_str();` * What to do with leaks out of temporaries? : `p = (s1+s2).c_str();`
* pointer/iterator invalidation leading to dangling pointers * pointer/iterator invalidation leading to dangling pointers
void bad() void bad()
{ {
int* p = new int[700]; int* p = new int[700];
int* q = &p[7]; int* q = &p[7];
delete p; delete p;
vector<int> v(700); vector<int> v(700);
int* q2 = &v[7]; int* q2 = &v[7];
v.resize(900); v.resize(900);
// ... use q and q2 ...
}
// ... use q and q2 ...
}
* LSP * LSP
* private inheritance vs/and membership * private inheritance vs/and membership
* avoid static class members variables (race conditions, almost-global variables) * avoid static class members variables (race conditions, almost-global variables)