What is a traceable pointer in C++?

Question

Trying to understand clause 20 in ISO Standard c++:

Change: Minimal support for garbage-collected regions.

Rationale: Required by new feature.

Effect on original feature: Valid C++ 2003 code, compiled without traceable pointer support, that interacts with newer C++ code using regions declared reachable may have different runtime behavior.

https://timsong-cpp.github.io/cppwp/n4618/diff.cpp03.utilities

What is a traceable pointer (not a traceable pointer object)? What is the difference between a traceable pointer and a normal pointer?

Answer 1

There doesn't seem to be a definition of the term traceable pointer in the C++ standard. That is, it is almost certainly referring to a traceable pointer object. You can raise a defect to get things corrected, i.e., either have the wording amended to define traceable pointer or to refer to traceable pointer object. As Annex C doesn't have mandatory impact on the standard, I'd guess it would get editorially fixed. The garbage collection support is also a section which isn't super popular as people like to play tricks with pointers and, e.g., use unused bits to store information.

Semantically, traceable object pointers is what is needed for the minimal garbage collection support. The key idea is that pointer values can't be "hidden", i.e., have their bit pattern modified, and can be identified by a garbage collect and objects which aren't referenced that way may get collected. The definitions constrain, e.g., the portability of the doubly linked list implementation using one pointer to store the XORed pointers to the previous and next node whose traversal depends on knowing the node you are coming from and the current node to move to the next node: the XORed value is not a safely-derived pointer. Likewise, I think setting bits which are known to be zero due to alignment constraints or because only some of the bits in a pointer are used for addresses (e.g., 48 bits out of the 64 bit pointer value) wouldn't necessarily be portable.

The functions in section 20 are used to declare additional "root" objects so the garbage collector doesn't reuse memory of objects which are somehow considered to be alive although the C++ implementation itself doesn't know how to arrive at them. For example, you could declare pointers to be reachable before storing their values into a file which is then later read again to recover their location.

Of course, C++ doesn't have mandatory garbage collection. There exist custom garbage collectors for C++, though. Even in programs written to not require a garbage collector a garbage collector could be interesting to locate memory leaks.