— John Cleese
As so often in life, people love to do the exact opposite of what you advise. In my previous post I claimed that the ‘restrict’ feature isn’t that all-important and guess what? I received questions on whether it was possible to achieve the (promised) effects of ‘restrict’ even if a particular C dialect doesn’t support it (in case you are using C++ or some C version predating C99, for example).
YES WE CAN!
We just need to creatively combine the wisdom from the previous “Pointers in C” installments. In particular:
- Pointer access involving multiple pointers can be optimized if the pointers point to incompatible types.
- structs with different tag names constitute different, incompatible types, regardless of whether the struct members are identical or not.
- A pointer can be converted to a pointer to a different type as long as the resulting pointer is suitably aligned for the target type.
- A pointer to struct points to its initial member.
Do you ‘C’ it?
SPOILER ALERT!
Again, I use the ‘silly’ example to demonstrate the technique. The idea is to wrap the original types (‘int’) in structs with different tag names thus yielding different (incompatible) types:
|
1 2 3 4 5 6 7 8 9 10 |
struct intx { int value; }; struct inty { int value; }; int silly4(struct intx* x, struct inty* y) { x->value = 0; y->value = 1; return x->value; } |
Believe it or not — it works:
|
1 2 3 |
gcc -O2 -std=c89 silly4.c -masm=intel -S && cat silly4.s |
|
1 2 3 4 5 6 7 |
silly4: mov DWORD PTR [rdi], 0 mov DWORD PTR [rsi], 1 xor eax, eax ret |
Why? To the compiler, the pointer types are different (item 2) and hence it doesn’t assume that they point to the same memory (item 1). Because of item 3 and 4 in the list above, the calling code can still pass plain ‘int’ arrays/pointers, just like in the original code. However, nasty casts are required when calling ‘silly4’ from C++ code:
|
1 2 3 4 |
int a, b; assert(0 == silly4((struct intx*)(&a), (struct inty*)(&b))) |
Contrary to C++, C is only weakly typed so such casts are not necessary officially, unless you want to get rid of compiler warnings, which you always want to, don’t you?
You could argue that these strange ‘struct int’ pointers that are used in the signature of ‘silly4’ kind of document the fact that the passed pointers are “restricted” and mustn’t overlap. However, I prefer to keep the original ‘int*’ interface and hide this struct business from callers altogether:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
// silly5.h #if __STDC_VERSION__ >= 199901L /* >= C99 */ #define RESTRICT restrict #else /* pre-C99 or C++ */ #define RESTRICT /* just for documentation purposes. */ #endif // silly5.c int silly5(int* RESTRICT x, int* RESTRICT y) { struct intx { int value; }; struct inty { int value; }; struct intx* px = (struct intx*)x; struct inty* py = (struct inty*)y; px->value = 0; py->value = 1; return px->value; } |
The generated code is identical to the one derived from ‘silly4’.
I still stick with my original recommendation that the ‘restrict’ feature is not that useful as it’s a legally binding contract for the caller while the compiler is free to ignore this plea for performance. If you want to use ‘restrict’ regardless of my advice, even if your compiler doesn’t support it, you now know how to emulate it in a portable fashion.