|
790 | 790 | appearing in the type of \tcode{D} can result
|
791 | 791 | in the different declarations having distinct types, and
|
792 | 792 | \grammarterm{lambda-expression}{s} appearing in a default argument of \tcode{D}
|
793 |
| -might still denote different types in different translation units. |
| 793 | +can still denote different types in different translation units. |
794 | 794 | \end{note}
|
795 | 795 |
|
796 | 796 | \pnum
|
|
1512 | 1512 | any declaration in the same translation unit
|
1513 | 1513 | whose locus\iref{basic.scope.pdecl} is before $P$.
|
1514 | 1514 | \begin{note}
|
1515 |
| -The declaration might appear in a scope that does not contain $P$. |
| 1515 | +The declaration can appear in a scope that does not contain $P$. |
1516 | 1516 | \end{note}
|
1517 | 1517 | \indextext{precede|see{declaration, precede}}%
|
1518 | 1518 | A declaration $X$ \defnx{precedes}{declaration!precede}
|
|
1795 | 1795 | \pnum
|
1796 | 1796 | \begin{note}
|
1797 | 1797 | Even if the result of name lookup is unambiguous, use of a name found in
|
1798 |
| -multiple subobjects might still be |
| 1798 | +multiple subobjects can still be |
1799 | 1799 | ambiguous\iref{conv.mem,expr.ref,class.access.base}.
|
1800 | 1800 | \end{note}
|
1801 | 1801 | \begin{example}
|
|
3111 | 3111 | or a maximal sequence of adjacent bit-fields all having nonzero width.
|
3112 | 3112 | \begin{note}
|
3113 | 3113 | Various
|
3114 |
| -features of the language, such as references and virtual functions, might |
| 3114 | +features of the language, such as references and virtual functions, can |
3115 | 3115 | involve additional memory locations that are not accessible to programs but are
|
3116 | 3116 | managed by the implementation.
|
3117 | 3117 | \end{note}
|
|
4270 | 4270 | When \tcode{D} is the type of a complete object, it will have a subobject of
|
4271 | 4271 | type \tcode{B}, so it must be aligned appropriately for a \tcode{\keyword{long} \keyword{double}}.
|
4272 | 4272 | If \tcode{D} appears as a subobject of another object that also has \tcode{B}
|
4273 |
| -as a virtual base class, the \tcode{B} subobject might be part of a different |
| 4273 | +as a virtual base class, the \tcode{B} subobject can be part of a different |
4274 | 4274 | subobject, reducing the alignment requirements on the \tcode{D} subobject.
|
4275 | 4275 | \end{example}
|
4276 | 4276 | The result of the \keyword{alignof} operator reflects the alignment
|
|
4583 | 4583 |
|
4584 | 4584 | \item A temporary bound to a reference in a \grammarterm{new-initializer}\iref{expr.new} persists until the completion of the full-expression containing the \grammarterm{new-initializer}.
|
4585 | 4585 | \begin{note}
|
4586 |
| -This might introduce a dangling reference. |
| 4586 | +This can introduce a dangling reference. |
4587 | 4587 | \end{note}
|
4588 | 4588 | \begin{example}
|
4589 | 4589 | \begin{codeblock}
|
|
4752 | 4752 | constexpr std::size_t N = sizeof(T);
|
4753 | 4753 | char buf[N];
|
4754 | 4754 | T obj; // \tcode{obj} initialized to its original value
|
4755 |
| -std::memcpy(buf, &obj, N); // between these two calls to \tcode{std::memcpy}, \tcode{obj} might be modified |
| 4755 | +std::memcpy(buf, &obj, N); // between these two calls to \tcode{std::memcpy}, \tcode{obj} can be modified |
4756 | 4756 | std::memcpy(&obj, buf, N); // at this point, each subobject of \tcode{obj} of scalar type holds its original value
|
4757 | 4757 | \end{codeblock}
|
4758 | 4758 | \end{example}
|
|
4953 | 4953 | \end{itemize}
|
4954 | 4954 | \begin{note}
|
4955 | 4955 | A literal type is one for which
|
4956 |
| -it might be possible to create an object |
| 4956 | +it is possible to create an object |
4957 | 4957 | within a constant expression.
|
4958 | 4958 | It is not a guarantee that it is possible to create such an object,
|
4959 | 4959 | nor is it a guarantee that any object of that type
|
|
5508 | 5508 | an invocation of a deallocation function\iref{basic.stc.dynamic.deallocation},
|
5509 | 5509 | and \impldef{invalid pointer value in the context of an evaluation} otherwise.
|
5510 | 5510 | \begin{footnote}
|
5511 |
| -Some implementations might define that |
| 5511 | +Some implementations can define that |
5512 | 5512 | copying such a pointer value causes a system-generated runtime fault.
|
5513 | 5513 | \end{footnote}
|
5514 | 5514 | \begin{note}
|
|
6133 | 6133 | initial value of the object, a value assigned to the object by $T$, or a
|
6134 | 6134 | value assigned to the object by another thread, according to the rules below.
|
6135 | 6135 | \begin{note}
|
6136 |
| -In some cases, there might instead be undefined behavior. Much of this |
| 6136 | +In some cases, there can instead be undefined behavior. Much of this |
6137 | 6137 | subclause is motivated by the desire to support atomic operations with explicit
|
6138 | 6138 | and detailed visibility constraints. However, it also implicitly supports a
|
6139 | 6139 | simpler view for more restricted programs.
|
|
6500 | 6500 | \begin{note}
|
6501 | 6501 | Compiler transformations that introduce assignments to a potentially
|
6502 | 6502 | shared memory location that would not be modified by the abstract machine are
|
6503 |
| -generally precluded by this document, since such an assignment might overwrite |
| 6503 | +generally precluded by this document, since such an assignment can overwrite |
6504 | 6504 | another assignment by a different thread in cases in which an abstract machine
|
6505 | 6505 | execution would not have encountered a data race. This includes implementations
|
6506 | 6506 | of data member assignment that overwrite adjacent members in separate memory
|
6507 | 6507 | locations. Reordering of atomic loads in cases in which the atomics in question
|
6508 |
| -might alias is also generally precluded, since this could violate the coherence |
| 6508 | +can alias is also generally precluded, since this could violate the coherence |
6509 | 6509 | rules.
|
6510 | 6510 | \end{note}
|
6511 | 6511 |
|
6512 | 6512 | \pnum
|
6513 | 6513 | \begin{note}
|
6514 | 6514 | Transformations that introduce a speculative read of a potentially
|
6515 |
| -shared memory location might not preserve the semantics of the \Cpp{} program as |
| 6515 | +shared memory location can not preserve the semantics of the \Cpp{} program as |
6516 | 6516 | defined in this document, since they potentially introduce a data race. However,
|
6517 | 6517 | they are typically valid in the context of an optimizing compiler that targets a
|
6518 | 6518 | specific machine with well-defined semantics for data races. They would be
|
|
6553 | 6553 | a lock-free execution in that thread shall complete.
|
6554 | 6554 | \begin{note}
|
6555 | 6555 | Concurrently executing threads
|
6556 |
| - might prevent progress of a lock-free execution. |
| 6556 | + can prevent progress of a lock-free execution. |
6557 | 6557 | For example,
|
6558 | 6558 | this situation can occur
|
6559 | 6559 | with load-locked store-conditional implementations.
|
|
6673 | 6673 | guarantees, which in turn are stronger than weakly parallel forward progress
|
6674 | 6674 | guarantees.
|
6675 | 6675 | \begin{note}
|
6676 |
| -For example, some kinds of synchronization between threads of execution might only |
| 6676 | +For example, some kinds of synchronization between threads of execution can only |
6677 | 6677 | make progress if the respective threads of execution provide parallel forward progress
|
6678 | 6678 | guarantees, but will fail to make progress under weakly parallel guarantees.
|
6679 | 6679 | \end{note}
|
|
0 commit comments