Frederick Gotham wrote:
> Is there any intention to add "restrict" pointers to C++, as they have in
> C99?
>
C++0x is closed for new proposals... So it probably can't be introduced
in C++0x.

There are a number of C99/C++ compilers supporting a __restrict (or
__restrict__ or whatever) keyword in C++ mode.
But, the WG21 doesn't concentrate on unsafe features... Especially if
all they give is optimization.
restrict probably has a lot of issues with object & classes.... But, in
the worst case, I think that the ISO standard could say that restrict
applies only on POD types or even simplier types, such as avoiding the
complexity of the stuff, and still being compatible with C99.

After all... the restrict keyword is a good reason for C adepts to say
that "C++ is slower". And it will probably remain one for a long time.

Antti Virtanen wrote:
> How many C++
> programs benefit from this optimisation and how much? Not many I suspect.
Yes, probably not many, because C++ programs are relatively high-level.

> Consider that in many cases it is possible to use C++
> features, which are not present in C99, to achieve safe
> restricted pointers, though they may not be as fast and require
> some additional coding.
How?
AFAIK, matrix manipulations can be very much optimized (with SSE or
3DNow! instructions) thanks to the "restrict" keyword.
I can't see any easy way to do that in C++.
Perhaps partially unrolling the loop and copying values to temporary
automatic variables... Yes, it is possible, you're right... But I
suspect that it is not possible for all usages of restrict.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

X-Replace-Address:yes
SuperKoko wrote:
> AFAIK, matrix manipulations can be very much optimized (with SSE or
> 3DNow! instructions) thanks to the "restrict" keyword.
> I can't see any easy way to do that in C++.

I believe that std::valarray has been introduced to address
exactly this optimization problem - i.e. to avoid memory load/store
operations that were necessary with C-style arrays due to the
possibility of aliasing resulting from the presence of pointers
and pointer arithmetics. See =A7 26.3.1/2.
I don't know which compilers already implement the optimizations
enabled by std::valarray, neither which C99 compilers actually
honor the restrict keyword.

Falk

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Antti Virtanen wrote:
> On 2006-07-01, Frederick Gotham <fgothamNO@SPAM.com> wrote:
>
> > Is there any intention to add "restrict" pointers to C++, as they have in
> > C99?
>
> Six years ago in a devx.com article:
> (http://www.devx.com/tips/Tip/13825)
>
> "C++ doesn't support restrict yet. However, since many C++
> compilers are also C compilers, it's likely that this feature will
> be added to most C++ compilers too."
>
> Seems this is not happening. Somewhat artificial example:
>
> obj* c[2];
> obj* s = c[0];
> restrict obj* p = c[1];
> s++;
> s->someFunction(); // illegal
>
> The first thing that came to my mind was that every method call through
> a pointer would be slower with restricted pointers in the scope. It is

Restrict does not change the semantics of the code it occurs in at all.
It's only effect is to promise that, within the scope of a
restrict-qualified pointer, all accesses to the object pointed at by
that pointer will be through that pointer, or other pointers derived
from it. The effect of this promise is to allow certain optimizations
that would otherwise be illegal. An implementation could legally
generate slower code for restricted pointers than for regular pointers,
but only because it perversely decided to do so; there's nothing in the
definition of 'restrict' that requires or even encourages slower code.

> very difficult for the compiler to figure when a pointer can or can not
> point to a particular restricted object.

The only objects that are restricted are the pointers themselves. The
compiler only needs to figure out whether a pointer points is derived
from a restricted pointer if it wants to apply optimizations that would
be legal only for such pointers. If figuring that out is excessively
expensive, it shouldn't bother, and just interpret the code as if the
pointer was not restricted, which is perfectly legal.

> >From IBM I found the following answer:
>
> "It is the responsibility of the programmer to ensure that restrict
> -qualified pointers are used as they were intended to be used.
> Otherwise, undefined behavior may result."
>
> If this is true, then "restrict" really doesn't prevent anything
> and doesn't carry a performance penalty. It will make some
> programs faster because the compiler can make certain
> optimisations, but doesn't make them any safer.

True - the 'restrict' qualification is about optimization, not about
safety. Since it allows optimizations that would be unsafe if the
requirements of 'restrict' are not met, it actually provides new ways
for code to fail.

However, it is almost always an error to have any other pointer
pointing at the same object as a restrict-qualified pointers if they
are both in scope in at that time. That is a condition that can often
be detected at compile time, so the restrict qualifier does provide a
small opportunity for improved warning messages. At the language level,
that situation wouldn't be an error without the restrict qualifier.
However, in any situation where use of 'restrict' is appropriate, such
use would be a logic error, even if it's not a language error.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Frederick Gotham wrote:
> Is there any intention to add "restrict" pointers to C++, as they have in
> C99?

I thought Stroustrup in particular is trying to unite C and C++ as much
as possible. C++0x does have, for example, variable argument macros, so
it may be an accidental omission if restrict isn't there. It's
certainly a worthwhile feature, and it would be standardising existing
practice. For example, Blitz++ uses it with C++ compilers that support
it as an extension, such as Kai C++ and GCC (IIRC).

Tom

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Falk Tannh   user wrote:
> I don't know which compilers already implement the optimizations
> enabled by std::valarray, neither which C99 compilers actually
> honor the restrict keyword.
>
Once I tried that with GCC (4.0.0) and ICC... Both gave very good
optimizations with restrict.
I think that it is very easy to support for an optimizer, because the
notion of "restricted pointer" is already internally used for a large
number of optimizations.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Is there any intention to add "restrict" pointers to C++, as they have in
C99?

--

Frederick Gotham

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 2006-07-01, Frederick Gotham <fgothamNO@SPAM.com> wrote:

> Is there any intention to add "restrict" pointers to C++, as they have in
> C99?

Six years ago in a devx.com article:
(http://www.devx.com/tips/Tip/13825)

"C++ doesn't support restrict yet. However, since many C++
compilers are also C compilers, it's likely that this feature will
be added to most C++ compilers too."

Seems this is not happening. Somewhat artificial example:

obj* c[2];
obj* s = c[0];
restrict obj* p = c[1];
s++;
s->someFunction(); // illegal

The first thing that came to my mind was that every method call through
a pointer would be slower with restricted pointers in the scope. It is
very difficult for the compiler to figure when a pointer can or can not
point to a particular restricted object. If there is a penalty, this
alone would be a reason to leave restrict out.

>From IBM I found the following answer:

"It is the responsibility of the programmer to ensure that restrict
-qualified pointers are used as they were intended to be used.
Otherwise, undefined behavior may result."

If this is true, then "restrict" really doesn't prevent anything
and doesn't carry a performance penalty. It will make some
programs faster because the compiler can make certain
optimisations, but doesn't make them any safer. How many C++
programs benefit from this optimisation and how much? Not many I
suspect. Consider that in many cases it is possible to use C++
features, which are not present in C99, to achieve safe
restricted pointers, though they may not be as fast and require
some additional coding.

// Antti Virtanen -//- http://www.students.tut.fi/~virtanea
--
"Indeed, it is becoming increasingly clear that for almost all programs,
correctness rather than speed is the paramount concern."
        Crafting a compiler in C, 1991

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]