- Consolidation: The Foundation for IT Business Transformation
- Build a Business Case: Developing Custom Apps
- SaaS and E-Discovery: Navigating Complex Waters
- SaaS 2011: Adoption Soars, Yet Deployment Concerns Linger
- New Technologies to Optimize Mobile Financial Services
- How to Transform Paper Insurance Documents into Digital Data
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.