D const design rationale
Bill Baxter
dnewsgroup at billbaxter.com
Sat Jun 23 21:44:33 PDT 2007
Don Clugston wrote:
> Walter Bright wrote:
>> You can't do that with C/C++ because arrays can be aliased. I have a
>> stack of papers 6" deep in the basement on trying to make C more
>> suitable for numerics, and it's mostly about, you guessed it, fixing
>> the alias problem. They failed.
>
> How much of this will actually be solved by invariant?
> It seems to me that typically, arrays are built up element-by-element,
> even if they never change again. I guess in D2.0, such code would
> initialize a temporary array, and finally idup it?
>
> The aliasing problem will be far from gone, though. Consider an in-place
> operation on a matrix. Frequently you modify one only row at a time,
> based on the remaining rows. I think you'd have to cast(invariant) those
> other rows, to avoid aliasing.
Thanks for asking this. It's been eating at me too. From what I
understand of Fortran code, you declare an array of a given size, set
its values however you like, then pass it to a function. But if we make
an invariant D array we can't set its values after initialization. So
it doesn't seem very useful. Or is the use pattern going to be, as you
say, Don, casting to invariant every time you need to call
fast_math_array_function()? If that's the case I suspect it won't take
long before this becomes an idiom:
/* x += y array-style */
add_accum(double[] x, const double[] y) {
_add_accum_impl(cast(invariant)x,cast(invariant)y);
}
Is that really what we want?
That code can't even be right though, because x is *supposed* to get
modified there. So how do you denote lack of aliasing on something like
that using invariant? In this respect C99's 'restrict' seems to be a
lot more understandable. My naive understanding of it being that you
just slap it on any argument that you want to tell the compiler it can
assume to be non-aliased.
--bb
More information about the Digitalmars-d
mailing list