Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update C++ style guide. #699

Merged
merged 1 commit into from
Jul 6, 2022
Merged

Update C++ style guide. #699

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 24 additions & 15 deletions cppguide.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1706,7 +1706,7 @@ <h3 id="Declaration_Order">Declaration Order</h3>

<ol>
<li>Types and type aliases (<code>typedef</code>, <code>using</code>,
<code>enum</code>, nested structs and classes)</li>
<code>enum</code>, nested structs and classes, and <code>friend</code> types)</li>

<li>Static constants</li>

Expand Down Expand Up @@ -2896,6 +2896,17 @@ <h3 id="Integer_Types">Integer Types</h3>

<p class="decision"></p>

<p>
The standard library header <code>&lt;cstdint&gt;</code> defines types
like <code>int16_t</code>, <code>uint32_t</code>,
<code>int64_t</code>, etc. You should always use
those in preference to <code>short</code>, <code>unsigned
long long</code> and the like, when you need a guarantee
on the size of an integer. Of the C integer types, only
<code>int</code> should be used. When appropriate, you
are welcome to use standard types like
<code>size_t</code> and <code>ptrdiff_t</code>.</p>

<p>We use <code>int</code> very often, for integers we
know are not going to be too big, e.g., loop counters.
Use plain old <code>int</code> for such things. You
Expand Down Expand Up @@ -4459,23 +4470,20 @@ <h4>Function Declarations</h4>
are provided in `backticks`, then code-indexing
tools may be able to present the documentation better.</li>

<li>For class member functions: whether the object
remembers reference arguments beyond the duration of
the method call, and whether it will free them or
not.</li>
<li>For class member functions: whether the object remembers
reference or pointer arguments beyond the duration of the method
call. This is quite common for pointer/reference arguments to
constructors.</li>

<li>If the function allocates memory that the caller
must free.</li>
<li>For each pointer argument, whether it is allowed to be null and what happens
if it is.</li>

<li>Whether any of the arguments can be a null
pointer.</li>
<li>For each output or input/output argument, what happens to any state that argument
is in. (E.g. is the state appended to or overwritten?).

<li>If there are any performance implications of how a
</li><li>If there are any performance implications of how a
function is used.</li>

<li>If the function is re-entrant. What are its
synchronization assumptions?</li>
</ul>
</ul>

<p>Here is an example:</p>

Expand Down Expand Up @@ -4946,7 +4954,8 @@ <h3 id="Function_Declarations_and_Definitions">Function Declarations and Definit
<p>Attributes, and macros that expand to attributes, appear at the very
beginning of the function declaration or definition, before the
return type:</p>
<pre>ABSL_MUST_USE_RESULT bool IsOk();
<pre> ABSL_ATTRIBUTE_NOINLINE void ExpensiveFunction();
[[nodiscard]] bool IsOk();
</pre>

<h3 id="Formatting_Lambda_Expressions">Lambda Expressions</h3>
Expand Down