We were honored to take part in the online session by Bjarne Stroustrup at the Core C++ conference, followed by a lively Q&A session.
The talk, covering the evolution of C++ from 2006 to 2020, was both enriching and inspiring, and deserves its own summary (coming soon). But the Q&A part raised some very good questions followed by interesting answers by Bjarne, which I would like to summarize in this short blog post.
This is my own intuitive summary, based on how I understood things. if I somehow misunderstood something – I’ll be happy to get comments from anyone who was in the room (it was quite packed, with more than 200 attendees) or from Bjarne, who happens to read C++ blogs and comment occasionally.
I also apologize for not crediting the askers for their good questions, if you ping me back with your names, I would be happy to do that.
Unsuccessful Attempt to Create a C++ Dialect
The “big” dialects that may come out of C++ might be considered Java and C#, but those are quite distinct languages, which might be somehow similar in syntax to C++, though different in many aspects. The question focused on how Bjarne views Microsoft’s attempt to create a new C++ dialect with C++.NET, AKA C++/CLI (C++ modified for Common Language Infrastructure)?
Well, Bjarne’s answer here was simple and short. He – and the industry, too – see this attempt as an unsuccessful one to create a C++ dialect.
Are D and Rust the Next C++?
There are two other languages that appear to be gaining some momentum (one more so than the other): D and Rust. The question to Bjarne was how does he see these languages, compared to C++? Does he think that these languages were able to solve some issues that are considered problematic in C++?
Bjarne replied first that he is happy to see new languages coming out. New languages bring new ideas and make us rethink things and improve. The competition is good. Personally, he doesn’t like these particular two – when he played a bit with Rust, he says, he found it cumbersome, too hard, and time-consuming to write simple code. This is of course his own subjective experience, but it seems that the market is mostly in agreement, seeing the adoption of Rust compared to the growth in C++ usage over the last years. Bjarne added that when we do see good ideas in other languages, we – that is the C++ community and the ISO committee – are not shy about raising ideas that may come or be inspired from other languages. So again, it’s a good thing that other languages try new paradigms and approaches, and if something proves to fit well into C++ he would be happy to think about how to adopt it.
ABI Compatibility
Isn’t it time by now to work on ABI standardization, to break the barrier between compilers and allow cross compiler usage of binaries (static or dynamic linking) for the same architecture?
Bjarne, as in previous discussions on the subject, is skeptical and reluctant towards ABI compatibility and standardization. To achieve that, he says, you first need to break the current ABIs, something that has yet to succeed. Reaching a standard ABI may be beneficial to many, but the way things are right now, there is an effort that the standard committee doesn’t want to undertake. This is a difficult problem, Bjarne says, for which he could not offer a solution.
Mistakes
This question touched on the delicate subject of mistakes that might have been made over the years in the language specifications. Are there any “solutions” for such mistakes? And if so, what are they?
Well, says Bjarne, we should look at it case by case. Yes, there are things in the language that we might do differently than today – but you can’t go back, and you can’t solve everything. What you can do is come up with a better way of doing things, then let the old way become less appealing and prevalent, and make the new approach replace the old one. Of course, the disadvantage is that you would have two language solutions for the same problem, but you can’t “fix” things seamlessly by changing behavior without hurting existing code. We’ve done that with string, moving from Copy-on-Write (COW) to Small String Optimization (SSO) and it created many issues in existing projects, for something that may seem as a simple internal change. You have to be very cautious with any change that you make. The direction shall be to come up with new and better approaches.
Covid-19, of course
It’s not surprising that the last question was about Covid-19 and its effect on the C++ ISO committee work: would Covid-19 and the move from intensive onsite meetings of the standard committee to online meetings mode affect C++23?
Yes, there is an influence on the pace of things, says Bjarne. You cannot expect the capacity that is achieved in the intensive standard committee meetings in a week of discussions, to be the same with a scatter of meetings, even if well organized and scheduled. On the other hand, as Bjarne says, C++23 was not planned to be a major version anyway. C++20 is a major version, so C++23 is planned to be more about fixes and small additions, the same as C++14 was for C++11, with maybe a few significant additions that he would like to see. But yes, the current pace of C++23 is slower due to covid.
What Bjarne would still like to see in C++23 is: (a) adding coroutines support into the standard libraries, which means adding coroutines usages into std; (b) shifting the standard library to use modules; and (c) executors, the standard library solution for managing concurrent and parallel execution.
Static reflection is also important and would add significant strength to the language, but the way things are shaping up, it would doubtfully be ready for C++23.
To Summarize…
Having a talk by Bjarne is always an event, not to mention getting answers to our own inquiries. This talk, together with the Q&A, make us better understand how C++ evolved, how it is going to keep evolving – for which purposes, by which tools and forces – and why it is still one of the best software languages out there, probably the best. But we might be biased :).
