- The Role of the WAN in Your Hybrid Cloud
- Book Expert: Advanced Analytics with Spark: Patterns for Learning Data at Scale
- Real results: Speeding quality application delivery with DevOps [in financial services]
- IT and LOB Win When Your Business Adopts Flexible Social Cloud Collaboration Tools
In C++, there can be several functions with the same namethe "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
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.