|
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}
|
|
3116 | 3116 | or a maximal sequence of adjacent bit-fields all having nonzero width.
|
3117 | 3117 | \begin{note}
|
3118 | 3118 | Various
|
3119 |
| -features of the language, such as references and virtual functions, might |
| 3119 | +features of the language, such as references and virtual functions, can |
3120 | 3120 | involve additional memory locations that are not accessible to programs but are
|
3121 | 3121 | managed by the implementation.
|
3122 | 3122 | \end{note}
|
|
4277 | 4277 | When \tcode{D} is the type of a complete object, it will have a subobject of
|
4278 | 4278 | type \tcode{B}, so it must be aligned appropriately for a \tcode{\keyword{long} \keyword{double}}.
|
4279 | 4279 | If \tcode{D} appears as a subobject of another object that also has \tcode{B}
|
4280 |
| -as a virtual base class, the \tcode{B} subobject might be part of a different |
| 4280 | +as a virtual base class, the \tcode{B} subobject can be part of a different |
4281 | 4281 | subobject, reducing the alignment requirements on the \tcode{D} subobject.
|
4282 | 4282 | \end{example}
|
4283 | 4283 | The result of the \keyword{alignof} operator reflects the alignment
|
|
4590 | 4590 |
|
4591 | 4591 | \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}.
|
4592 | 4592 | \begin{note}
|
4593 |
| -This might introduce a dangling reference. |
| 4593 | +This can introduce a dangling reference. |
4594 | 4594 | \end{note}
|
4595 | 4595 | \begin{example}
|
4596 | 4596 | \begin{codeblock}
|
|
4759 | 4759 | constexpr std::size_t N = sizeof(T);
|
4760 | 4760 | char buf[N];
|
4761 | 4761 | T obj; // \tcode{obj} initialized to its original value
|
4762 |
| -std::memcpy(buf, &obj, N); // between these two calls to \tcode{std::memcpy}, \tcode{obj} might be modified |
| 4762 | +std::memcpy(buf, &obj, N); // between these two calls to \tcode{std::memcpy}, \tcode{obj} can be modified |
4763 | 4763 | std::memcpy(&obj, buf, N); // at this point, each subobject of \tcode{obj} of scalar type holds its original value
|
4764 | 4764 | \end{codeblock}
|
4765 | 4765 | \end{example}
|
|
4960 | 4960 | \end{itemize}
|
4961 | 4961 | \begin{note}
|
4962 | 4962 | A literal type is one for which
|
4963 |
| -it might be possible to create an object |
| 4963 | +it is possible to create an object |
4964 | 4964 | within a constant expression.
|
4965 | 4965 | It is not a guarantee that it is possible to create such an object,
|
4966 | 4966 | nor is it a guarantee that any object of that type
|
|
5515 | 5515 | an invocation of a deallocation function\iref{basic.stc.dynamic.deallocation},
|
5516 | 5516 | and \impldef{invalid pointer value in the context of an evaluation} otherwise.
|
5517 | 5517 | \begin{footnote}
|
5518 |
| -Some implementations might define that |
| 5518 | +Some implementations can define that |
5519 | 5519 | copying such a pointer value causes a system-generated runtime fault.
|
5520 | 5520 | \end{footnote}
|
5521 | 5521 | \begin{note}
|
|
6140 | 6140 | initial value of the object, a value assigned to the object by $T$, or a
|
6141 | 6141 | value assigned to the object by another thread, according to the rules below.
|
6142 | 6142 | \begin{note}
|
6143 |
| -In some cases, there might instead be undefined behavior. Much of this |
| 6143 | +In some cases, there can instead be undefined behavior. Much of this |
6144 | 6144 | subclause is motivated by the desire to support atomic operations with explicit
|
6145 | 6145 | and detailed visibility constraints. However, it also implicitly supports a
|
6146 | 6146 | simpler view for more restricted programs.
|
|
6507 | 6507 | \begin{note}
|
6508 | 6508 | Compiler transformations that introduce assignments to a potentially
|
6509 | 6509 | shared memory location that would not be modified by the abstract machine are
|
6510 |
| -generally precluded by this document, since such an assignment might overwrite |
| 6510 | +generally precluded by this document, since such an assignment can overwrite |
6511 | 6511 | another assignment by a different thread in cases in which an abstract machine
|
6512 | 6512 | execution would not have encountered a data race. This includes implementations
|
6513 | 6513 | of data member assignment that overwrite adjacent members in separate memory
|
6514 | 6514 | locations. Reordering of atomic loads in cases in which the atomics in question
|
6515 |
| -might alias is also generally precluded, since this could violate the coherence |
| 6515 | +can alias is also generally precluded, since this could violate the coherence |
6516 | 6516 | rules.
|
6517 | 6517 | \end{note}
|
6518 | 6518 |
|
6519 | 6519 | \pnum
|
6520 | 6520 | \begin{note}
|
6521 | 6521 | Transformations that introduce a speculative read of a potentially
|
6522 |
| -shared memory location might not preserve the semantics of the \Cpp{} program as |
| 6522 | +shared memory location can not preserve the semantics of the \Cpp{} program as |
6523 | 6523 | defined in this document, since they potentially introduce a data race. However,
|
6524 | 6524 | they are typically valid in the context of an optimizing compiler that targets a
|
6525 | 6525 | specific machine with well-defined semantics for data races. They would be
|
|
6560 | 6560 | a lock-free execution in that thread shall complete.
|
6561 | 6561 | \begin{note}
|
6562 | 6562 | Concurrently executing threads
|
6563 |
| - might prevent progress of a lock-free execution. |
| 6563 | + can prevent progress of a lock-free execution. |
6564 | 6564 | For example,
|
6565 | 6565 | this situation can occur
|
6566 | 6566 | with load-locked store-conditional implementations.
|
|
6680 | 6680 | guarantees, which in turn are stronger than weakly parallel forward progress
|
6681 | 6681 | guarantees.
|
6682 | 6682 | \begin{note}
|
6683 |
| -For example, some kinds of synchronization between threads of execution might only |
| 6683 | +For example, some kinds of synchronization between threads of execution can only |
6684 | 6684 | make progress if the respective threads of execution provide parallel forward progress
|
6685 | 6685 | guarantees, but will fail to make progress under weakly parallel guarantees.
|
6686 | 6686 | \end{note}
|
|
0 commit comments