How to read the specification correctly (C/C++)?

Question

C++ / C#

Good day to all.
Very often, when searching for a particular question, you find answers in which people give detailed answers and quote the standard of the language. Here I had a few questions:
1. How to read the specification correctly? Did the people who know her directly pick up the document and read it cover to cover? Or did it happen in the process of practice - when questions arose, they turned to the specification and studied the problem area, which led to a step-by-step acquaintance with the material?
2. How to patch up gaps in knowledge? Let's say you already have good experience in writing programs, knowledge of the language, some subtleties, etc. ..."). And 70 percent of a good book or the same standard is simply not interesting to you. Suppose you start reading a chapter, you seem to be familiar with the material, but still there are fears that it may contain an important note or paragraph. So you start reading based on what you already know. As a result, a waste of time, boredom and throwing things halfway.

Answer 1

answers in which people give detailed answers and quote the standard of the language

I do this quite often.
And so and so. In general, it is useful to start by simply scrolling through the standard in order to understand what is written there at all, and where to look for answers to questions that arise.
And then you can just look for answers to all the questions about the language, both your own and others'.

Answer 2

Even Stroustrup writes in the book that knowing the details of the language is not important for writing great software, although this can certainly help.
Problems in your knowledge will be patched up in battle. There is no point in memorizing books - it will not help you.
A lesson not enshrined in blood is poorly learned.

Answer 3

This attempt will be tantamount to reading TSB, why do you need this? In the beginning, don't bother at all. This is still a reference book, and there is no point in reading reference books just like that, so there is a need for something specific, then it’s worth looking for and that’s it.

Answer 4

These are different things.
All documentation is read in order to know what the language is capable of, and not to reinvent the wheel with crutches.
Along the way, they look into it to remember this and that (although with modern IDEs this is not so relevant already)

Answer 5

1. How to read the specification correctly? Did the people who know her directly pick up the document and read it cover to cover?

The first time you read from cover to cover, the rest of the time you just remember, moving on to the right points. The knowledge that such and such a clause is in the standard appears after the first time. You can memorize something, but then you still won’t remember anything, because it is not used. The brain gradually erases what is not used.
This topic is a bit broader than just reading from cover to cover. There is the first language when you don't know what can be in the language and its library of functions. So the first language you study completely. But the rest of the languages ​​you learn contain similar elements or even the same ones. Therefore, for example, you read the semantics of the split () function for a string in the first language, studied it all (wrote a bunch of examples and ran them many times), and then in the other languages ​​\u200b\u200bthat you study, you see the same function and you don’t need to read about it, because you are making connections (analogies) with your first split() function. Therefore, the more fully you read about this function somewhere in the beginning, the less you have to read about it later. This is how knowledge is accumulated. Then there comes a moment when you no longer know what you don't know, because you already know everything,
Now, if you start reading what you already know, you need to change the record. So this material is for beginners and you need other material, more serious.