Dr. Dobb's Journal - February 2008 - (Page 67)

d02mila_p5ma 12/7/07 3:30 PM Page 67 confident that build problems should not arise for library users. This is a reasonabe assumption of developers who create libraries for C, Pascal, Fortran, or other languages according to the interfacing standards. In fact, even in those languages, there can be problems regarding name collisions. With C++, these problems are avoided by using namespaces. Nonetheless, some complications arise in C++, mainly due to templates and overloaded functions. Overloaded Functions 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. Function Templates and Class Templates In addition to being able to create function libraries and class libraries with C++, you can create libraries containing function templates and class templates, leaving the task of instantiating such templates to the application program. Often, the actual template instantiation parameters are not foreseeable by the library developers. They can only specify in the documentation that those parameters must satisfy certain requisites. If the templates are instantiated with parameters that do not respect those requisites, the compiler emits error messages. For example, the Standard Library contains the function templates min and max, and the class templates vector and list. The function template min can be instantiated with a numeric type or with the string type, but not with the complex type, for any T. The class template vector can be instantiated with any type if the only goal is to create an empty collection. However, if you want to call the resize member function of that collection, the element type must have a default public constructor or no constructor at all. vide for application programmers, but also the programming errors that you want to prevent. Actually, sometimes the purpose of a specific feature of a library is not so much to provide a functionality to users as it is to prevent programming errors by forbidding error-prone operations. For example, a time instant and a time span are different kinds of entities. You can add two time spans and you can multiply a time span by a number. However, you cannot add two time instants nor multiply a time instant by a number. You can subtract a time instant from another time instant, obtaining the time span between them, and you can sum a time span to a time instant, obtaining another time instant, following the former by that time span. If a library defines a class for time instants and another class for time spans, it should allow only the operations that make sense for every class. The application code that would contain disallowed operations shouldn’t be accepted by a compiler. The most advanced and sophisticated C++ libraries define recursive templates in a programming style called “template metaprogramming.” In this context, a logical programming error (almost) always generates a compilation error. In general, the wrong usage of forbidden expressions should, if possible, result in compile-time errors. To this purpose, some libraries (Boost and Loki, for instance) have defined macros to declare compile-time assertions. If a program using the Loki library contains the statement STATIC_CHECK(3 == 4) when it is compiled, an error is generated. The same happens if a program using the Boost libraries and containing the statement BOOST_STATIC_ASSERT(3 == 4) is compiled. Such statements, similar to the assert macro from the C Standard Library, allow the compiler to analyze a constant expression, and if the expression comes out as false, they generate a compile-time error. Libraries as Abstractions: Avoiding Errors When designing a library, you should consider not only the features you want to pro- Static Testing Programs The assert macro is useless in production code. In fact, in addition to being valuable for internal documentation, its main purpose is 67 February 2008 l www.ddj.com l Dr. Dobb’s Journal http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - February 2008

Dr. Dobb's Journal - February 2008 Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook South American Software Development Conversations Inside Visual Studio 2008 BibPort: Creating Bibliographic References Continuous LINQ The ZK Framework Static Testing C++ Code The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - February 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.