Wednesday, 25 June 2008

The future of C++

In my recent blog entry* I complained about not exactly knowing where C++ is heading, what features will C++0x contain when it finally appears, and if we'll need to switch to hex as in C++0a ;-). Then I read some interviews with Bjarne Stroustrup** and the things became clearer.

1. The process

The first ambiguity I addressed, was the problem of the very loooong time which C++ needs when acquiring new features, and hinted at the lack of corporate backing. Bjarne on that**:
BS: The progress on standard libraries has not been what I hoped for. ... We will not get ... I had hoped for much more, but the committee has so few resources and absolutely no funding for library development.
BS: There is no shortage of good ideas in the committee or of good libraries in the wider C++ community. There are, however, severe limits to what a group of volunteers working without funding can do. What I expect to miss most will be thread pools and the file system library. However, please note that the work will proceed beyond '09 and that many libraries are already available; for example see what has to offer.
So that's pretty clear, the industry isn't backing C++ anymore, and the ISO beaurocracy isn't helping here. Java's JSP is definitely more lightweight. Python hasn't a commitee. IBM, Sun (and Google?) are massively backing Java. Previously Google was a stronghold of C++ (MapReduce, BigTable, BigFile), but lately Java seems to take over, in the real "weed language" manner.

2. The features

The second of my questions was the extent of new features which will make it into new standard, beacuse this was a constant source of confusion: thousands of proposals, each in a different state of progress, constantly wandering between approved, considered, considered strongly, considered not so strongly, not considered, demised, etc ;-). Now the new feature scope seems to stabilize at last. Bjarne again**:
BS: I do — based on existing work and votes — expect to get:

- Threads
- Regular expressions
- Hash tables
- Smart pointers
- Many improvements for containers
- Quite a bit support for new libraries

- A memory model supporting modern machine architectures
- Thread local storage
- Atomic types
- Rvalue references
- Static assertions
- Template aliases
- Variadic templates
- Strongly typed enums
- constexpr: Generalized constant expressions
- Control of alignment
- Delegating constructors
- Inheriting constructors
- auto: Deducing variable types from initializers
- Control of defaults
- nullptr: A name for the null pointer
- initializer lists and uniform initialization syntax and semantics
- concepts (a type system for template arguments)
- a range-based for loop
- raw string literals
- UTF8 literals
- Lambda functions
The most important feature (IMHO) is**:
BS: The new memory model and a task library was voted into C++0x in Kona. That provides a firm basis for share-memory multiprocessing as is essential for multicores.
and, of course, the auto keyword and lambdas!

Maybe more important is what won't be there**:
BS: The progress on standard libraries has not been what I hoped for. .... We will not get the networking library, the date and time library, or the file system library. These will wait until a second library TR. I had hoped for much more, ...
BS: ... What I expect to miss most will be thread pools and the file system library. However, please note that the work will proceed beyond '09 ...

But an important change of working style will take place:**
... Fortunately, the committee has decided to try for more and smaller increments. For example, C++0x (whether that'll be C++09 or C++10) will have only the preparations for programmer-controlled garbage collection and lightweight concurrency, whereas we hope for the full-blown facilities in C++12 (or C++13).
and we may expect a host of new extensions in the future!

On the other hand, at least when the multithreading is concerned, there are independent libraries available, and they offer some rather high level concepts! Take for example the latest Trolltech's Qt 4.5 framework***, which implements futures, automatic scaling for multicore, has a MapReduce implementation plus concurrent mapping and filtering algorithms. It's just like Java 7's fork-join framework* and the ParallelArray class. Bravo! Other library with high level threading support are of course the Intel's Thread Building Blocks, it's not bad either! At this point we don't need a standard document, as it seems.

3. The prospects

At last, let's pose a more general question: what kind of language wants C++ to be? In the past Bjarne Stroustrup maintained that C++ should be a "general purpose programming language". Contrast this with the statements from the last interviews**:
JB: You are looking at making C++ better for systems programming in C++0x as I understand it, is that correct? ...

BS: Correct. The most direct answer involves features that directly support systems programming, such as thread local storage and atomic types.

JB: C++ is often used in embedded systems, including those where safety and security are top priorities. What are your favorite examples and why do you think C++ is an ideal language for embedded systems especially where safety is a concern, aside from easy low-level machine access?

BS: Yes, and I find many of those applications quite exciting.

For my taste, Bjarne thinks clearly that C++ is an system and embedded programming language: e.g. he expressed his fondness for robotics systems before. That's bad news, because I don't really like embedded programming and automotive :-(((. On the other hand, system programming is quite exciting for me, provided I haven't to fiddle about low level data structures too much.

Allow me a question in this context: for me OO programming is about hiding low level details, seeing the bigger picture. If the strengths of the language lie in the hardware access then maybe it's not so useful for OO programming? We can use C for low level programming (like Wireshark's code does, and it's not a toy system) and do OO in Java or Python? So where's the place for C++ then?

But maybe the future will be totally diffrent? Maybe we won't be programming C++ anymore but rather the Qt platform, which only happens to be written in C++? This would be akin to the Java platform: because C++ doesn't provide a standard ABI, many comapnies are using Qt as to assure the portability of their code between operating systems (among others my current client). Interestingly, not only in GUI applications, abut also in general purpose programming! But what about the (maybe only preconceived) imcompatibility with the standard library, which I bemoaned in one of my previous entries? If I can give faith to Danny Kalev's words****:
And in other news, Nokia completed its acquisition of Trolltech last week.
Qt is currently used in Skype, Google Earth, and Adobe Photoshop Elements.
After Nokia's acquisition, it seems that Qt will be modified to support Symbian and other mobile environments, or at least POSIX libraries and better support for mainstream C++.
then it seems that not only yours truly is having that impression, and that there will be a remedy soon!

* Language trends and waiting blues:
** An Interview with Bjarne Stroustrup: (but
also , although I don't quote it here)
**** C++ Reference Guide: (Notes on 25th of June)


Anonymous said...

Maybe it's just me, but it seems like Bjarne knows that if he keeps positioning C++ against platforms like Java and .NET for general programming purposes, he won't be getting much funding out of parties like IBM and Sun. That's very pathetic, as all these companies made a lot of use of C++ throughout the years.

On the other hand, I do feel C++ has a lot of shortcommings that many people prefer not to deal with, which reflects on why .NET, Java, Ruby and other systems have found such a huge audience throughout the last decade.

I myself don't program in C++ at all. I did learn it and used it at school, but I've never really seen the point of it. Maybe because I learned it right after I learned C, and didn't feel there was anything I couldn't do with C that I could do with C++.

At one point, C++ seems like the salvation to many, many problems, but I don't feel it was ever completely realized. Nowadays, functional programming systems seem more like they could be it, but I'm sure they won't be either. C++ tried to be everything to everyone, and that's impossible to accomplish. I believe the reality of today is that there's not one single programming language/environment that can be or should be used for everything. C++ for web development, for example, doesn't come to mind as a great choice. Java has been trying to do that for years and it has had some wins, but it's still not there either.

The more money the bigger the chance that a programming environment/language can succeed. But in today's climate, money doesn't completely dictate what programmers will choose. If it was only money, everyone will be coding in .NET/ASP, and that's clearly not the case.

The conclusion is that C++ will be around for many decades to come, but it needs to provide something no other environment can deliver if it want to mantain or increase its community. I'm sure someone else will come out with a religious/cult-based answer to this, but the truth is simply out there and it's staring us at the face.

Marek Krj said...

Well, I personally think that you can solve many problems very elegantly in C++ (in comparison to Java, for example), but on the other side, I don't know if I will want to solve the problems, where C++ will be applied...

Because the general mood is rather pesimistic: as my distinguished collague Stefan Z. said, when asked for the comment: where are all the standardized frameworks and libraries the other languages have? When I pointed out Qt, he said something like: too little, too late...