|
|
|
|
Sponsored Link •
|
|
Advertisement
|
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]
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:
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:
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.
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.
|
Sponsored Links
|