As I wrote the proposal for the C ++ standard

    This will be the story of a junior developer from Yandex.Passport about the appearance of a proposal in the C ++ standard, developed in collaboration with Anton antoshkka Polukhin. As often happens in life, something new began with pain, or rather, with the desire to stop it.


    Once upon a time there was a library at my support. Everything was fine with her: going under Linux, working, not crashing. Once people came with a request (requirement) to assemble it under Windows. Why not? But the first time did not work. The root of the evil was handwritten cryptography, which at some point multiplied two 64-bit integers. To save the result of such a multiplication, a 128-bit number is required, and the type __int128 was used in the library. It is beautiful: it has a natural interface, is supported by several compilers (gcc, clang), it works without memory allocation, but the main thing is that it is.

    The Microsoft compiler developers did not provide support for this type, did not come up with any analogues - or I did not find them. The only cross-platform solution that came to mind is Big Numbers from OpenSSL, but it is somewhat different. As a result, I specifically solved this problem with a "bicycle": only uint128_t was needed with a limited set of operations. From several foreign solutions, I assembled the UInt128 class, put it in the library sources. “Bicycle” is just that pain. The task was solved.

    In the evening of the same day I went to unwind at an event where people from Working Group 21 (WG21) talked about how they process a C ++ file. I listened and wrote to cpp-proposal@yandex-team.ru a short letter of two sentences on the topic “I need int128 in cpp”. Anton Polukhin in response told that the developers of the standard want to solve this problem once and for all. It is logical: now I needed a 128-bit number, and someone needs to work with 512-bit numbers - and this someone also wants a convenient tool.

    Anton also said that there are two ways to solve: through the core of the language and through the library. There is an opinion, and I share it, that the syntax of the language is already quite complicated: adding a construct to the language that will provide cross-platform and efficient ability to use numbers of different accuracy will be very difficult. But in the framework of the library it’s quite possible to cope: templates are our everything. “We need a working prototype,” said Anton. “And preferably with tests.” It also turned out that the type must be plain old data (POD) to appeal to more people.

    And I went to make a prototype. The name wide_int was chosen consciously: there are no stable associations with this name, in any case - widespread. For example, big_number could be misleading - they say it stores the value on the heap (heap) and never overflows. I wanted to get a type with behavior similar to the behavior of fundamental types. I wanted to make a type the size of which will continue their progression: 8, 16, 32, 64 ... 128, 256, 512, etc. After some time, a working prototype appeared. It was not difficult to make it: it had to compile and work, but not necessarily really efficiently and quickly.

    Anton studied it, made a number of comments. For example, there was not enough conversion to floating-point numbers, you had to mark the maximum number of methods as constexpr and noexcept. Anton dissuaded me from the idea of ​​limiting the choice of the size of the number: I made a multiple of 64. After that, together with Anton, we wrote the text of the proposal itself. It turned out that writing a document is much more difficult than writing code. A little more polishing - and Anton (as the only one who understands what to do next) began to show our offer to people from the standardization commission.

    Criticized a bit. For example, someone expressed a desire to make an integer type that does not overflow. Or a type whose size can be set accurate to bits (and get, for example, a size of 719 bits!). The proposal to refuse to be tied to the number of bits, but to set the number of machine words, seemed to me the strangest: business logic doesn’t care how many words are in the number on some platform - it is important for it to unambiguously determine the same numbers on different platforms. Say a unique user identifier is an unsigned integer of 64 bits, not one unsigned long long.

    In a nutshell, these were ideas for other types. We listened to criticism, there were no significant comments. After that, Anton published a proposal for a standard and went to defend it at the next meeting of the commission..

    The defense was successful: our proposal was put to work - in other words, it will be considered at meetings and beyond. A number of comments were made; Now we are making the necessary corrections. In particular, the commission nevertheless asked to use the number of machine words in wide_int. The argument is simple: the type will be implemented one way or another, but if you use these very machine words, it will be more efficient. I still have the hope that the convenient alias uint128_t will fall into the standard - then I can throw out my UInt128 type before someone else sees it. =) The

    current version of the implementation can be found here . There is also a document and a small discussion on stdcpp.ru. In total, about four months have passed since the day the first letter was sent to cpp-proposal@yandex-team.ru. Of these, about 40 hours of non-working time I spent on this proposal. At the time of writing, the implementation has swelled to 1622 lines, and even tests have added 1940 lines.

    I consider it important to tell that all this gives me. Firstly, it is interesting to learn how the decision-making process is built and what is important when designing interfaces in the standard library.

    Secondly, I can change C ++ in the direction that I like. Of course, it is important to remember that for the realization of any major idea like-minded people are needed. For example, there is an idea to make the interface for containers and strings a little more expressive and obvious: I wanted to add operator bool () to the containers. But colleagues indifferent to C ++ made it clear that Iwrong .

    Thirdly, I learned a lot about the templates in C ++.

    Fourthly, they say that it will somehow strengthen my resume ... I haven’t checked it yet, but I will take my word for it from experienced colleagues.

    Fifth, when Bjarne Straustrup writes somewhere “+1” to someone in a correspondence dedicated to discussing your work, it’s fun. =) Even if he supports someone’s criticism.

    In the end, I’ll say that you can find out about the news and events of RG21 C ++ by subscribing to stdcppru on Twitter .

    Also popular now: