Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼

Andrew Koenig

Dr. Dobb's Bloggers

The Solution to Last Week's Language-Design Puzzle

May 17, 2012

Last week, I asked a question about overloaded operators that I can summarize as follows:

struct Thing {
void operator+(std::string);
struct Blob: Thing { };
void operator+(Thing&, const char*);
Thing t;
Blob b;
t + "s";   // OK – calls nonmember
b + "s";   // What does this do?

The first of the two commented expressions, t+"s", might mean either t.operator+("s") or operator+(t, "s"). The first of these meanings requires converting "s" to type std::string; the second requires no conversions. As a result, the second meaning is clearly a better match for the expression, so that's the one the compiler uses.

The second commented expression, b+"s", is more interesting. Analogously to the first, it might mean b.operator+("s") or operator+(b, "s"). This time, however, the call to operator+(b, "s") requires converting b from Blob& to Thing&. If operator+ is an ordinary member of Blob by inheritance, then the call is ambiguous: One alternative requires a conversion on the first argument; the other requires a conversion on the second argument.

Here is how a language designer might think about the situation. Language designers try to define general rules from which specific language behaviors follow. One such rule might be that when we derive one class from another, the members of the base class become members of the derived class. Another such rule might be that if the derived class does nothing to change the behavior of the base class, the derived class should behave as much as possible like the base class.

What this example shows is that these two general rules conflict: They cannot both be universally true at the same time. As a result, one of them must give way to the other. One of the hard parts of language design is to figure out which rule should take precedence in cases such as this.

The key to this particular example is in what happens if we call b.operator+("s"). In particular, while the member operator+ is executing, the this pointer will have type Thing*, not Blob*. This observation leads to the following subtle language rule:

Calling a base-class member of a derived-class object
 counts as a conversion from Derived& to Base&
 for the purpose of resolving overloaded operators.

With this rule, the call to b.operator+("s") converts the "first argument" (i.e., the expression b) from Blob& to Thing&, and converts the second argument from const char* to std::string. The call to operator+(b, "s") also converts the first argument to Thing&, but does not convert the second argument at all. Therefore, operator+(b, "s") wins.

I would guess that most C++ programmers are not consciously aware of this language rule. However, if the rule were not there, most programmers would notice its absence because of anomalies such as this example. Such anomalies, and design strategies for avoiding them, are among the many reasons that programming-language design is harder than it looks.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.