|
|
|
|
Sponsored Link •
|
We commenced our discussion by considering the "gotchas" of C++, the
annoyances, great and small, that pester us as we write code. We quickly
got minor irritants off our collective chest, such as the space required
between adjacent '>' characters in nested template definitions. Some
thought the bool-to-int conversions a little too
gratuitous, and would rather see them as more distinct types. One
developer even thought that the "= 0" suffix was too cryptic a way to tag
a function as pure virtual, which was one instance where copying Java
seemed like a good idea (by borrowing the abstract keyword).
We all pretty much agreed that old C-style casts should be abolished.
Weightier embarrassments that surfaced included
vector<bool> (because it fails to meet all requirements
of standard containers—but I think some people make a mountain out of this
molehill, since it is still quite useful in its own right), the difficulty
in and questionable utility of using export, binary
incompatibility issues, the apparent uselessness of exception
specifications as they're currently defined (I mean, who uses them,
really?), and the surprising pitfalls awaiting those who use
auto_ptr for anything other than a local or instance
variable.
The export issue will resolve itself, I believe, as
vendors develop more sophisticated implementations. So far only one
vendor has developed a solution, and it currently requires template source
code to be available at instantiation time, but a proprietary intermediate
code would work just as well and simultaneously keep confidential code
confidential (confidential enough, anyway). Certainly,
implementing export should be much more onerous than
actually using it. Most of these issues have long been with us and
are under consideration by our faithful standards committee
representatives. Many issues have already been solved by Boost and are
described in Bjorn Karlsson's upcoming book, Beyond the C++
Standard Library: An Introduction to Boost.
One particular issue related to templates is receiving lots of
attention: what to do with those nasty error messages! As we all know too
well, one typo or omission in user code can give rise to pages of
unintelligible diagnostics revealing something "amiss" deep in the bowels
of the standard library. No, it's not really an error in your compiler's
implementation—it's just that most of the library is
(non-exported) template code that gets compiled at the same
time your code does, and, alas, your code is guilty of Library Abuse.
Regardless of who's guilty, all that techno-gibberish doesn't help you
find your bug in linear time.
The first partial solution that appeared on the scene was Leor Zolman's STLFilt, a nifty little Perl-based utility (available for free) that screens out most of the cruft so you stand a chance of figuring out what's wrong. As it happens, the C++ standards committee is working on this big-time. The template concepts proposal from Bjarne and others researches ways of more completely specifying constraints on template parameter types so that error messages will point back directly to your code, as they should—not the library's. [Consider this an invitation for a qualified someone to write on article on same for TCS.]
But you don't have to wait for C++0x to make headway. Earlier in the day of our BoF, Bjarne showed how to specify constraints on template parameters with an example that looked something like the following:
#include <string>
using namespace std;
// A constraint class (inspects T for operations)
template<typename T>
struct Comparable {
static void constraint(T a, T b) {
// Exercise required operations (errors will point here)
(void)(a < b);
(void)(a <= b);
}
Comparable() {
// Force instantiation of static function above
void (*p)(T,T) = constraint;
}
};
// The template of interest
template<typename T>
class Subject : private Comparable<T>
{};
// A class that is not comparable
struct Foo{};
int main() {
Subject<int> s1;
Subject<string> s2;
Subject<Foo> s3; // Error
}
The goal in this example is to endow the Subject template
with logic that constrains its template parameter to types that support
the binary operators < and <=. These operators are used in the private
base class template, Comparable, which possesses two
important features:
Comparable::constraint, I mean).
Since Comparable::constraint will be instantiated, its
code will be checked by the compiler. If the argument passed to the
template parameter, T, does not have the required operators,
a compile error will point directly to the test expressions. Here's the
output from the Digital Mars compiler:
constraints.cpp(9) : Error: illegal operand types Had: Foo and: Foo constraints.cpp(10) : Error: illegal operand types Had: Foo and: Foo --- errorlevel 1
Lines 9 and 10—bingo! Type Foo does not support
< and <=.
Enough complaining. We asked our group what features they would like to see in C++'s next go-around and came up with the following list (in no particular order):
explicit to adorn conversion functions for
symmetry with explicit constructors
This is a respectable list, and many of the issues are either already resolved or under construction. At about the same time we were having our BoF, the standards committee's library group was building its own wish list. Here it is, as I received it from library group chair, Matt Austern:
cout << x should "just work" for such types.
filestream constructors)
filestreams
dynamic_any
time_t.
copy_if (duh!)
Okay, I added that last "duh!" It's a good sign that the two lists generously overlap. It's also a good thing that C++ is a language that can host all of these features. With all of its gaps and gotchas, the appeal of C++ is its power and flexibility. As Bjorn said in his aforementioned book, "It is amazing that a language as mature as C++ still offers room for exploration into higher-level abstractions as well as technical detail, all without requiring changes to the language." Even if we need a small language change or two, C++ is still amazing. For updates of the official C++ Library Wish List, click here.
So what's on your wish list? Post your comments in the
discussion forum for this article and we'll see that your input is
passed on to the standards powers that be.
Chuck Allison is the editor of The C++
Source. He has over 20 years of industrial software development
experience, and is currently a professor of Computer Science at Utah Valley State College. He was a
contributing member of the C++ Standards Committee throughout the 1990s
and designed std::bitset. He was a contributing editor for
the C/C++ Users Journal from 1992-2001 and Senior Editor from 2001-2003.
Chuck has been a regular lecturer at Software Development Conference for
over 10 years, and is author of C & C++ Code Capsules: A
Practitioner's Guide (Prentice-Hall, 1998), and co-author with Bruce
Eckel of Thinking in C++,
Volume 2: Practical Programming (Prentice-Hall, 2004). His company,
Fresh Sources, Inc., offers
training and mentoring in C++ and Java development.
|
Sponsored Links
|