You can see the current version of the class at:
https://www.cl.cam.ac.uk/teaching/1819/ProgC
I've moved to a style where the lectures are recorded and the lecture hours have been replaced with lab sessions. I've also mostly[1] removed the C++ content and replaced it with more C. Both the videos and the labs should be available for everybody.[2]
This gives more time for tooling (eg, ASan/MSan/UBSan/valgrind), as well as for various low-level topics like memory management (eg, arenas, reference counting and mark-and-sweep) and data-structure layout and cache optimizations (ie, the reasons why people still use C). Also there's a heavy focus on the lack of safety and undefined behaviour -- beyond the lecture devoted to it, this comes up in basically every lecture.
[1] There are still 2 lectures on C++. If you think that it is impossible to learn C++ in 2 one-hour lectures, you are correct. The pedagogical theory at work is basically "Dumbo's magic feather": the goal is to give students enough self-confidence that the year after they won't be afraid to consider doing a final year project using C++ (eg, modifying a web browser), which is the point at which they will _actually_ learn C++.
[2] I'm not totally sure how I feel about this. On the one hand, obviously I'm happy anyone can access these resources.
But on the other, it's really easy to say subtly not-quite-right things when lecturing. If it's ephemeral, then this is harmless since the effect of lectures is just to cue students too remember what to look up when they are programming on their own, but if they can re-watch the video then there's a bigger risk of burning in the wrong idea.
I suppose the long-term thing is to pre-write a script for each lecture, maybe even turn it into a book.
Regarding the bit about "subtly-not-quite-right things when lecturing": IMHO, it's too tall an order to ask professors to get everything in their lectures exactly right. It seems more reasonable to take a page from good journalists - get as much right as possible the first time around, acknowledge if you discover something was wrong, and provide corrections with context.
Ultimately, I think it's up to students to remember that everyone can be wrong, even professors, and to trust but verify. :)
amazon.com/C-Programming-Modern-Approach-2nd/dp/0393979504
My TXR language is like that:
./configure cc=g++
make && make tests
Compiles cleanly and tests pass. I usually work with it with a C compiler. Before releases I run it through the C++ compiler to see what breaks, and fix it. (Usually very little and often nothing at all.)
Teaching them at the same time? I'm not sure I would take programming newbies and try to teach them how to program in C such that it also means the same thing as C++. That is to say, I would be confident that I could teach this in a straightforward way; however, the problem would be the lack of supporting material. For instance, there is no reference manual for the "Clean C" language; what would we use as a text book?
One approach would be just to use C resources, and cover the C and C++ differences as one chapter of the course: basically, how to port C programs to the C++ dialect.
I'd definitely teach the students how to leverage the stricter C++ type conversions while keeping the code C, including the following trick:
#ifdef __cplusplus
#define strip_qual(TYPE, EXPR) (const_cast<TYPE>(EXPR))
#define convert(TYPE, EXPR) (static_cast<TYPE>(EXPR))
#define coerce(TYPE, EXPR) (reinterpret_cast<TYPE>(EXPR))
#else
#define strip_qual(TYPE, EXPR) ((TYPE) (EXPR))
#define convert(TYPE, EXPR) ((TYPE) (EXPR))
#define coerce(TYPE, EXPR) ((TYPE) (EXPR))
#endif
In some ways it's easier to interlink C and C++ code than it is to interlink Python2 and Python3 code.
There's more overlap wrt mental models between C#, Java and C++ than there is betwern C and C++. Being able to compile code in both languages means close to nothing if a developer can't understand how a project is structured and how a component is supposed to work.
Thus, the observation doesn't inform the debate about C and C++ overlap.
>The other day Neel Krishnaswami mentioned that heβs going to be teaching the C class at Cambridge in the fall, and asked if I had any advice about that topic.
Some googling found a C/C++ class by Neel Krishnaswami[1]. The description says 10 lectures so I'm guessing roughly ~10 hours of instruction. The prerequisites for the class are "none". You can also browse the pdfs of class lectures and past exams to get a feel for what the professor is teaching.
With that in mind, we then consider Regehr's advice:
>My main idea is that we need to teach C in a way that helps students understand why a very large fraction of critical software infrastructure, including almost all operating systems and embedded systems, is written in C, while also acknowledging the disastrously central role that it has played in our ongoing computer security nightmare.
The noble goal of "traps/pitfalls/disasters of C" isn't really possible to weave into an introductory course if a class is currently structured with ~10 hours. You have some hard time constraints there. You'd have to remove some topics ... e.g. maybe remove linkers?, STL?, metaprogramming? -- or -- make the class much longer ... e.g. more hours?, more homework?, more case studies?
An "Introduction to programming using C syntax" is one type of class that requires a baseline of time to each.
An "Introduction to industrial-grade software engineering using C best practices" is another type of class with its own heavy time commitments. Teaching the topics of correct/incorrect uses of C would take even more time than the learning the syntax of C.
Regehr's essay is well-intentioned ("hey, you should teach this very important topic <X-prime> related to topic <X>") -- but he doesn't actually tackle how to squeeze it all into a finite time-constrained class.
[1] https://www.cl.cam.ac.uk/teaching/1617/CandC++/