• 12
• 10
• 10
• 13
• 10

# __restrict on references

This topic is 3550 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Why is there no support for the __restrict keyword on references? Do references have a hidden, implicit "restrict" behavior, and thus always optimize OK? http://msdn.microsoft.com/en-us/library/5ft82fed(VS.80).aspx I must admit that in the past it *seems* like I've had less detection of aliasing potentials by compilers when I use references over pointers... and thus faster code.

##### Share on other sites
References can't be reseated, and a reference can't refer to an "array" of subsequent values in memory, like a pointer can point at, so a lot more is known about their aliasing.

##### Share on other sites
Quote:
 Original post by ZahlmanReferences can't be reseated...

This compiles OK in VS2005... is this behavior MS-specific?

class foo{public:	int a;};int main(){	foo f1;	foo f2;	foo& r = f1;	r = f2;...}

##### Share on other sites
Quote:
Original post by discman1028
Quote:
 Original post by ZahlmanReferences can't be reseated...

This compiles OK in VS2005... is this behavior MS-specific?

*** Source Snippet Removed ***

That reference isn't being re-seated. You're simply copying the object via the copy assignment operator.

For illustration, here is equivalent code using pointers instead of references:

class foo{public:	int a;        void operator=(const foo& rhs)        {            std::cout << "Assignment Operator" << std::endl;        }};int main(){	foo f1;	foo f2;	foo* r = &f1;	(*r) = f2;}

##### Share on other sites
Quote:
 Original post by fpsgamerThat reference isn't being re-seated. You're simply copying the object via the copy assignment operator.

Ah yeah... oops. :)

Anyhow, more quibble:

Quote:
 Original post by Zahlman...a reference can't refer to an "array" of subsequent values in memory...

But a reference can be passed into a function, making it a "black box" as far as the function is concerned (unless alias analysis goes beyond function scope, which it could but I doubt most compilers do).

Plus, an object offset into an array such as "objArray[counter]" can be seated to a reference, in which case no more is known about their aliasing than a pointer that steps along an array.

Plus, a pointer (as opposed to a second reference) could be pointing to the same memory the reference is referencing.

3 reasons for __restrict for references... right?

##### Share on other sites
Unless, as I mentioned earlier, references have an implicit "restrict" behavior, in which case none of the above three present an issue...