Over the years, there have been several suggestions and proposals for allowing programmers to define operator.() so as to be able to provide “smart references” similar to the way we provide “smart pointers.” I first considered that in 1983, but couldn’t solve the problem. In early 2014, Gabriel Dos Reis and I decided that now we really had to solve it: Too much code was getting too complicated and too ugly because of the lack of smart references. Operator -> is good for objects with pointer semantics, but we needed a general way of providing value semantics for a handle.
Operator dot differs from other operators by having its right-hand operand be a name rather than a value: for x.m, m is not the value of some variable it is the name of a member of some class. Ideally, dot would be a binary operator taking into account both x and m for x.m. Many have tried, including Gaby and I, but that quickly gets complicated. The current rules for operator->() and the proposed design for operator.() “solves” those problems by considering the right-hand operand only when looking for possible candidates. This allows composition of interfaces without requiring inheritance. If someone figures out a good and simple way of taking the member name into account in a more general form, we are reasonably sure that we have not proposed anything that prevents that. When designing, you must always try to avoid painting yourself into a corner by closing off possible evolution paths.
Historically, the key sticking point with the operator.() proposals has been how to distinguish operations on the reference object (the handle) from operations on the referred-to object (the value). The current proposal “forwards” every operation to the referred-to object unless that operation has been explicitly declared in the handle. This is simple and quite general. In particular, we can apply operators on a smart reference (e.g., ++r) and have ++ apply to reference is we so desire, but by default it is applied to the referred-to object (as it would for a built-in reference). The papers outline why we think that this is – by far – the design that best balances the needs of the various use cases. The focus is on allowing the user to define a class that is a reference, just like the built-in reference, except that it is “smart” in some way (e.g., it can have a rebind() member) analogously to the way a “smart pointer” is just like a pointer except that it is “smart” in some way (e.g., takes care of ownership). If you can define or use a smart pointer, you can define or use a smart reference.
The proposal has been quite stable. There have been proposals for alternatives and major extensions, but few suggested modifications. We tried to find a way to prevent a pointer (or reference) to the referred-to object to escape from the smart reference, but couldn’t find a simple way of guaranteeing that so we gave up, quoting “C++ protects against Murphy, not Machiavelli.” We ensured that you can define a matching set of smart . (dot), -> (arrow), * (dereference), and [] (subscript) operators with the relations they have for built-in types.
- James Adcock: Request for Consideration – Overloadable Unary operator.().
- Koenig and B. Stroustrup: Analysis of Overloaded operator.().
- G. Powell, D. Gregor, and J. Jarvi: Overloading Operator.() & Operator.*().
- B. Stroustrup: The Design and Evolution of C++. Addison-Wesley, 1994.
- B. Stroustrup and G. Dos Reis: Operator Dot (R2).
- Bjarne Stroustrup and Gabriel Dos Reis: Operator Dot Wording.
Add a Comment
Comments are closed.