In article <HAGAR.94Apr21131143@ulam.engin.umich.edu> hagar@engin.umich.edu (ulam) writes:
>
>I learned recently that a proposal was put to the standards committee
>to include a key word "restrict" to indicate that a pointer would not
>be used to alias any other data (presumably within the scope wherein
>the pointer was declared as restrict(ed)). The purpose is, of course,
>to expose data dependancies (or the lack thereof) to the compiler so
>as to allow optimizations that could not otherwise be safely and
>automatically done (some loop unrollings, vectorization, etc)
>
>I've used this (non-ANSI) mechanism in c on cray machines, where it
>pretty crucial if c code is to come anywhere close to code produced by
>the fortran compiler.
>
>I'm just curious as to the reasons this proposal was rejected for c++
>(if in fact it was). Was the proposal half-baked or unimplementable,
>or did philosophy come into play? It's certainly not very safe, and
>has more of a c "the programmer knows what she's doing" flavor than a
>c++ "safety at (almost) all costs" flavor.

 I think 'noalias' was actually added to the C language
at one time and had to be removed again because it didnt work.
The C++ committee will not mess around with this, IMHO.
Loss of automatic optimisation opportunities is a consequence of
the granting to the programmer the power to optimise things manually.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

I learned recently that a proposal was put to the standards committee
to include a key word "restrict" to indicate that a pointer would not
be used to alias any other data (presumably within the scope wherein
the pointer was declared as restrict(ed)). The purpose is, of course,
to expose data dependancies (or the lack thereof) to the compiler so
as to allow optimizations that could not otherwise be safely and
automatically done (some loop unrollings, vectorization, etc)

I've used this (non-ANSI) mechanism in c on cray machines, where it
pretty crucial if c code is to come anywhere close to code produced by
the fortran compiler.

I'm just curious as to the reasons this proposal was rejected for c++
(if in fact it was). Was the proposal half-baked or unimplementable,
or did philosophy come into play? It's certainly not very safe, and
has more of a c "the programmer knows what she's doing" flavor than a
c++ "safety at (almost) all costs" flavor.

Are any compiler implementors going to implement such a mechanism as a
pragma instead?

James
--
-------------------------------------------------------------------------
James Paul Holloway                         |hagar@umich.edu
-------------------------------------------------------------------------