On Wed, 12 Apr 2000 rainer_blome@de.ibm.com wrote:
> > If a restrict qualifier at the
> > top level in a type follows the same rules as const and volatile
> > (which I think it should)
>
> My gut feeling is that it should not. Const and volatile after an
> asterisk talk about the pointer itself (the place where its value is
> stored), not about the pointer's target. The top-level qualifiers that
> exist so far (const and volatile) do not affect overloading
> because they do not make a semantic difference for a caller (the caller
> shouldn't care whether the implementation modifies the pointer's value
> or not).
>
> In contrast to this, restrict talks about the target, not really about
> the pointer's value. Therefore, it does make a semantic difference
> to the caller (the caller *must* care whether pointer targets are
> aliased or not). Consequently restrict should participate in overloading.
> In this sense, restrict is not a top-level qualifier.
I would say that the idea that restrict is more about the pointer
target than the pointer itself does not really reflect the semantics of
the qualifier.
The best analogy I have been able to think of is a lease. In a large
office building (memory), space may be leased (by a declaration that is
a definition, or by dynamic allocation), and then sub-leased (aliased
through pointers or references). There are non-exclusive leases
(aliasing through unrestricted pointers and references), in which the
lessor together with one or more lessees jointly occupy the same
space. Whatever arrangements they make to avoid interfering with each
other is beyond the scope of the lease. There are also exclusive
leases (aliasing through restricted pointers or references), in which
the one lessee occupies space to the exclusion of the lessor and other
lessees of the lessor. The lessee himself may sub-let his space, in
whole or in part, if he wishes, using either type of lease. In any
areas that that are not sub-let, the exclusive lease gives the lessee
the expectation that when he returns after an absence, the furniture
will be where he left it.
For space that has been leased and then sub-leased one of more times, is
the exclusivity of one of those leases more about the (rights and
expectations of the) lessor or more about the space itself? It's not
clear that this is a useful question. Nevertheless, it seems better
for an exclusive lessee to possess a copy of his lease (rather than
relying on a copy posted in the leased space). By this analogy, it
also seems better for a restricted pointer to "possess" the restrict
qualifier.
> Admittedly, restrict syntactically behaves somewhat like a top level
> qualifier. As far as I understand it, restrict was `syntactically
> moved behind the asterisk or ampersand' to indicate that it can only
> be used on pointers and references (and to keep the syntax simple).
> Maybe the keyword conceptually belongs
> before the asterisk (e.g. copy(int const restrict *, int *)).
There was a previous attempt to do it this way, using the "noalias"
keyword, but it was unsuccessful.
> There are places where const can be used where restrict is not
> allowed. For other places, the converse is true (`&restrict' is OK,
> `&const' is bogus). So it should be no big problem to also differentiate
> them with respect to overloading. The language spec may be uglier then,
> but it will be more useful.
Of course it is non-conforming, but I would say '&const' is not so much
bogus as redundant. A reference, once established, cannot be modified
because no means were provided to modify it. So it is const by
definition.
I have argued in another message that using top-level restrict
qualifiers for template argument deduction is not desirable. I think
the same arguments apply to overloading of ordinary functions, and we
can pursue that in more detail, if anyone expresses an interest.
> I would like to read about the reasoning behind restrict in C, can
> anybody point me to a reference about this?
See:
http://reality.sgi.com/homer_craypark/
to find a rationale attached to the official specification, and also a
couple of historical documents that show penultimate versions of the
proposal and discusses reasons for the last round of changes. The
latter are useful to get an idea of some of the subtleties which which
an aliasing proposal must grapple.
-- Bill Homer (651) 683-5606 Cray Inc. homer@cray.com 655F Lone Oak Drive, Eagan, MN 55121--------------------- Object Oriented Numerics List -------------------------- * To subscribe/unsubscribe: use the handy web form at http://oonumerics.org/oon/ * If this doesn't work, please send a note to owner-oon-list@oonumerics.org
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:13 EST