If C-1999's "restrict" keyword is added to C++, we should add it to
operator new's return type and operator delete's parameter (T restrict
*).  I think it means that an object has no alias anywhere else, so the
compiler can make optimizations that can assume that no other pointer
aliases that object and can interfere in the process.  Operator new
creates an object, so "restrict" is pretty much garunteed for its return
value, except for perverse uses of placement new, since no existing
pointer can know its address.  Using "restrict" for operator delete has
a greater chance of being a lie, but you are screwed anyway if you have
a pointer that had its object deleted through a seperate copy.

The "restrict" qualifier works like "const" and "volatile," so we should
use "const_cast" to toggle its state.  (Anyone else think we should
rename this cast operator?)

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <1eg9ym7.2ss2st76zt9uN%dwalker07@snet.net.invalid>,
dwalker07@snet.net.invalid (Daryle Walker) wrote:

> If C-1999's "restrict" keyword is added to C++, we should add it to
> operator new's return type and operator delete's parameter (T restrict
> *).  I think it means that an object has no alias anywhere else, so the
> compiler can make optimizations that can assume that no other pointer
> aliases that object and can interfere in the process.  Operator new
> creates an object, so "restrict" is pretty much garunteed for its return
> value, except for perverse uses of placement new, since no existing
> pointer can know its address.

See below: "restrict" for the return value of a function makes no sense.

> Using "restrict" for operator delete has
> a greater chance of being a lie, but you are screwed anyway if you have
> a pointer that had its object deleted through a seperate copy.

operator delete doesn't have the task to change any memory pointed to by
its argument, so there is no need for a "restrict" argument. The situation
is very much different for a destructor: A destructor could very well have
a "restrict" this argument. That means that fields that the destructor
accesses through the "this" pointer must not be accessed through pointers
not derived from this.

> The "restrict" qualifier works like "const" and "volatile," so we should
> use "const_cast" to toggle its state.  (Anyone else think we should
> rename this cast operator?)

With "const" and "volatile", there are two distinct properties: Whether an
object _is_ const or volatile, and whether you have a pointer that
declares its target to be const or volatile. You can have a const int *
pointing to a non-const int, so casting such a pointer to int * can make
sense.

restrict is different: You have "restrict" pointers and pointer values
derived from that. If you have a pointer int restrict* p and calculate
p+1, then p+1 is not a "restrict" pointer: It is a pointer "derived from"
a restrict pointer, and that is something different.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]