I\'ve been watching Mike Acton\'s talk on Data-oriented design in C++ in CppCon 2014, and he gives this example:
int Foo::Bar(int count)
{
int value = 0;
__restrict__
is not standardized in C++, so this question can only be answered on a particular platform. For GCC, you can apply __restrict__
to this
in the same way as const
:
void T::fn () __restrict__
There is no potential aliasing in your example. C++ specifies undefined behavior for data races.
A new system for C++ restricted pointers is being developed. It will likely be standardized in C++17. Support for this
is one of the stated design goals.
With the code that you posted, code compiled with any optimisation at all should not re-read that class member. However, take this similar code:
void Foo::Bar(int count, int* result)
{
*result = 0;
for (int i = 0; i < count; i++) {
if (m_someDataMemberOfFoo) (*result)++;
}
}
In this case, the compiler must assume that result == &m_someDataMemberOfFoo is a possibility, if that member has type int. Obviously any developer calling it the way deserves to get his programming license revoked, but it is legal and the compiler must handle this correctly.
This is even the case if you mark the method as "const". A const method is not allowed to modify any part of *this by using the this pointer (with some exceptions). However, members of *this can be legally modified in other ways if the actual object is not const.
"restrict" in C is intended to fix the problem, and hopefully the same feature in C++ would fix it in this case.