From 153da174176d6ffe3ff30f0e99ae646dca223f2b Mon Sep 17 00:00:00 2001 From: Kim Viggedal Date: Thu, 30 Jan 2020 20:19:22 +0100 Subject: [PATCH] Merge I.2 and R.6 seem to address the same issue, (#1553) thus I propose removing R.6 and moving some of its contents into I.2. --- CppCoreGuidelines.md | 36 ++++++++++++++---------------------- 1 file changed, 14 insertions(+), 22 deletions(-) diff --git a/CppCoreGuidelines.md b/CppCoreGuidelines.md index 82af97c..68b3786 100644 --- a/CppCoreGuidelines.md +++ b/CppCoreGuidelines.md @@ -1308,6 +1308,14 @@ Non-`const` global variables hide dependencies and make the dependencies subject Who else might modify `data`? +**Warning**: The initialization of global objects is not totally ordered. +If you use a global object initialize it with a constant. +Note that it is possible to get undefined initialization order even for `const` objects. + +##### Exception + +A global object is often better than a singleton. + ##### Note Global constants are useful. @@ -1322,6 +1330,9 @@ Another solution is to define the data as the state of some object and the opera **Warning**: Beware of data races: If one thread can access nonlocal data (or data passed by reference) while another thread executes the callee, we can have a data race. Every pointer or reference to mutable data is a potential data race. +Using global pointers or references to access and change non-const, and otherwise non-global, +data isn't a better alternative to non-const global variables since that doesn't solve the issues of hidden dependencies or potential race conditions. + ##### Note You cannot have a race condition on immutable data. @@ -1334,7 +1345,8 @@ The rule is "avoid", not "don't use." Of course there will be (rare) exceptions, ##### Enforcement -(Simple) Report all non-`const` variables declared at namespace scope. +(Simple) Report all non-`const` variables declared at namespace scope and global pointers/references to non-const data. +(??? NM: Obviously we can warn about non-`const` statics ... do we want to?) ### I.3: Avoid singletons @@ -8992,7 +9004,6 @@ Here, we ignore such cases. * [R.3: A raw pointer (a `T*`) is non-owning](#Rr-ptr) * [R.4: A raw reference (a `T&`) is non-owning](#Rr-ref) * [R.5: Prefer scoped objects, don't heap-allocate unnecessarily](#Rr-scoped) - * [R.6: Avoid non-`const` global variables](#Rr-global) * Allocation and deallocation rule summary: @@ -9284,26 +9295,7 @@ Instead, use a local variable: ### R.6: Avoid non-`const` global variables -##### Reason - -Global variables can be accessed from everywhere so they can introduce surprising dependencies between apparently unrelated objects. -They are a notable source of errors. - -**Warning**: The initialization of global objects is not totally ordered. -If you use a global object initialize it with a constant. -Note that it is possible to get undefined initialization order even for `const` objects. - -##### Exception - -A global object is often better than a singleton. - -##### Exception - -An immutable (`const`) global does not introduce the problems we try to avoid by banning global objects. - -##### Enforcement - -(??? NM: Obviously we can warn about non-`const` statics ... do we want to?) +See [I.2](#Ri-global) ## R.alloc: Allocation and deallocation