C/C++ is not a thing

It quite common in job ads to find infamous “C/C++”, surprisingly even people with several years of programming seem to use it, moreover, they defend it as right. So, what’s wrong about it?

In December 2020 a C++20 standard specification has been published. Another chapter in the history of C++ opened, diverging the language even more from C — its ancestor — and making it even more complicated than it was. The complexity of C++ is the major complaint among many, the backward compatibility is another. Why compatibility was causing complaints? C legacy makes C++ tied strong to its history. This tie is so strong plenty people still perceive it as almost one programming language. And this where the perception problem starts.

In my too long experience in programming, I was in various corners of the profession, starting from the basics of imperative programming and then effectively from some point built up my career around system programming and embedded systems. What’s most important in conclusion the C and C++ can never be put in the same bag as technology to use is that I’ve seen with my own eyes how badly putting experienced C programmers into C++ projects ends. And badly is a very light word to express the mess.

Talking about C/C++ as if it were one thing and ascribing every weakness of C and negative past experience with C to C++ is just plain wrong. personally, I take most uses of the compound “C/C++’’ as an indication of ignorance.

were words of the author of C++, Bjarne Stroustrup, used in 1994 on comp.lang.c++ USENET group — a strong opinion at that time when C++ was far from its modern glory, but so much true today.

Imperative programming vs object oriented

There is an ongoing never-ending rant (should I call it flame war?) among programmers whether object oriented design or programming is a success or the biggest mistake of all times. I don’t care. Both works. I know two large successful widely used object oriented software projects written entirely in C, these are Linux Kernel and GTK+; I know there are others, what’s important for me they exist. Why then object oriented C++ is so despised?

Many universities (wrongly) teach their students the basics of object oriented design by modelling some real-life examples like a Dog derived from an Animal or a Fork derived from Cutlery… It’s not the point of this text to divagate about this, someday I’ll write about my experiences. Another problem is the fact you’ve given certain tools doesn’t automatically means they have to be all used to get the task done. And this where the problem starts for inexperienced C++ programmers, various books teach multitude corners of the language, almost none focus on how cleanly solve problems. Yes, there are nice articles out there about idiomatic use of C++, but who being busy getting their things done have time to study them? Maybe a few years later as a reflection.

The Go programming language gained popularity thanks to being stripped from advanced features. Most users are happy with all the copy-pasting they do, however, more advanced programmers miss advanced features. In general, the population of programmers is divided between problems solvers claiming they don’t care about the programming language and programming language littérateurs, who commit themselves to master the language of their choice. Go seem to be the right choice for the former and C++ for the latter. There is no way efficient maintainable code can be written in C++ by someone who only scratched the surface.

C++ can be used to write imperative code, free from object oriented design (aside from standard library usage), but secure maintainable code cannot be written like C. OK, technically in 99% of cases it can, but that’s throwing the baby with the bathwater — all benefits of choosing C++ in the first place are gone. No one sane should let that ever happen.

RAII makes sense, shall be used every time it’s technically possible. It makes the code safer. Most fans of Rust come from C battleground and Rust uses RAII extensively, moreover, it practically doesn’t allow doing anything sensible without it at least under the hood. Why any code in C++ should be different?

Several years of experience

How someone with several years of experience in C is going to efficiently write C++ code when suddenly lands in such a project? They don’t. Been there done that. On both sides actually, but I was lucky to have some good mentors on my journey to learn C++, people who actually cared about idiomatic language, even if that probably wasn’t that much of a thing in the C++98 era. But the urge to change the language in new standards do not come from anywhere, right?

C++ evolution is a result of need. Universal portable abstractions work well in projects when fast small native binaries are important. Before Rust caught on, there was no competition as all other languages were either running in VM or using a garbage collection. People working heavily on performance-sensitive projects done in C++ discuss the language a lot, they came with ideas, some of these land in the standardisation committee for consideration. There is a tremendous amount of hard work these people do in addition to their everyday job.

Then they hear “you know, your experience in C++ doesn’t matter, as any experienced programmer can write code”. Is it true? Yes. Is it fair? No. What quality this code is going to have after couple years of contribution? I’ve seen twenty years old codebases in C maintained by a large number of programmers with various qualities — the word spaghetti doesn’t express well enough the condition of these. On the contrary, I’ve seen C++ code maintained to quality and refactored relatively regularly. It was much easier to navigate and read.

Rust is a game-changer as it forces anyone willing to try the language to get up to speed with specific style and idioms, not all forced by the compiler, but by the community producing new crates like crazy. In the end, you learn how to code by reading others’ code. The interesting part is that exercising Rust changes the perception and improves how we deal with C++, and it’s not only my opinion. I’d like every C++ programmer to at least try Rust for several months. What astounds me is Rust gaining among people who didn’t have experience with C++, sometimes had most of their experience in C only. The point is, the major part of Rust’s abstractions is available in C++, if not directly they can easily be recreated in couple lines of code improving the C++ code quality.

Source of mistake

While I understand why recruiters easily make the mistake posting job ads by just copying the content they received from their clients, I don’t understand the defence coming from some experienced programmers. My advice to recruiters would be to become sensitive to the appearance of this non-sense and clarify with customers what they really want. If they look for C++, they should specifically ask which standard is their main one. I’ve seen examples of job ads where it was put very clear. If you’re hiring manager, don’t make that mistake, don’t fool anyone — you should know exactly what your needs are, and the last thing you’d ever need is C programmers writing C++.

The software in C cannot be written anywhere like C++, not even close even if you make attempt to write in an object oriented style. C++ cannot (in my opinion) be written anywhere like C, even if there are language similarities that allow this. Moreover, no C++ project should live without -Wall -Wextra -Wold-style-cast -Werror, compilers today are very good at static checks that prevent shooting in the knee. Most of C-style used in C++ wouldn’t pass these strict checks. I’m pretty sure most attempts to build C++ project don’t use that, hence thinking C is a perfectly fine mixture with C++.

If I’m going to discuss with a teammate how std::expected is valuable in embedded software, I need someone who understands principles of C++, there is no way someone who barely knows it would be capable of comprehending the topic. There is more patterns of error handling in C than I have fingers, none similar to exceptions — if there is a need to replace them, every team member has to understand the importance of this. To be absolutely clear — I don’t undermine or underestimate the great skills of experienced C programmers in anyone, I’m drawing circles around areas that seem neglected when the topic is considered or discussed. It’s possible I’m completely alone in my thinking, however, I’ve seen some elements of this view expressed by others, too.

My plea

While I’m surprised anyone sane would consider C first as the language of choice for any new project in 2021, I don’t mind using it if I’m asked and I’m not against the language. My only concern is the tremendous effort required to write a large correct and safe program in C, the effort that could be utilized better when C++ or Rust would be the choice. Everyone in the industry should care about safety. Maintenance of a large C codebase by several changing programmers is hard and costly, not everyone can afford scrutiny of the Linux Kernel and even there mistakes are made. How many of them could be avoided by using the tool better suited for the job? This question will remain unanswered as we’re never going to be able to compare apples with apples. In my experience, better the tool, better the software.

My plea is to draw a bold line between C and C++ experience and always be clear about project needs. If you need both, be precise and say in your job specification “7 years of C11 experience, 4 years of C++14 experience” — this way everyone reading would clearly see where the potential employer is with their technology needs. Not everyone wishes to be the jack of all trades, some people prefer to be experts in their niches. Being fluent in C or C++ is one of such niches.

Disclaimer: This articles express only the view of the author and cannot be linked with any entity to which the author may have ties, neither personal nor professional.