Why I no longer use modern C ++

Modern C ++: what is it and how did it come about?

Over the past decade, with the arrival of the C ++ 11 standard, and before that, the TR1 specifications and the Boost library, which precede it, the C ++ community of developers witnessed a massive transition to a new programming style, the so-called modern C ++. This transition implied the introduction of such techniques as the auto keyword, closures (lambda expressions), variable patterns, and much more. C ++ turned out to be fertile ground for experimentation, and several libraries written in the new style were born. Those who could understand new idioms like SFINAE, tag dispatch, CRTP, type generator, safe bool , etc., or at least learned how to reproduce them, were awarded the title of guru.

With the appearance in the early 1970s. The intuitionistic theory of Martin-Löf types, which is the result of the intersection of pure mathematics and computer science, began a period of active research in the field of new types of languages ​​such as Agda and Epigram . This laid the foundation for the functional programming paradigm. All these theories are now being taught in universities and proclaimed as a “breakthrough”, and huge amounts of money are invested in their development and promotion. There is even a whole community of speakers who earn their living by promoting this “breakthrough” among representatives of business America. Therefore, it is not surprising that the current decisions of the C ++ Standardization Committee are actively influenced by new members - yesterday's students, whose opinion was shaped by this environment.

Reorientation from performance to functionality

Over time, C ++ has evolved from a “fast” language into a “functional” one, and performance has been forgotten. Now it is no secret that some C ++ components, for example, the iostream library and strings, by their very nature, cannot work quickly; In addition, some basic features are missing, such as controlling the transfer of data over the network and very basic functions, for example, the simplest procedure for splitting rows. If you ask any member of the Committee why these shortcomings have not been eliminated over the past almost twenty years, the answer will invariably be the same: because no one wanted to bother with the preparation of the relevant report or proposal.

The committee expects to use the research group SG14 - a division of the ISO 21 Working Group (WG21) dedicated to game development and high-frequency trading (HFT) - as a platform to discuss further language improvements between specialists from the low-latency software industry. However, judging by the discussions that have already taken place in the discussion groups and the Michael Wang Standard (its content is as funny as the name), no one is eager to carry out the radical reforms that C ++ needs so much to compete in this area with “C ++” with classes ".
')

And why is this actually a problem?

I conduct an expert analysis of C ++ code for a large number of development companies as a consultant both in strategic investments and in optimizing and increasing application performance, and I learned from my own experience that the performance of programs written in modern C ++ leaves much to be desired. The reason is not that the new style does not allow creating high-performance systems with low latencies; it’s just that there are many obstacles in the development process that paralyze the work of programmers or create extremely difficult-to-optimize graphs that create difficulties for compilers. I am extremely glad that there is Chandler Karut with his series of video lectures, thanks to which we can restore the lost connection (and at the same time a bit of sanity) between the C ++ language and reality.

Performance loss

The first stumbling block, as already mentioned, is the potential loss of performance due to the more complex structure of the intermediate code presentation and compiler passes. From this point of view, Fortran is much better, since it is simpler and compilers can optimize it much more efficiently compared to similar C / C ++ code. My own experience in the field of HFT and game development for decades, as well as data from authoritative peer-reviewed publications, and indeed, observations of anyone with a little compiler optimizations show that the common belief is that conventional and variable templates allow you to get much faster assembler code due to the automatic "dissolving" of C ++ code at the compilation stage is not confirmed in practice . This is nothing more than a fallacy, with very steady. In fact, the opposite takes place: small code fragments are much better compiled, debugged, and optimized when working with the generated assembly code, rather than with templates.

Compile time

The next issue is compile time. Regular and variable templates are “renowned” for their ability to increase the compilation time tenfold because of the rebuilding of the much larger number of files involved in the process as compared to the traditional style. While a simple, traditional class in C ++ is recompiled only if the header files that it directly included were changed, in modern C ++ one small change often entails a complete reassembly of the project, which often takes up to ten minutes. For classic C ++, this time, with the same small revision, is a few seconds.

How soon the programmer will be able to start testing the generated assembly code, having finished making the necessary changes to the program, depends on the quality of the generated code. If the application can be quickly assembled and tested, then all problem areas will be fixed more likely. And if the compilation takes ten minutes, then this probability is greatly reduced.

Maintainability

The third and last obstacle is related to the complexity of the code. As Edsger Dijkstra once said,

Simplicity is the key to reliability.

If in order to understand the code, you have to hire a programming guru, then either something is wrong with the code, or the chosen language is not suitable for the tasks to be solved.

If you carefully read, perhaps, the most famous article by Dijkstra , “On the dangers of the goto operator,” it is easy to see that its most important provisions also apply to templates (ordinary and variable): it’s not that the mechanism itself is bad, but that the inherent structure inherent in it inevitably generates a complex code, which ultimately eliminates the most important advantage of a quality code - its comprehensibility.

When creating trading systems, when up to 100,000 orders per second are sent over the network, and trading strategies are developed and implemented every two days, the simplicity of the code is not just desirable - it is necessary. Hence my “rule of one minute” when developing such systems:

If in one minute it is impossible to understand what this C ++ file is doing, consider that the code is incorrect.

True reason

However, the real reason I’ve almost stopped dealing with modern C ++, despite the fact that I’ve been very successful in it, is that there are more and more developments in the IT industry that really should be paid attention to.

C ++ has become similar to Fortran: it has reached its limits. Now so fast interfaces already exist that the very concept of a “clock cycle” becomes irrelevant for certain nodes of the system. The speeds have reached such values ​​that two bits of information, sent strictly along a pair of adjacent wires, will surely get out of sync without passing a meter.

C ++ is no longer suitable for managing such speeds that are implemented in modern processors, mass-produced on the market, since it is initially focused on a serial data transfer method - even in the most parallel systems like the GPU.

A modern developer, if he really wants to keep up with the times, is forced to turn to new languages ​​- Verilog and VHDL; he must be able to design his own processors and virtual models of motherboards, otherwise he will not cope with the avalanche of technological advances in the coming years. And the point is not that the FPGA ( User Programmable Gate Array , Field-Programmable Gate Array , FPGA ) is characterized by ultra-high speeds - this is not at all the case. In fact, they are an order of magnitude slower than the top processors.

Just now there are more and more all sorts of reconfigurable computing systems. For example, Intel supplies Xeon processors with embedded FPGAs, and the Internet of Things ( IoT ) will turn into a market with billions of dollars in the next five years, and the engine of this process will be largely small ten-dollar PPVMs, for which will have to hire an army of skilled technologists. And believe me, programming at the RTL level ( register transfer level, register transfer level ) is hundreds of times more difficult than writing code in C ++. And if learning C ++ is not easy, imagine what it means to master PPVM programming at a professional level (documentation for Altera’s Transceiver Toolkit alone takes 700 pages, for the Quartus development environment, another 1000, not to mention Xilinx products).

And yet it is worth it. When you finally master these new languages ​​and techniques, you will have the greatest opportunities for the realization of your own ideas. This is exactly how “unicorns” are born ( startups, whose estimated cost in a short time rises to a billion dollars and more - approx. Transl.) - thanks to people who are able to see the whole picture.

Conclusion

Anyway, I think that C ++ is gradually becoming a thing of the past. As in the case of Fortran, its age makes itself felt. Therefore, investing time and energy in improving your programming skills in modern C ++ is the same as investing in Cobol or the same Fortran. The programmer of the new time must master the new tools in order to be able to manage with the advanced technologies that will appear in the coming decades. And the time to study all this is too little.

Translator's Note

I do not completely agree with the opinion of the author, however, I believe that C ++ programmers should read this article. I also have a feeling that with modern C ++, something is wrong. The "tricked" code on the templates becomes extremely difficult to understand and in addition, it does not give the promised efficiency. I am generally more and more inclined towards writing C-style code with classes.

Oh yes, I almost forgot. Use static code analyzers to reduce at least the number of stupid mistakes - and without them there is enough headache with C ++.