🚀 go-pugleaf

Bill Leonard (bill@amber.ssd.hcsc.com) wrote:
: In article <465q4m$j07@wcap.centerline.com>, chase@centerline.com (David Chase)
:  writes:
: > I'm not sure that I agree with this.  I haven't been following the
: > proposals, but if the annotations appear in the function declaration
: > (like const) then I think it ok.  The reason for this is that it
: > proclaims, loud and clear, to clients:
: > 
: >   these arrays had better not overlap.
: > 
: > and
: > 
: >   future versions of this code (i.e., recompilations) reserve the right
: >   to access these array elements in a different order than they do now.
: > 
: > or (rephrased)
: > 
: >   the order in which the elements of the arrays are referenced is an
: >   implementation detail; clients should not rely on this.

: But programmers, even the best ones, make mistakes.  Now I'd be the first
: to agree that no language can prevent programmers from making mistakes, but
: I also believe one needs to strike a balance between benefits and cost.
: Bugs due to mistakenly declaring an absence of aliasing are extremely
: costly to find and fix.

Hmmm. Suppose you claim that X[20][20] and Y[20] are not aliases of
each other. What's wrong with:

assert(&Y[20] <= &X[0][0] && X[20][20] >= Y[0]);

(apart from the obvious fact that it's not portable)?

Maybe what the language needs, rather than another kind of attribute,
is a predicate (given that a compiler probably couldn't easily check
an attribute).

In fact, couldn't a compiler take some loop:

for (...)
  for (...)
    X[...] = Y[..] * X[...];

and turn it into:

if (X and Y are aliased)
  for (...)
    for (...)
      X[...] = Y[..] * X[...];
else
  some_neat_vectorop(X,Y);

which has the advantage that you don't have to check _anything_, and
can't possibly get an invalid answer; and if you happen to also have
the assert above, it can optimise out the first branch of the if.

--
-Geoff Keating (keagchon@mehta.anu.edu.au)

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]