<html>
<head>
<title>N3362: Terminology: "indirection" versus "dereference" (revision 2)</title>

<style type="text/css">
  ins { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  del { text-decoration:line-through; background-color:#FFA0A0 }
</style>

</head>

<body>
N3362=12-0052<br/>
revision of: N3324=12-0014<br/>
Jens Maurer<br/>
2012-02-10

<h1>Terminology: "indirection" versus "dereference" (revision 2)</h1>

<p>
This paper addresses core issue 342 and implements a consistent
terminology for "indirection through a pointer" throughout the core
language section of the standard.  As decided in Bloomington, the term
"dereference" would be replaced by "indirection".  This paper reflects
the additional comments made during review at the Kona meeting.  Due
to the volume of the changes, they are presented as a separate paper
as opposed to integrating them into the core issues list.
</p>

Here is the list of places that
already uses "indirection":</em>
<ul>
<li>5.3.1 expr.unary.op paragraph 1</li>
<li>8.3.4 dcl.array paragraph 8</li>
<li>8.3.5 dcl.fct paragraph 9</li>
<li>20.4.7.4 lib.meta.trans.pt</li>
</ul>

Change in 3.7.4.1 basic.stc.dynamic.allocation paragraph 2:
<blockquote>
... The effect of <del>dereferencing</del> <ins>indirecting
through</ins> a pointer returned as a request for zero size is undefined. [
Footnote: ... ]
</blockquote>

Change in 3.7.4.3 basic.stc.dynamic.safety paragraph 2:
<blockquote>
<ul>
<li> the value returned by a call to the C++ standard library
implementation of <code>::operator new(std::size_t)</code>; [ Footnote: This
section does not impose restrictions on <del>dereferencing</del>
<ins>indirection through</ins> pointers to
memory not allocated by <code>::operator new</code>. This maintains
the ability of many C++ implementations to use binary libraries and
components written in other languages. In particular, this applies to
C binaries, because <del>dereferencing</del> <ins>indirection through</ins>
pointers to memory allocated by <del><code>malloc</code></del>
<ins><code>std::malloc</code></ins> is not restricted. ]</li>
<li>the result of taking the address of an object (or one of its
subobjects) designated by an lvalue resulting from
<del>dereferencing</del> <ins>indirection through</ins> a safely-derived
pointer value;</li>
<li>...</li>
</ul>
</blockquote>

Change in 3.8 basic.life paragraph 5:
<blockquote>
... <ins>Indirection through such</ins> <del>Such</del> a
pointer <del>may be dereferenced</del> <ins>is permitted</ins> but the
resulting lvalue may only be used in limited ways, as described
below. The program has undefined behavior if:
<ul>
<li>...</li>
</ul>
</blockquote>

Change in 4.11 conv.mem paragraph 2:
<blockquote>
... Since the result has type "pointer to member of <code>D</code> of
type <em>cv</em> <code>T</code>", <del>it can be dereferenced</del>
<ins>indirection through it</ins> with a <code>D</code>
object <ins>is valid</ins>. The result is the same as if
<ins>indirecting through</ins> the pointer to member of
<code>B</code> <del>were dereferenced</del>
with the <code>B</code> subobject of <code>D</code>. The null member
pointer value is converted to the null member pointer value of the
destination type. [ Footnote: ... ]
</blockquote>

Change in 5.2.9 expr.static.cast paragraph 12:
<blockquote>
... [ Note: although
class <code>B</code> need not contain the original member, the dynamic
type of the object <del>on</del> <ins>with</ins> which
<ins>indirection through</ins> the pointer to member is <ins>performed</ins>
<del>dereferenced</del> must contain the original member; see 5.5
expr.mptr.oper. -- end note ]
</blockquote>

Change in 5.3.1 expr.unary.op paragraph 1:
<blockquote>
... [ Note: <ins>indirection through</ins> a pointer to an incomplete
type (other than <em>cv</em> <code>void</code>) <ins>is valid</ins>
<del>can be dereferenced</del>.  ... ]
</blockquote>

Change in 5.10 expr.eq paragraph 2:
<blockquote>
... Otherwise they compare equal if and only if they would refer to
the same member of the same most derived object (1.8 intro.object)
or the same subobject if <del>they were dereferenced</del>
<ins>indirection</ins> with a hypothetical object of the
associated class type <ins>were performed</ins>. [ Example: ... ]
</blockquote>

Change in 7.5 dcl.link paragraph 8:
<blockquote>
[ Note: Because the language linkage is part of a function type, when
<ins>indirecting through</ins> a pointer to C function <del>(for
example) is dereferenced</del>, the function to
which <del>it</del> <ins>the resulting lvalue</ins> refers is
considered a C function. -- end note ]
</blockquote>

Change in 8.3.2 dcl.ref paragraph 5:
<blockquote>
... [ Note: in particular, a null reference cannot exist in a
well-defined program, because the only way to create such a reference
would be to bind it to the "object" obtained by
<del>dereferencing</del> <ins>indirection through</ins> a null
pointer, which causes undefined behavior. As described in 9.6
class.bit, a reference cannot be bound directly to a bit-field. ]
</blockquote>


<em>Drafting note: The term "dereferenceable" is defined for iterators
in 24.2.1p5.  I see no need to eradicate that term.  Therefore,
17.6.3.2 swappable.requirements p5, 23.2.3 sequence.reqmts p3, 23.2.4
associative.reqmts p8 and many more are unchanged.</em>

<p>

Change in 17.6.3.5 allocator.requirements table 27:
<blockquote>
a <del>dereferenceable</del> pointer of type <code>C*</code>
<ins>through which indirection is valid</ins>
</blockquote>

Change in 20.6.3.2 pointer.traits.functions:
<blockquote>
<em>Returns:</em> The first member function returns a
<del>dereferenceable</del> pointer to r obtained by calling
Ptr::pointer_to(r) <ins>through which indirection is valid</ins>; an
instantiation of this function is ill-formed if Ptr does not have a
matching pointer_to static member function. The second member function
returns <code>std::addressof(r)</code>.

</blockquote>

Change in 20.6.4 util.dynamic.safety paragraph 10:
<blockquote>
... Hence <ins>indirection through a pointer</ins> <del>pointers</del>
located there <del>may not be dereferenced</del> <ins>is
undefined</ins> if the object <del>they point</del> <ins>it
points</ins> to was created by global <code>operator new</code> and
not previously declared reachable. [
Note: ... ]
</blockquote>

Change in 20.6.12 specialized.algorithms paragraph 1:
<blockquote>
... In all of the following algorithms, the formal template parameter
<code>ForwardIterator</code> is required to satisfy the requirements
of a forward iterator (24.2.5 forward.iterators), and is required to
have the property that no exceptions are thrown from increment,
assignment, comparison, or <del>dereference of</del>
<ins>indirection through</ins> valid iterators. ...
</blockquote>

Change in 22.4.5.1.2 locale.time.get.virtuals paragraph 11:
<blockquote>
<em>Requires:</em> <code>t</code> shall <del>be dereferenceable</del>
<ins>point to an object</ins>.
</blockquote>

Change in 23.4.4.2 map.cons paragraph 3:
<blockquote>
<em>Requires:</em> If the iterator's <del>dereference</del>
<ins>indirection</ins> operator returns an lvalue or a const rvalue
<code>pair&lt;key_type, mapped_type&gt;</code>, then both
<code>key_type</code> and <code>mapped_type</code> shall be
<code>CopyConstructible</code>.
</blockquote>

Change in 23.4.5.2 multimap.cons paragraph 3:
<blockquote>
<em>Requires:</em> If the iterator's <del>dereference</del>
<ins>indirection</ins> operator returns an lvalue or a const rvalue
<code>pair&lt;key_type, mapped_type></code>, then both
<code>key_type</code> and <code>mapped_type</code> shall be
<code>CopyConstructible</code>.
</blockquote>

Change in 23.4.6.2 set.cons paragraph 4:
<blockquote>
<em>Requires</em> If the iterator's <del>dereference</del>
<ins>indirection</ins> operator returns an lvalue or a non-const
rvalue, then <code>Key</code> shall be <code>CopyConstructible</code>.
</blockquote>

Change in 23.4.7.2 multiset.cons paragraph 3:
<blockquote>
<em>Requires</em> If the iterator's <del>dereference</del>
<ins>indirection</ins> operator returns an lvalue or a non-const
rvalue, then <code>Key</code> shall be <code>CopyConstructible</code>.
</blockquote>

Change in 24.5.3 move.iterators paragraph 1:
<blockquote>
Class template <code>move_iterator</code> is an iterator adaptor with
the same behavior as the underlying iterator except that its
<del>dereference</del> <ins>indirection</ins> operator implicitly
converts the value returned by the underlying iterator's
<del>dereference</del> <ins>indirection</ins> operator to an rvalue
reference. ....
</blockquote>

Change the title of 28.12.1.3  re.regiter.deref
<blockquote>
<code>regex_iterator</code> <del>dereference</del> <ins>indirection</ins>
</blockquote>

Change the title of 28.12.2.3 re.tokiter.deref
<blockquote>
<code>regex_token_iterator</code> <del>dereference</del>
<ins>indirection</ins>
</blockquote>


</body>
</html>
