A few weeks ago, the Core C++ Israel conference took place for the first time, in the Academic College of Tel-Aviv Yaffo.
Naturally, I have mainly focused on the domains that are closer to my day-to-day work and interests; unfortunately, I did not manage to be there during the whole conference period. In this post, I provide a short summary of the conference – at least those parts of it where I was present – and some paths and directions that it presented. I will not get deeply into the lectures details; I might add some more detailed posts at a later time. The titles and the descriptions are all my own interpretations – these are not the official titles of the presentations. Moreover, I assume that the intents behind some of lectures might be different than those I refer here as my individual perception of them.
Where We Came from and Where We are Going to
A few years ago, while I was focusing Python, I thought – like many of my friends, the C++ veterans – how sad it is that my many years of profession and deep understanding of the language will soon be worthless. At the time, C++ looked like a dinosaur in a world of new, shiny languages, which are made for a world where the limits of bandwidth, clockcycles and RAM size are fading out take the front of the stage. However, not only did the language not lost its shine, but it seems that no real substitution is found for tasks that require real fieldwork.
One of the interesting lectures on that topic was provided by Anastasia Kazakova from JetBrains. The lecture focused on the place of C++ in the SW industry of 2019. It was divided to two main parts. In the first part, Kazakova presented numbers, graphs and analyses. An impressive try to estimate the use of the language in various SW domains, on various OSs, various demographics and the like. Most of the analyses referred to the division among the various versions of the language. If you were wondering – C++11 is the clear winner, in almost every measure. The numbers are very interesting, but to say the truth, I suspect they do not say much. The survey JetBrains relies on included very few thousands of programmers. This is only a small fraction of the whole C++ community, and there is no reason to believe that it was a statistical sample.
Memory and Performance
Yossi Moalem, from Checkpoint, provided a great lecture about the way in which the physical memory structure affects the performance. Indeed, most of its content are probably familiar to those who work in low-level environments (e.g., as appears in the masterpiece of Meyers and Alexandrescu about the problems in the pattern of Double Checked Locking). Nevertheless, the lecture was very interesting and the great presentation provided excellent illustration of the content discussed. In addition, throughout the whole lecture, Moalem used the same specific test-case with relevant performance measures. The lecture detailed the physical structure of the memory and cache in the various levels, and described how the way in which elements are held in the memory and the way they are being accessed can dramatically affect the performance. After that, Moalem discussed multithreads systems and how the memory structure can cause different threads to see different, unsynchronized data. Finally, he presented some of the tools that C++11 offers for creating memory fences and accurate access to the memory, that will not allow compiler or CPU optimizations to harm the data coherency.
Throwing Exceptions or Returning an Err-Value?
Phil Nash from JebBrains discussed the inherent problem of the current ways to handle errors in C++: On one hand, good SW engineering requires using exceptions. On the other hand, in many cases, performance issues dictate avoiding that relatively heavy mechanism in favor of returning simple error values, the good-old-Kernighan-and-Ritchie style. If you have chosen to use C++, it is very probable that your system runs in a high-performance domain – which makes the whole exceptions mechanism less useful in the language. Nash described the differences between error-values and exceptions. Then, he showed how to use the tools provided by the language for a sophisticated implementation of error handling, in ways that provide better performance than exception handling together with better SW engineering than returning naive error values. Finally, he presented a full thesis, suggesting a solution that allows a mechanism that is similar to exception handling but keeps the performance similar to return values. That solution requires changes in the language, and it was suggested to the committee.
Closing Lecture: Modules
The closing lecture was given by Bryce Adelstein Lelbach from Nvidia. Its subject was one of the most controversial issues in the community: Modules. The modules should be part of C++20, but there are still “fighting retreats” about the actual way they will be finally defined. In fact, this is probably the largest change ever done in the language. This is not about some new element or a novel syntax with surprising effects. The idea of modules completely displace the simple, basic idea behind C++ and its elder sister C – the concept of Coding –> Compilation –> Linkage or, if we refer to the files – Source Code file –> Object file –> ELF. Throughout its many years of existence, a Compilation Unit was always a single source code file. If there was any need for the file to be aware of other entities, it was done by #includeing the relevant header files, which in turn, after the preprocessing stage, became part of the code in the source file. After that stage, the linker was responsible to all the symbol resolutions among the object files, without any hierarchy or any direction from the source code. The relations and dependencies between the files of a project are completely outside the scope of the language, and are being managed by external mechanisms, like Makefiles or Solutions.
Well, in C++20, this is about to change (in practice, according to Adelstein-Lelbach, it might take as many as 15 years until it is commonly adopted as a de-facto standard). Relations between files will be defined neither “below” the language in the preprocessor domain, nor “above” the language in Makefiles and the like. Instead, the language itself will define those relations, using modules. A module can define, explicitly, what API it exposes and what is its internal implementation. Instead of using the preprocessor direction #include, a dependency will be defined using a new keyword in the language itself – import. Thus, in fact, the structure of a project will be dictated by the language itself rather than by external tools – which will allow faster, better and more effective build process.
The lecture presented the motivation for modules, the syntax that will be used and the possible ways to implement such build systems.
Two half-days were devoted to the domain of teaching the language. Some of the lectures did not innovate much, but some of them have raised interesting observations.
C++03 –> C++20
In a session that focused on teaching the language, Amir Kirsh from the Academic College of Tel-Aviv Yaffo and Yehezkel Bernat (from Microsoft and Hadassa College) went over some of the important features in the latest C++ versions. Kirsh was speaking about features of C++11/14, and Bernat discussed some features that were entered to the language in C++17 and those that are going to do it in C++20.
Joyce Vogel, from Lev Academic Center, described important aspects one should take care of when creating an online course or a course that combines learning in classrooms with online activities.
Not specific for C++ teaching, but very interesting: Using C++ templates, it is possible to describe any required logic – the syntax of C++ templates is proven to be Turing complete. This fact is known for many years, but I never had the chance to see the actual proof for it. In that session, prof. Yossi Gil from the Technion described the proof in general lines. In addition, he discussed the differences between C++ templates and Java generics.
Let the Students Define their (not) Own Projects
Keren Kalif from Afeka College described the structure of the academic course she lectures. Instead of defining the projects which the students have to implement, she instructs her students to invent their own ideas for projects. After the approval of those project, they have to write the relevant header files and define there the required API. Then comes the twist: At the next stage, each student should choose some other project, of one of their friends – and implement its existing API. Thus, her students experience two aspects that many times are lacking from the academic studies – defining pure APIs and working on someone else’s code.
Teaching the Language as First Language
Dr. Yechiel Kimchi from the Technion presented the main elements in his course, in which he teaches fresh CS students C++ as their first language, through which they learn what programming is at all.
Update the Content, Update the Media
Meir Komar, from the Academic Center Lev, presented a fascinating lecture, in which he discussed the need to evolve the CS degree’s contents and the means of teaching them. The lecture started with a discussion about the subjects and domains that compose the core of a CS or SW Eng. degree and their updates throughout the years. Then, it moved to its main part, where Komar presented the special aspects that distinguish the Millennials, or the Z-Generation students – what their expectations and what the best approaches to teach them are.
Understand the Language Bottom-Up
Shmuel Fine, from AlgoPlumb, described the ways he uses to teach his apprentices and the means he uses to overcome the common issues that rise when teaching a language which its roots are planted deep in the world of low-level. In fact, the approach he suggests is surprising by its simplicity – yet, I’ve almost never seen that approach being taken anywhere in practice. Shmuel suggests teaching the language in a way that immediately connects the students to the actual meaning of each element of it (this dictates – although I’m not sure he expressly said that – that the first language being taught is C, or the subset of C++ which is C-like – and not plain C++).
For example, teaching variables is done by immediately watching the memory map in order to fully grasp their actual meaning. Working that way makes later teaching about addresses and pointers, for example – which is one of the hardest challenges in C/C++ – much simpler and easier; the students naturally understand it because they are already fully connected to the artifacts created by the language in the level of the bare metals. In my opinion, despite the fact that the lecture did not introduce any new technology aspect, it presented one of the most important ideas in the conference.
Basic C++ Elements
Adam Segoli Schubert, a TA in Tel Aviv University, described the important points he emphasizes to his students throughout the course for a better practical understanding of the language.
A C++ Junior – From the Industry Point of View
Finally, Daniel Trugman, from Palo-Alto Networks, described the skills and knowledge required from a junior graduate or engineer without experience when applying to a position that requires C++ knowledge.
Teaching C++ – an Experts Panel
Among the other activities related to C++ teaching, there was a panel of experts that discussed teaching the language. Unfortunately, I’ve felt that this specific panel missed the point a bit. First of all, all the speakers were lecturers from academic institutions. Thus, a very specific and narrow point of view was presented – that of teaching C++ as part of an academic syllabus in computer science or software engineering. It could have been very interesting to bring to that panel experts from other teaching disciplines – for example, bootcamp mentors; evening-courses instructors; owners of online websites for learning C++; team leaders that train juniors or seniors that do not know the language and more. In addition, all the speakers were pure C++ people. Thus, for example, after the moderator had raised the question “which programming language should be taught first”, everyone agreed on the same answer and shared the same smile of wisdom. In fact, it could have been much more interesting to confront that approach with lecturers that believe that Java or Python are better as first languages, in order to really examine it.
The conference was an interesting occasion of meeting people from many domains and disciplines, and provided new insights, knowledge and points of view about the language. Among others, some long-shot view of the directions (which some of them are very sad… but for that I’ll dedicate another, later post) in which the language progress into the future, deep insights about non-trivial issues in the language, and tools that some of them provide real inspiration for learning C++.