An Editorial

---

C++ Reloaded As you know, C++0x, the next official version of our favorite programming language, is in the works. What changes are afoot? Will it have the features you need? Will it be easier to use? To answer some of these questions and more, Bruce Eckel and I hosted an evening Birds-of-a-Feather gathering at the Software Development Conference in Santa Clara, California, in March earlier this year. Bjarne Stroustrup was there to keep an eye on us (he and Herb were giving a "super tutorial" on future directions in C++ during the day).

Go Ahead, Vent a Little

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.

Tempest in a Template

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:

1. It has a static member function with expressions that exercise those operators, and
2. Its constructor stores (locally) a pointer to said function, which seems to be the cheapest way to force the compiler to instantiate it (the function 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 <=.

Making a List

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):

1. Delegating constructors, so one constructor can call another, without the user having to create separate, private functions
2. Allow explicit to adorn conversion functions for symmetry with explicit constructors
3. Lambda expressions
4. Thread support
5. PL/I-style arrays (like FORTRAN/C99 arrays and then some)
6. Support for distributed programming
7. Template aliases (what many of us call "template typedefs")
8. Smarter smart pointers (a la Boost)
9. A good XML API
10. A "for-each" iteration construct integrated into the language
11. Extended type information (as much runtime type information as possible for a compiled language)
12. Object serialization
13. Better range checking in standard library components

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:

C++0x Standard Library Wishlist

1. A simple and uniform display mechanism for arbitrary ordered lists (arrays, STL containers, pairs, tuples, etc.) cout << x should "just work" for such types.
2. An infinite-precision integer arithmetic class
3. String versions of all (or most) functions that take C-style strings (e.g. filestream constructors)
4. Simple functions for extracting integer and floating-point values out of a string and vice-versa
5. A threads library
6. A socket library
7. Explicit support for Unicode
8. An XML parser and generator library
9. An infinite-precision real number capability (Hans Boehm calls this "constructive reals," and he has implemented them for Java.)
10. Some form of simple graphic/GUI library (possibly a simple interface to the simpler parts of larger libraries)—a recurrent theme
11. A facility for random-access to files; maybe a form of random-access iterators for filestreams
12. A range-checked version of standard containers/iterators and algorithms
13. A way of manipulating files that are part of a directory structure
14. A good linear algebra library (Matrices and vectors)
15. Versions of the standard containers with virtual destructors
16. Move semantics, which requires core and library support
17. A string formatting library. (aka type-safe printf)
18. A container to hold anything, like dynamic_any
19. A date/time library (a date is not a duration!). And an end to time_t.
20. A graph library, aka Boost.Graph (to supplement standard containers)
21. Math/octonion & math/quaternions (used by game designers for 3d math)
22. A SI/Units library. (no more Mars Lander crashes!)
23. A new STL algorithm: 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.

Talk back!

Have an opinion? Readers have already posted 82 comments about this article. Why not add yours?

About the author

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.