This paper briefly outlines the guiding principles of the work on C++0x, presents a few examples of likely language extensions, and lists some proposed new standard libraries.
[Note: This paper was first presented to the "Modern C++ Design & Programming" conference in Shanghai, November 18, 2005]
Guiding Principles
C++ is a general-purpose programming language with a bias towards systems programming that:- is a better C
- supports data abstraction
- supports object-oriented programming
- supports generic programming
By "systems programming", I mean programming the kind of tasks traditionally associated with the operating system and fundamental tools. This includes the operating system kernel, device drivers, system utilities, networking, word processing tools, compilers, some kinds of graphics and GUI, database systems, games engines, CAD/CAM, telecommunications systems, etc. This kind of work is strongly represented among current C++ users. For example, see my "applications" page: http://www.research.att.com/~bs/applications.html.
The aim of C++0x is for that characterization above to remain true. It is not an aim to eliminate one of those styles (or "paradigms"; e.g. to make C++ less compatible with C) or to add a radically new paradigm. The most effective styles of programming use a combination of these techniques. Using these techniques in concert is often called "multi-paradigm programming," so we can say that we want to improve C++ as a multi-paradigm programming language.
The high level aims for the language part of C++0x are to:
- Make C++ a better language for systems programming and library building
- Rather than providing specialized facilities for a particular sub-community (e.g., numeric computation or Windows-style application development)
- Make C++ easier to teach and learn
- Through increased uniformity, stronger guarantees, and facilities supportive of novices
In other words, C++0x should be better than C++98 where C++98 is already strong—and maybe in a few more areas that are natural generalizations of what C++98 supports. When it comes to supporting specialized application areas, such as numeric computation, Windows-style application development, and embedded systems programming, C++0x will rely on libraries. The efficiency of the basic language features (such as, stack-allocated objects and pointers) plus the generality and flexibility of its abstraction mechanisms (such as classes and templates) make the use of libraries attractive in an incredibly broad set of application areas and reduce the need for new language features.
We cannot make the language simpler to teach and learn by removing features. Stability and compatibility are major concerns, so eliminating anything of importance (in any way) is not an option (and eliminating something of no importance would not be a help). This leaves us with the options of generalizing rules and adding easier-to-use features. We aim at both, but the latter is easier. For example, better library facilities, such as containers and algorithms, save users from some of the problems associated with lower-level facilities like arrays and pointers. Language facilities that simplify the definition and use of libraries (such as concepts and generalized initializer lists—see below) will therefore contribute to the ease of use of C++0x.
Some people object: "Don't dumb-down C++ for novices—there are languages enough for those", or "The sooner novices become experts the better!" These people have a point, but there will always be more novices than experts. Many C++ users quite reasonably don't want to become C++ experts—they are experts in their own fields (e.g., physicists, graphics specialists, or hardware engineers) who use C++. In my opinion, C++ has become too "expert friendly" and it will cost us little to provide much better support for "novices". It will cost us nothing in terms of performance (the zero-overhead principle still holds), in flexibility (we don't propose to prohibit anything), or in terseness of code. On the contrary, we aim to simplify expression of ideas. Finally, C++ is so large, is used in so many application areas, and there are so many useful C++ design techniques, that we are all "novices" much of the time.
The C++0x improvements should be done in such a way that the resulting language is easier to learn and use. Among the rules of thumb for the committee are:
- Provide stability and compatibility (with C++98, and, if possible, with C)
- Prefer standard library facilities to language extensions
- Make only changes that change the way people think
- Prefer generality to specialization
- Support both experts and novices
- Increase type safety (by providing safe alternatives to currently unsafe facilities)
- Improve performance and ability to work directly with hardware
- Fit into the real world
We try to focus on extensions that "change the way people think" because that way we gain the greatest benefits for our efforts. Every change has a cost in terms of implementation, learning, etc., and the cost of a change does not always directly relate to its benefits. The major advances/benefits do not come from improving the way a programmer writes an individual line of code, but from improving the way a programmer solves problems and organizes programs. Object-oriented programming and generic programming have changed the way many people think—and that was the purpose of the C++ language facilities supporting those styles. Thus, the best use of our time as language and library designers is to work on facilities and techniques that help change the way people think.
Please note the last rule, "Fit into the real world". As usual for C++, the aim is not to create the most beautiful language—though we all prefer elegance when we can get it—but to provide the most useful language. This implies that compatibility, performance, ease of learning, and interoperability with other systems and languages are serious interrelated concerns.
Language Features
Let�s see how code using new C++0x features might look:
template<class T> using Vec = vector<T,My_alloc<T>>;
Vec<double> v = { 2.3, 1.2, 6.7, 4.5 };
sort(v);
for(auto p = v.begin(); p!=v.end(); ++p)
cout << *p << endl;
Each line except the last is illegal in C++98, and in C++98 we�d have to write more (error-prone) code to get the work done. I hope you can guess the meaning of this code without explanation, but let�s look each line individually.
template<class T> using Vec = vector<T,My_alloc<T>>;Here, we define
Vec<T> to be an alias of
vector<T,My_alloc<T>>. That is, we define a vector called
Vec that works exactly like
vector except that it uses my allocator (
My_alloc) rather than the default allocator. The ability to define such aliases and to bind some but not all parameters of a template has been missing from C++. It has traditionally been referred to as a "template typedefs" because
typedef is what we typically use for defining type aliases, but for technical reasons, we preferred
using. One advantage of this syntax is that it introduces the name being defined where it is easy for the human reader to spot. Note also another detail. I didn�t write
template<class T> using Vec = vector< T,My_alloc<T> >;It will no longer be necessary to add that space between the terminating >'s. These two extensions have already been accepted in principle.
Next we define and initialize a Vec:
Vec<double> v = { 2.3, 1.2, 6.7, 4.5 };
Initializing a user-defined container (
vector<double,My_allocator<double>>) with an initializer list is new. In C++98, we can only use such initializer lists for aggregates (arrays and classic
structs). Exactly how this extension will be achieved is still being discussed, but the solution will most likely involve a new kind of constructor—a "sequence constructor". Allowing the above implies that C++ better meets one of its fundamental design criteria: support user-defined and built-in types equally well. In C++98 arrays have a notational advantage over
vectors. In C++0x, that will no longer be the case.
sort(v);To do that within the framework of the STL we must overload
sort for containers and for iterators. For example:
template<Container C> // sort container using <
void sort(C& c);
template<Container C, Predicate Cmp> // sort container using Cmp
where Can_call_with<Cmp,typename C::value_type>
void sort(C& c, Cmp less);
template<Random_access_iterator Ran> // sort sequence using <
void sort(Ran first, Ran last);
template<Random_access_iterator Ran, Predicate Cmp> // sort sequence using Cmp
where Can_call_with<Cmp,typename Ran::value_type>
void sort(Ran first, Ran last, Cmp less);
This illustrates the most significant proposed C++0x language extension that is likely to be accepted:
concepts. Basically, a concept is the type of a type; it specifies the
properties required of a type. In this case, the concept
Container is used to specify that the two first versions of
sort need an argument that meets the standard library container requirements. The
where-clauses are used to specify the required relationship between the template arguments: that the predicates can be applied to the containers' element types. Given concepts we can provide far better error messages than is currently possible and distinguish between templates taking the same number of arguments, such as
sort(v, Case_insensitive_less()); // container and predicateand
sort(v.begin(), v.end()); // two random access iteratorsThe difficulty in the design of �concept� is to maintain the flexibility of templates so that we don�t require template arguments to fit into class hierarchies or require all operations to be accessed through virtual functions (as for Java and C# generics). In �generics�, an argument must be of a class derived from an interface (the C++ equivalent to �interface� is �abstract class�) specified in the definition of the generic. That means that all generic argument types must fit into a hierarchy. That imposes unnecessary constraints on designs requires unreasonable foresight on the part of developers. For example, if you write a generic and I define a class, people can't use my class as an argument to your generic unless I knew about the interface you specified and had derived my class from it. That's rigid.
There are workarounds, of course, but they complicate code. Another problem is that you cannot use built-in types directly with generics, because built-in types, such as int, are not classes and don't have the functions required by interfaces specified by a generic—you then have to make wrapper classes for holding built-in types and access elements indirectly through pointers. Also, the typical operation on a generic is implemented as a virtual function call. That can be very expensive (compared to just using a simple built-in operation, such as + or <). Implemented that way, generics are simply syntactic sugar for abstract classes.
Given "concepts", templates will retain their flexibility and performance. There is still much work left before the committee can accept a specific and detailed concept design. However, concepts are a most likely extension because they promise significantly better type checking, much better error messages, and greater expressive power. That should lead to significantly better library interfaces, starting with the current standard containers, iterators, and algorithms.
Finally, consider the last line that outputs the elements of our vector:
for (auto p = v.begin(); p!=v.end(); ++p)
cout << *p << endl;
The difference from C++98 here is that we don�t have to mention the type of the iterator:
auto means �deduce the type of the declared variable from the initializer�. Such uses of
auto are far less verbose and also less error-prone than current alternatives, such as:
for (vector< double, My_alloc<double> >::const_iterator p = v.begin(); p!=v.end(); ++p)
cout << *p << endl;
The new language features mentioned here are all aimed at simplifying generic programming. The reason is that generic programming has become so popular that it is seriously strains the language facilities. Many �modern� generic programming techniques border on �write only� techniques and threaten to isolate its users. To make generic programming mainstream, as object-oriented programming was made mainstream, we must make template code easier to read, write, and use. Many current uses are too clever for their own good. Good code is simple (relative to what it is trying to do), easy to check, and easy to optimize (i.e., efficient). This implies that a wide range of simple ideas can be expressed simply in C++0x and that the resulting code is uncompromisingly efficient. The former is not the case in C++98—at least not for a sufficiently large range of techniques relying on templates. Better type checking and more extensive use of type information to shorten code will make code shorter and clearer, and easier to maintain, as well as more likely to be correct.
Library Facilities
Ideally, we�d leave the C++ language mostly unchanged and focus on adding standard libraries. However, libraries that are sufficiently general to be standard are not easy to design and the standards committee is—as usual—short of resources. We are a relatively small group of volunteers and all have �day jobs�. This puts unfortunate limits on how adventurous we can be with new libraries. On the other hand, the committee started early and a technical report on libraries ("The Library TR") was recently approved by vote. It provides several facilities that are directly useful to programmers:- Hash Tables
- Regular Expressions
- General Purpose Smart Pointers
- Extensible Random Number Facility
- Mathematical Special Functions
unordered_maps) available. In addition, the Library TR provides extensive facilities for builders of generic libraries building on the STL:
- Polymorphic Function Object Wrapper
- Tuple Types
- Type Traits
- Enhanced Member Pointer Adaptor
- Reference Wrapper
- Uniform Method for Computing Function Object Return Types
- Enhanced Binder
The list of proposals is still quite modest and not anywhere as ambitious as I�d like. However, more proposals from the committee's large backlog of suggestions are being considered and more libraries will appear either as part of the C++0x standard itself or as further committee technical reports. Unfortunately, lack of resources (time, money, skills, people, etc.) will continue to limit progress in this direction. Sadly, I cannot offer hope for the most frequently wished for new standard library: a standard GUI library. A GUI library is simply too large a task for the volunteers of the C++ standards committee to handle and too difficult a task given the many (non-standard but huge, useful, and supported) GUI libraries available. Please notice that even though they are not standard, the major C++ GUIs have more users than most programming languages and are often better supported.
In addition to these general-purpose libraries, the committee presented a library interface to the most basic level of hardware in its �Performance TR�. That TR is primarily aimed to help embedded systems programmers and to disprove myths about poor performance of C++ code and about C++ being unsuitable for low-level tasks.
Putting It All Together
�Drawing all shapes in an array� is a classical example of object-oriented programming (going back to the early Simula days). Using generic programming, we can generalize that to drawing each element of any container holding (pointers to) shapes:
template<Container C>
void draw_all(C& c)
where Usable_as<typename C::value_type,Shape*>
{
for_each(c, mem_fun(&Shape::draw));
}
In C++0x, we hope to have
Container as a standard concept and
Usable_as as a standard predicate. The
for_each algorithm is already in C++98, but the version that takes a container (rather than a pair of iterators) will have to wait for concepts in C++0x. The
where-clause is a mechanism through which an algorithm can express requirements on its arguments. Here,
draw_all() requires (obviously) that the elements of the container must be usable as (implicitly convertible to)
Shape*. In this case, the where-clause gives us a degree of flexibility/generality not offered by simply requiring a container of
Shape*'s. In addition to any container of
Shape*'s, we can use any container with elements that can be used as
Shape*'s, such as a
list<shared_ptr<Shape*>> (where
shared_ptr is a likely C++0x standard library class) or a container of pointers to a class derived from
Shape*, such as
deque<Circle*>.
Assuming that we have points p1, p2, and p3, we can test draw_all() like this
vector<Shape*> v = {
new Circle(p1,20),
new Triangle(p1,p2,p3),
new Rectangle(p3,30,20)
};
draw_all(v);
list<shared_ptr<Shape*>> v2 = {
new Circle(p1,20),
new Triangle(p1,p2,p3),
new Rectangle(p3,30,20)
};
draw_all(v2);
The "draw all shapes" example is important because when you can do that well, you can do much of what�s key to object-oriented programming. As written here, the example demonstrates the power of multi-paradigm programming by also employing generic programming (concepts and templates), conventional programming (e.g. the free-standing standard-library function
mem_fun()), and simple data abstraction (the function object returned by
mem_fun()). Thus, this simple example opens the door to a host of elegant and efficient programming techniques.
I hope that after looking a bit at this example, your reaction will be "How simple!" rather than "How clever! How advanced!" In my opinion, many people are trying too hard to be clever and advanced. The real aim of design and programming is to produce the simplest solution that does the job and express it in the clearest possible way. The aim of the C++0x design is to better support such simple solutions.
Information Sources
My web pages ( http://www.research.att.com/~bs) contain much useful information. There you will find information about my own work (books, articles, interviews, FAQs, etc.) and links to sources that I find most helpful, such as a list of interesting C++ applications, a list of C++ compilers, and links to useful libraries (e.g., BOOST). In connection with C++0x, you can find:- "Wish lists" for language features and library facilities
- The Standard: IOC/IEC 14882—International Standard for Information Systems�Programming Language C++
- The Performance TR: ISO/IEC PDTR 18015—Technical Report on C++ Performance.
- The Library TR: JTC1.22.19768 ISO/IEC TR 19768—C++ Library Extensions.
- A link to the WG21 (ISO C++ Standards Committee) site, where you can find all the proposals being considered
- A page with some of my proposals (including "concepts") to the committee. (Please remember that not all proposals are accepted and that essentially all proposals that are accepted incorporate major changes and improvements before acceptance.)
Acknowledgements
Thanks to Rong Yao ("Royal") who encouraged me to clarify many points. Also thanks to Nicholas Stroustrup, Bjorn Karlsson, and students from my 689 class for their helpful comments.Talk back!
Have an opinion? Readers have already posted 150 comments about this article. Why not add yours?
About the author
-
Artima provides consulting and training services to help you make the most of Scala, reactive
and functional programming, enterprise systems, big data, and testing.
2070 N Broadway Unit 305
Walnut Creek CA 94597
USA
(925) 918-1769 (Phone)