------=_Part_3614_16247580.1365334206576
Content-Type: text/plain; charset=ISO-8859-1



At moment, if performance is a concern of yours then aliasing should be
too. Where pointer aliasing would be an issue, for a portable solution
(i.e. non-compiler specific) you have to do a lot of small value passing,
local variable usage (i.e. temps), & even class member copying, &/or manual
common subexpression elimination. Also generally minimising the use of
references & pointers (i.e. you are on a strict subset of C++).

It's a disappointment that there is no clean portable way (like C's
restrict keyword) to assist the compiler to generate optimal code. Instead
work arounds such as those listed lead to more fuzzy code, greater
instruction cache load, & lot more mental overload than if there were a
default go-to solution like having a "restrict" keyword.

The in parameter proposal is another decent solution, but will likely face
difficulty in being adopted due to the significant change it proposes.
With the restrict keyword as part of C, & implemented by some compilers
already (though for some, implementation covers specific forms only - it
appears that LLVM, for example, ignores restrict everywhere except function
parameters) it does seem the most likely way forward for acceptance. C++
programmers got override & final keywords as opposed to attributes (a good
thing IMHO). I'm really hoping we can get "restrict" in the next language
enhancement.

What critical arguments have there been against "restrict"?

What has the general/initial reaction to N3538
(http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3538.html) been
like?

Also, once upon a time was there not a restricted pointer/reference
proposal? I guess, without having reviewed it, this would now be a type of
pointer/reference not to allow reseating and to somehow block the memory
location from aliasing (like a cross between a unique pointer & a
reference-counted pointer, in that it can be moved around (not copied), and
a reference of only 1 is allowed on the memory location)? An idea, but
still a restrict keyword applicable to both pointers & references is likely
a better solution.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_3614_16247580.1365334206576
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>At moment, if performance is a concern of yours then aliasing shoul=
d be too. Where pointer aliasing would be an issue, for a portable solution=
 (i.e. non-compiler specific) you have to do a lot of small value passing, =
local variable usage (i.e. temps), &amp; even class member copying, &amp;/o=
r manual common subexpression elimination. Also generally minimising the us=
e of references &amp; pointers (i.e. you are on a strict subset of C++).<br=
><br>It's a disappointment that there is no clean portable way (like C's re=
strict keyword) to assist the compiler to generate optimal code. Instead wo=
rk arounds such as those listed lead to more fuzzy code, greater instructio=
n cache load, &amp; lot more mental overload than if there were a default g=
o-to solution like having a "restrict" keyword. <br><br>The in parameter pr=
oposal is another decent solution, but will likely face difficulty in being=
 adopted due to the significant change it proposes.&nbsp; With the restrict=
 keyword as part of C, &amp; implemented by some compilers already (though =
for some, implementation covers specific forms only - it appears that LLVM,=
 for example, ignores restrict everywhere except function parameters) it do=
es seem the most likely way forward for acceptance. C++ programmers got ove=
rride &amp; final keywords as opposed to=20
attributes (a good thing IMHO). I'm really hoping we can get "restrict"=20
in the next language enhancement.&nbsp; <br><br>What critical arguments hav=
e there been against "restrict"? <br><br>What has the general/initial react=
ion to N3538=20
(http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3538.html) been l=
ike?<br><br>Also, once upon a time was there not a restricted pointer/refer=
ence proposal? I guess, without having reviewed it, this would now be a typ=
e of pointer/reference not to allow reseating and to somehow block the memo=
ry location from aliasing (like a cross between a unique pointer &amp; a re=
ference-counted pointer, in that it can be moved around (not copied), and a=
 reference of only 1 is allowed on the memory location)? An idea, but still=
 a restrict keyword applicable to both pointers &amp; references is likely =
a better solution.<br><br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3614_16247580.1365334206576--

.