39

The title says it all. I am curious why is the restrict keyword not part of C++ ? I don't know much about C++, and I'm still not able to find anything online that would give a reason blocking this. Does anyone know what terrible things would happen, if a C++ standard would use this keyword similarly to the way C does? Is it just not needed at all?

More explanation: It is not about using it, perhaps I will not have any benefit from this keyword in my whole life. This question is only about curiosity, since restrict is part of C since C99, that is 15 years.

Read this as well: I'm interested in technical reasons, not opinions like "They just didn't like, it is not cool enough"

Deduplicator
  • 43,322
  • 6
  • 62
  • 109
Gábor Buella
  • 1,712
  • 13
  • 19
  • Note that at least MSVC, gcc and Intel's compiler support `restrict` (or variations, like `__restrict`) for c++, so in practice this is not that big a deal. – Alexandre C. Mar 28 '14 at 23:53
  • 1
    This question asks for opinions about something that is not real problem, and therefore it's not an appropriate question for Stack Overflow. – Dialecticus Mar 28 '14 at 23:53
  • My guess: They just didn't like it and thought they had the perfect "sufficiently smart compiler" to figure it all out on its own. – Deduplicator Mar 28 '14 at 23:56
  • 12
    @Dialecticus This question basically asks for technical reasons. I don't expect answers like "because restrict is stupid", I would like answers like "it conflicts with this and that". Should I modify the question according to this? – Gábor Buella Mar 28 '14 at 23:56
  • 3
    Buella, you may be interested in N3635 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3635.pdf and other results of googling "site:www.open-std.org/jtc1/sc22/wg21/ restrict" – osgx Mar 29 '14 at 00:04
  • @BuellaGábor Could you specify any references, or at least elaborate regarding `restrict` and c++? I don't get what's your question's all about ... – πάντα ῥεῖ Mar 29 '14 at 00:07
  • 1
    @πάνταῥεῖ http://en.wikipedia.org/wiki/Restrict – Gábor Buella Mar 29 '14 at 00:16
  • The question is probably more appropriate to programmers.stackexchange.com – mjhm Mar 29 '14 at 02:32

2 Answers2

22

There are several issues in defining "restrict" in C++, some of them are listed in WG paper N3635: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3635.pdf "Towards restrict-like semantics for C++"

Some possible issues with restrict in C++ are:

  • Restrict Class members and indirection with “this pointer”
  • Passing of restrict qualifiers into functions, functors, lambdas, and templates
  • Escaping of restrict pointer values inside functions
  • Overlapping array members, strides

Document also list several C++ compilers with limited "restrict" support for C++.

There is also interesting history note in N3635 about non-inclusion of restrict to C++:

At the time of reviewing C99 feature inclusion in C++ during the Mont Tremblant meeting, restrict was considered but was waiting a paper proposal although none came forward....

Restrict is a C99 feature and was never designed to work in class abstractions and it may have to do with that pointers are not common in C++. ... it was designed for fine-grain aliasing for C, but not well-designed for type-based aliasing in C++

osgx
  • 85,909
  • 48
  • 329
  • 491
  • 3
    Thanks, this paper is something I was looking for. I just had no idea I need to google `site:www.open-std.org/jtc1/sc22/wg21/ restrict`. Next time I will know.. – Gábor Buella Mar 29 '14 at 00:18
  • 2
    "Pointers not common in C++"? I wonder they got that notion... :-( – einpoklum Mar 07 '16 at 17:49
  • I would be OK with the idea that restrict could only be applied to function argument pointers could only exist on the stack and could only refer to standard layout POD types. The that first *ahem* restriction is a novel category for C++, and the second category (standard layout POD) has generally not affected the ability to use language keywords. So, maybe my idea is a bad one. – Omnifarious Jun 25 '18 at 14:49
  • @Omnifarious: For C++, I think it might be better to have a "memory window" object type whose constructor would take a pointer,, and which would be used like a pointer, but with semantics that during the lifetime of the memory window, accesses made via the window or pointers that are definitely linearly derived therefrom would be unsequenced relative to accesses made via pointers that are definitely not linearly derived therefrom. Such an object could also allow a practical and convenient means of type punning if a pointer of one type could be used to form a window of another. – supercat May 23 '22 at 21:40
  • @Omnifarious: A compiler would have to ensure that any pending operations on the original type that occurred before the constructor was run would be sequenced before any operations using the window, and any operations using the window would be sequenced before any operations on the original memory type that follow its destruction, but a compiler could be agnostic to the possibility of cross-type aliasing within the lifetime of the window provided those conditions were met. – supercat May 23 '22 at 21:42
8

Not to detract from osgx's answer, but - there is a somewhat more up-to-date paper, N3998 by Finkel, Tong, Carrouth, Nelson Vandevoode and Wong, from May 2014:

Towards restrict-like aliasing semantics for C++

And an ever newer one from 2018:

[[assert: std::disjoint(A,nA, B,nB)]]: Contract assertions as an alternate spelling of ‘restrict’

(Thanks @MCCCS for pointing the last one out.)

Community
  • 1
  • 1
einpoklum
  • 102,731
  • 48
  • 279
  • 553