Context : the latest ISO/C++ Committee gathered in Sophia Antipolis a few days ago. The meeting was very "calm", since it was the very first held since the standard was accepted last November. Bjarne Stroustrup kindly accepted to make a public presentation before leaving. Here is a short transcript of what he said.
Stroustrup think that programming languages are not interesting, but programming is. He started by using Simula but was appalled by the resources consumed by the existing compilers. He imagined a language that would combine Simula's elegant OO features with those of a "fast" language (BCPL at that time).
C++ serves two purposes :
Classes are used to represent concepts. You need to capture relationships
between concepts and between classes. The relationships between concepts
are expressed by parameterized types, and those between classes are represented
by class hierarchies.
For concrete types, no compromises are needed on conventional notations
runtime space and efficiency
The approach of the C++ Committee is to use abstract classes and iterators.
There is no reason why an iterator over a list should be very different
from an iterator over a vector. The first solution that appeared was to
use a pure interface for Iterator :
Very recently, I was talking to someone who was puzzled (not to say appalled) to find out that there were not just "Iterators" in the STL, but "Const Iterators". While I proceeded in explaining how they both differ and why they are necessary, I can't help thinking that a gentle introduction to the problematic makes all this stuff clear and natural. This shouldn't need to be explained, it should come natural. And I have the feeling that now would have been the right time for Bjarne to do so.
I suspect that both time constraints and the fact that he didn't know how C++ aware his audience was made him switch to another gear.
Stroustrup then showed the "classical" STL example, that solves the problem of reading the user's input, sort the words and outputs them. The listing is less than twenty lines long and was thoroughly explained.
Cedric: I am not a great fan of this example to illustrate the STL. I have the feeling most of the people who see it for the first time will be worried by its compacity and will overlook the main point (which is : STL allows a great abstraction at almost no cost if compared to a "manual" solution).
STL Iterators are already a complex notion to grasp for newcomers, and I am not persuaded that showing their use through stream iterators is a good idea. After asking a few people around, it turns out they were not that repelled by the example, so maybe it's just me.
Cedric: this is admittedly a very important problem and there are very complex notions at work here (mostly related to : it is necessary to know what the different template strategies are available in order to use the one that is most suited to your problem). However, I fail to see how it fits with Bjarne's overall discussion, mainly focused on high-level notions. Anyway.
However, you are inheriting a lot of uninteresting window implementation details doing this. This is a general problem with inheritance : the user should not be bothered by this.
It is necessary to be more loosely coupled to the windowing system. There are several ways to achieve this, one of them being to use abstract interfaces and multiply-deriving concrete implementations from both the interface and the window implementations.
Cedric: another one, more suited IMHO, is delegation, but this was not mentioned.
Then again, I found that Bjarne didn't go far enough in his point.
My perception is that this is another attempt to explain how STL is such
a fine library. Here, Bjarne tried to show that blindly deriving can be
nasty, and that this shouldn't be done without careful consideration. The
STL shows how it is possible to build a sound hierarchy while avoiding
almost entirely derivation, and promoting aggregation and combining orthogonal
functionalities. BTW, I love the STL, in case you hadn't noticed.
Regarding the STL, Bjarne reminded that however well-designed it is, it remains a low-level library, which purposefully exposes low-level details (like allocators) . It should be seen as a foundation for higher-level frameworks.
Cedric: C++ is in good way, and should become even more enjoyable to use in the forthcoming two years, while the standard slowly percolates through available implementations. Compiler vendors are working real hard to catch up with it, and the first fully ISO-C++ compilers should be expected in the next few months (my guess is that VC++ will be the first one, while Sun announced that their next major version wouldn't be out before at least eighteen months).
A: If Java was just a programming language, nobody would have bothered at all. It is however an extraordinary example of a company betting its very existence on a single idea. Java is very uninteresting (the worst language I have seen in years) and it's a shame Sun makes claims that cannot possibly be delivered.
Cedric: I am really saddened by his recent statements on Java. Bjarne has always been a model in objectivity and reasoned opinions, but I can't understand these emotional sentences. This is even more unforgiveable that he could just stick to facts (like the hype) and he would gain immediate approval of any crowd, however hostile to C++ they may be.
The worse is that he is usually much more balanced and neutral during Committtee sessions. Why he chose to be so aggressive toward Java in front of an open audience, I can't understand. Many people will most likely consider this as bitterness coming from someone who sees his baby somehow "threatened" by a newer and challenging contender.
I don't see things this way at all. I still believe Stroustrup
is definitely non-emotional on this issue, but is grieved to see that all
the pragmatic considerations that have always guided the evolution of C++
have been completely discarded (and even despised) by Java creators.
Q: How are the C9X and C++ Committee cooperating ? Isn't this a oneway process ?
Cedric: a very insightful question, which had been discussed a few days ago during the meeting
A: My impression is that C9X is driven by Fortran programmers trying to write Fortran code in C, and who are not that interested in adding design features (strong typing mostly).
Cedric: This is a very hot topic. The feelings on this issue among
the C++ Committee are mixed, but some of them definitely have a few problems
with the C9X people. This comes as no surprise actually, that C9X is only
remotely interested in C++ while the opposite is really true. My feeling
is that the differences can't be worked out, and I think the forthcoming
versions of C and C++ will not be compatible. This has become less an issue
by now, since C++ has now gained wide acceptance, but it would definitely
have immediately grinded C++ to a halt if such a resolution had been taken
ten years ago.
Q: Is anything missing in the standard ?
Cedric: Of course, Stroustrup (just like everyone else) has minor
nits about the standard but to put the words in his mouth "I can't think
of a missing feature I'd like to see added at all costs, nor of a feature
I'd like to see removed".
Q: What would you consider for future additions to the language ?
A: I have been thinking for the past years about including concurrency about the language, and the reason why it hasn't been done is that I haven't been able to figure out a general-purpose and elegant solution that would cover all the possible aspects of concurrency Concurrency can mean many different things (process-level, database access, threads, etc...) and so far, not a single approach has been identified that could "do it right".
Cedric: Other considerations for future inclusion in the language
: garbage collection and embedded C++.
The next ISO C++ Commitee will be hosted by SGI in the Silicon
Valley. Then, it will probably be Dublin and then Hawaii.
Back to my homepage