C++ Extensions: Rich Pointers

mikhailberis

Home

Syndication

Archives

Some time towards the end of 2011 I officially became a member of the ISO C++ Committee as part of Google's delegation. Around the same time I wrote about a few extensions to C++ that I wanted to propose or at least help champion to the next version of C++. The Kona meeting is just around the corner and I'm just about ready to make a case for a specific new extension to C++ that I wrote a paper about called rich pointers. This post is about the motivations behind the extension.

It's 2012 and I've pretty much started it off with a very ambitious project: to add a new pointer type to C++ with something called "rich pointers". This project aims to achieve the following:

Define a new pointer type that conveys semantics different from the primitive pointers inherited from C.
Associates an object's type to the pointer instead of the object.
Provide a richer reflection and runtime introspection facility for C++ types referred through rich pointers.
Attempts to standardize a runtime interface for managing types and these rich pointers.

Here are a few motivating examples for why a new pointer type would be required instead of shoehorning the reflection information into current RTTI implementations.

Suppose we want to implement serialization on any type of object that has a member function called "serialize", how would we do this from a function that's provided through a DLL?
We're implementing a distributed service and we'd like to use Google Protocol Buffers as the data interchange object but also want to render the information using the Qt GUI framework on the client side. How do we do this with as little overhead as possible and without having to adapt the type of the protocol buffer into something that the Qt GUI framework will understand?
Let's say we want a generic registry of handlers implemented as dynamically linked modules for a server application and we want to minimize the requirement for downtime of the application as we add new functionality to it. How do we ensure that the new types introduced in the dynamically linked modules are dealt with accordingly by the server application?
Suppose we're hosting a just-in-time (JIT) compiler that can compile C++ code in a long-running application. We're doing this so that we can reprogram parts of the application according to runtime constraints/inputs (imagine a query optimizer for SQL databases or for regular expressions) for efficiency concerns. How do we allow the new types defined in the runtime-compiled C++ code to be used in the host application in a type-safe manner?

These are just a number of real-world requirements that rich pointers intends to address and enable in a standardized manner. To get this done I'd have to convince the committee that:

Adding a new pointer type unique to C++ and having rich runtime type information is necessary to enable seamless solutions for these kinds of problems.
Requiring the compiler to generate type information for types referred to via rich pointers is doable and will not lead to overly bloated binaries.
Attaching type information to a pointer instead of the object makes sense.
Current RTTI mechanisms are inadequate to achieve this kind of reflection and runtime type introspection.
Implementing this feature will not require too much heavy lifting for implementors.

This paper also implies and relies on the following being true:

That C++ modules will define how dynamically and statically shared C++ libraries will be defined (maintaining backward compatibility to existing linkers).
That the committee will agree to have a standardized API for accessing details about an application's runtime (for type registration, function registration, certain system characteristics of the machine and implementation, etc.).
Runtime introspection is something we'd like to support at the language level because everyone else who needs this functionality has implemented a library that provides this feature in an inadequate and clumsy manner.

In the coming days I will be updating the post with a link to the actual document hosted in the ISO C++ Committee mailings page. I certainly look forward to shedding more details about this project and update everyone of the progress of this proposal and perhaps post some insider notes about the upcoming meeting in Kona, Hawaii.

Thank you and I do hope to be able to give more details soon.