Why Vase drowned, and C ++ is still afloat

  • Tutorial
This article is a brief retelling of an incredibly interesting Scott Myers report for those who do not have 70 minutes for the entire report, but have 7 minutes for the main points.

Some people who do not write in C ++, but only hear about this language, ask the question: “Why does anyone write in C ++ at all?” But there are people who use C ++ every day, and these people ask themselves the question: “But really, why am I writing in this language?”

But really, there must be some reason why people write C ++ programs. Let's go back to the beginning of the 90s, when C ++ was standardized. A lot of ideas were suggested. There were so many offers and they were so different that I remember a quote from Jim Waldo, who then worked in the standardization committee: “Everyone who proposes to add something to C ++ must attach his kidney to the application. Then no one will offer more than two ideas, and he will approach the choice of these two incredibly responsibly. ”

The language that would have been received as a result of accepting all the proposals turned out to be too complicated, and then Björn Straustrup said, “Do you remember Vase?” No one, except people from Sweden, understood what it was about. Vasewas a huge warship built in Sweden in 1625. The basic principle of the ship’s construction was “Why don’t we add here such a feature here?” Many of the ideas came directly from the king, in particular he personally approved the size of the ship. Also, according to instructions from above, it was necessary to attach a huge number of decoration elements, carvings, a large number of guns, etc. to VAZ. But you won’t refuse the king. The result was logical - due to design errors, Vaz sank on the first voyage, barely leaving the bay.

Let's take a look at C ++. Is it as "loaded" with features? At first glance - no doubt:



Let's look at this:
f(x);


Everything seems to be clear - this is the function f, to which x is transmitted. So? Is not a fact. It can be a function, or it can be a pointer to a function, or it can be a reference to a function. It can also be an object in the class of which the parentheses operator is overloaded. Or an object that can be implicitly converted to one of the above. Or one of the overloaded functions. Or a template. Or several of the above things at the same time.

I'm starting to understand why people find C ++ complicated. It seems that all of the above is designed completely wrong. Too complicated.
But wait. Let's measure a couple of things. For example, the number of vacancies for programmers in different languages, the amount of code for them in open sources, the number of search queries to search engines, etc. And if we look at the statistics, over the past 25 years, C ++ is on the 2-4th place in popularity in the world.



C ++ is in second place by the number of code in opensource (12%) and this percentage is growing year by year.



Accordingly, something in this language is done correctly. For some reason he is swimming. Let's figure out why.

C compatible

We can take the code in C - and use it in C ++. We can take the editor, IDE, linker, debugger from C - and use them for C ++ immediately or with minimal changes. We can take a C programmer, tell him "you already know some of the features of C ++, look at OOP, STL, and a couple more things - and you can write in C ++." This thing was incredibly important in the 90s and early 2000s. And today, the C code is the most common in the world.

The most important feature of the language

What would you call the most important feature of the language? (Replicas from the audience: “braces”, “patterns”). Not. These are destructors. Destructors made RAII possible. Destructors simplified the complexity of concepts used in programming by an order of magnitude. In the destructor, we can free memory, mutex, close a file or network connection. Destructors save us from condition branches, from unnecessary goto.

Patterns

There is such a small crater on Mars, which turned out from the fact that the research apparatus made on Earth vigorously crashed into this planet, which in general should not be broken. But crashed. It crashed because in one of the pieces of his code the programmer decided to use the metric system of measures, and in another piece of code, the other programmer - classical English. And somehow it turned out that a kilogram is not equal to a pound.
Templates in C ++ gave us the opportunity to write abstract code, algorithms, functions and classes, which at the compilation stage can be reliably and unambiguously specified by some specific types. This is a huge step forward. And no costs on runtime!

Overload

We can overload functions, methods, operators. We can make the code simpler and more expressive. Overloading the parenthesis operator has become the basis for lambdas in the C ++ 11 standard, and lambdas are very useful.

Language for Libraries

C ++ was designed as a language convenient not so much for application programmers as for library developers. The idea was that when there are a lot of good libraries, it will be convenient to write really good applications with their help. Now we can say that we really have a lot of libraries for C ++, so the idea paid off.

Multi-paradigm

Procedural programming? OK. Object Oriented Programming? OK. Metaprogramming on templates? OK. Dangerous programming with pointers and assembler inserts? OK. Mixed concepts? Also approx. Even functional programming to some extent already becomes possible with the advent of the latest C ++ standards.

Best language for "obstacle programming"

C ++ may not be the best language of all time, but at the moment it is the best language for what I call "programming with obstacles." An obstacle may be an unknown subject area, high requirements for speed or memory consumption, the need to communicate with strange someone else’s code or hardware devices, task uncertainty, etc. Choosing C ++ in a situation with the presence of the above (or other) obstacles - you have the highest chance of not ruining the project at some point simply because it is impossible to solve the problem in the selected language.

You do not pay for what you do not use

One of the basic principles of the language. What can be calculated at the compilation stage - there it is calculated. Unused code - not called. The program works out only those instructions that you wrote, in the exact order in which you made it do it. No backstage games. Such things are especially important in system programming.

Platform Independent Assembler

Another property of compatibility with C. A C ++ program has not gone so far from assembler. In most cases, you can understand which set of assembler instructions the C ++ code will deploy to. As a result, you can write effective programs for any platform. Moreover, for some platforms it is possible to write only in C / C ++.

backward compatibility

C ++ code written in the early 90s on the first versions of the C ++ standard can simply be taken and compiled with a modern compiler that supports C ++ 14. And it will compile. Well, with a high probability. And he will do what he must. Again, with a very high probability. There are a couple of places that can break, but they are few and they are well known. Thus, we tell companies: investing in C ++ code today you can be calm - and after 10 and 20 years your code will work, which means your money will not be lost.

Difficulty to hide

The C ++ language is often blamed for the fact that the code on it is complex. It would be more accurate to say that in C ++ it is really possible (if you wish) to write complex code. And it’s hard to talk about C ++ code. Let's take a look at this:

std::cout << x;


Oh my goodness! Yes, there are namespaces, streams, a template (implicitly specified), an object of a class (inherited from another class), and operator overloading. Nightmare! But take a look at the code above again. You really don’t understand what is written there? Do you really think about all these terrible terms that I mentioned when reading this code? Not. Complexity is hiding from you, you do not notice it.

Language for those who have no other choice

People who decide to write in C ++ do not live in a tank. Often they know a couple of other languages ​​- scripted, managed, functional. Where you can save yourself time and effort - they write on them. But sometimes it turns out that there is no choice - the problem is too complex, the requirements are too high, the risks are beyond. And then C ++ enters the scene. A sophisticated but powerful tool for complex, but large-scale tasks. This, by the way, is one of the reasons why programming in C ++ and code in C ++ are considered complex - the average level of tasks solved in this language is higher. It is naive to wait for a solution to a super-complex problem with simple minimalistic code.

Language for those who like difficulties

Yes, in C ++ it’s very easy to shoot yourself in the foot. Even in many different ways. But for some people this is a plus. The ability to shoot yourself in the foot suggests the ability to shoot at all anywhere, anytime, and anytime. Yes, the results can be terrible. But the power is awesome.

The standard is getting bigger and ... easier

We are told that in the C ++ language standard in the 1990th year there were 400 pages, in 1998 - 700, and in 2011 it became 1300. “The language is becoming more complicated” - we are told. No, it doesn’t. Yes, we introduce new concepts and features, but most of them are designed not to complicate, but to simplify the code. Remember how you had to run iterators over vectors - and here in C ++ 11 we have range-based for and auto. We can write one line of code where it used to be 5. Lambda functions made it possible to exclude entire entities from the code — superfluous classes and methods that were not needed in fact. Yes, standard developers have to ponder and write substantially more text. But the end programmer is only getting easier.

Also popular now: