Channels ▼


Static Testing C++ Code

Overloaded Functions

More Insights

White Papers

More >>


More >>


More >>

In C++, there can be several functions with the same name—the "overloaded" functions. For example, the Standard Library contains the functions double pow(double, double) and float pow(float, float), in addition to other overloaded versions. The first function performs the exponentiation of a double number by a double exponent; the second version does the same operation, but with a float base and a float exponent.

The expression pow(3., 4.) invokes the function double pow(double, double), while the expression pow(3.f, 4.f) invokes the function float pow(float, float).

Yet, the expression pow(3., 4.f) is illegal, as is the expression pow(3.f , 4.), because such expressions are considered ambiguous by the compiler. The ambiguity comes from the fact that there is no overloaded version exactly matching, and the attempt to implicitly convert the parameters to match an existing overloaded version leads to several existing overloaded functions, and the compiler can't decide among the candidate versions.

The rules to bind a function call to the corresponding overloaded function are rather complex, and the situation is often complicated further by implicit conversions. Actually, a constructor that gets only one parameter and that is not preceded by the implicit keyword lets the compiler perform an implicit conversion from the parameter type to the type of the class containing that constructor. A type-conversion operator lets the compiler perform an implicit conversion from the class containing that operator to the type declared as operator.

With such grammar, it's sometimes difficult for programmers to forecast which function will be chosen by the compiler when compiling a function call expression, or if the compiler will surrender at an ambiguous expression.

Although the ambiguity lies in the application code, not in the library code, a good library should be designed so that it is unlikely that typical application code will be ambiguous.

Therefore, there is a need to test the usability of a library, checking that unreasonable usage is forbidden and reasonable usage is allowed. This can be done by preparing a series of typical uses of the library, some reasonable and others unreasonable, and to verify that every reasonable use of the library can be compiled and every unreasonable usage is spotted by the compiler as an error.

Related Reading

Currently we allow the following HTML tags in comments:

Single tags


<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags


<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

