Can C's restrict keyword be emulated using strict aliasing in C++?

Question

The Problem

The restrict keyword in C is missing in C++, so out of interest I was looking for a way to emulate the same feature in C++.

Specifically, I would like the following to be equivalent:

// C
void func(S *restrict a, S *restrict b)

// C++
void func(noalias<S, 1> a, noalias<S, 2> b)

where noalias<T, n>

• behaves just like T* when accessed with -> and *
• can be constructed from an T* (so that the function can be called as func(t1, t2), where t1 and t2 are both of type T*)
• the index n specifies the "aliasing class" of the variable, so that variables of type noalias<T, n> and noalias<T, m> may be assumed never to alias for n != m.

An Attempt

Here is my deeply flawed solution:

template <typename T, int n>
class noalias
{
    struct T2 : T {};
    T *t;

public:
    noalias(T *t_) : t(t_) {}
    T2 *operator->() const {return static_cast<T2*>(t);} // <-- UB
};

When accessed with ->, it casts the internally-stored T* to a noalias<T, n>::T2* and returns that instead. Since this is a different type for each n, the strict aliasing rule ensures that they will never alias. Also, since T2 derives from T, the returned pointer behaves just like a T*. Great!

Even better, the code compiles and the assembly output confirms that it has the desired effect.

The problem is the static_cast. If t were really pointing to an object of type T2 then this would be fine. But t points to a T so this is UB. In practice, since T2 is a subclass which adds nothing extra to T it will probably have the same data layout, and so member accesses on the T2* will look for members at the same offsets as they occur in T and everything will be fine.

But having an n-dependent class is necessary for strict aliasing, and that this class derives from T is also necessary so that the pointer can be treated like a T*. So UB seems unavoidable.

Questions

• Can this be done in c++14 without invoking UB - possibly using a completely different idea?

• If not, then I have heard about a "dot operator" in c++1z; would it be possible with this?

• If the above, will something similar to noalias be appearing in the standard library?

Answer 1

You could use the __restrict__ GCC extension for un/aliasing.

From the docs

In addition to allowing restricted pointers, you can specify restricted references, which indicate that the reference is not aliased in the local context.

void fn (int *__restrict__ rptr, int &__restrict__ rref)
{
/* ... */
}

In the body of fn, rptr points to an unaliased integer and rref refers to a (different) unaliased integer. You may also specify whether a member function's this pointer is unaliased by using __restrict__ as a member function qualifier.

void T::fn () __restrict__
{
/* ... */
}

Within the body of T::fn, this will have the effective definition T *__restrict__ const this. Notice that the interpretation of a __restrict__ member function qualifier is different to that of const or volatile qualifier, in that it is applied to the pointer rather than the object. This is consistent with other compilers which implement restricted pointers.

As with all outermost parameter qualifiers, __restrict__ is ignored in function definition matching. This means you only need to specify __restrict__ in a function definition, rather than in a function prototype as well.

Answer 2

Maybe i dont understand your question, but c restrict keyword was removed from STANDARD C++, but almost each compiler has their "C restrict" equivalents:

Microsoft VS has __declspec(restrict): https://msdn.microsoft.com/en-us/library/8bcxafdh.aspx

and GCC has __ restrict__ : https://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html

If you want a common definition you could use #define's

#if defined(_MSC_VER)
#define RESTRICT __declspec(restrict)
#else
#define RESTRICT __restrict__
#endif

I dont test it, let me know is that does not work

Answer 3

If we're only talking about pure C++ Standard solution, runtime check is the only way. I'm actually not even sure if this is possible given the strength in the definition of C's restrict lvalue qualifier, which is that the object can only be accessed by the restrict pointer.

Answer 4

The proper way to add restrict-like semantics to C++ would be to have the Standard define templates for restricted references and restricted pointers in such a way that dummy versions which work like ordinary references and pointers could be coded in C++. While it might be possible to generate templates which behave as required in all defined cases, and invoke UB in all cases which should not be defined, doing so will be useless if not counterproductive unless a compiler is programmed to exploit the UB in question to facilitate such optimizations. Programming a compiler to exploit such optimizations in cases where code uses a Standard-defined type that exists for that purpose is apt to be easier and more effective than trying to identify patterns within user types where it would be exploitable, and would also be less likely to have undesired side-effects.

Answer 5

I think that your solution doesn't fully achieve the intended goal even if the noted UB didn't exist. After all, all real data accesses occur on the built-in type level. If decltype(a->i) is int and your function manipulates int* pointers, then under certain circumstances the compiler should still assume that those pointers could alias a->i.

Example:

int func(noalias<S, 1> a) {
    int s = 0;
    int* p = getPtr();
    for ( int i = 0; i < 10; ++i ) {
        ++*p;
        s += a->i;
    }
    return s;
}

Usage of noalias will hardly enable optimizing above function to the following:

int func(noalias<S, 1> a) {
    *getPtr() += 10;
    return 10 * a->i;
}

My feeling is that restrict cannot be emulated, and must be supported by the compiler directly.