|
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