C ++ 0x. Not entered

On Habré, articles on the new standard C ++ 0x have already been run through - what is included in it and how to use it. And this article is about what could have entered there, but was rejected for certain reasons.

Concepts

Concepts are such a cool thing that extends the use of templates. In short, the concept allows you to put forward the requirements for the type used in the template. For example, you can require a public constructor and destructor, support for a specific interface, and some other things. There is a thought that concepts could be quite useful - to reduce the number of errors, to avoid foolish compiler messages when working with template types, to give the user understanding of the template type about what this type does with its argument. In general, cool. Something similar is, for example, in C #.
The concepts were removed from draft C ++ 0x in July 2009 with the wording “not ready”. There were several reasons for this:

1. In the proposed form it turned out too fancy. The supplement describing concepts took up one and a half hundred pages (while the rest of the standard was about 800). It was a bit hard. We tried to simplify - but it turned out even worse. Half of the people began to complain that they cut the necessary things, the second - that the rest is still too difficult.
2. A couple of separate groups of programmers in the framework of a personal initiative tried to make the implementation of concepts in the compiler. In GCC, of ​​course. It turned out, for example, this and a couple more options. All of them showed a very mediocre performance both in compilation and in the work of the resulting programs. And not only on examples using concepts, but also on ordinary templates. The implementations were recognized as "proving a theoretical possibility", but not suitable for real use.

For over 2 years, different people tried to do something with all this mess. But 2 years for the entire crowd that is trying to develop a new C ++ standard is just an instant. Nothing was solved. Concepts in the new standard will not be. While everyone is optimistic, they smile and wave. You can read more here .

Garbage collector

Automatic garbage collection in C ++ - this is it, a fertile field for holivar! Sharpen spears, noble Knights of the Mouse and Keyboard, because here you will find a great battle, both among themselves and with a crowd of assorted trolls! Well, it would seem, what nafig garbage collection in the holy of holies - C ++ ?! On the other hand, all those who have learned this forbidden fruit in other languages, with a downcast look, say that it is sweet. On the third, how is it, # $%, implemented in C ++, without undermining either backward compatibility, nor type safety, nor common sense? With the fourth - well, in other languages, somehow solved this problem? Fifth, other languages ​​are for housewives and Hindus, and C ++ is for those who know Tao. In general, somewhere after the 25th thought on this subject, I get lost and forget the beginning. Somewhere on the same plane is the C ++ Standardization Committee. In C ++ 0x the garbage collector will not be.

Modules

You probably know that if you need to create a component (library) for the purpose of its multiple use at the output of your work, you get a * .h file and, in fact, a compiled library (or source files, if you are an open source). In other languages ​​(in the same C #) there is only one artifact at the output - the library itself, which contains self-description of all its types and functions in the metadata. The main idea of ​​module architects in C ++ is to achieve the same. Judge for yourself: the absence of several files automatically gives less chaos, fewer out-of-sync errors, reveals fewer details of the implementation of the code and is generally very convenient. But how can this be used if there are no * .h files? Somehow like this:

import std; // Module import directive. int main() { std::cout << “Hello World\n”; } 

The idea of ​​getting rid of the centuries-old tradition of dividing source code into header files and implementations excites the imagination. The world is not ready for such shocks. In C ++ 0x, do not wait for this feature.
Good document with a description of the venture: www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2316.pdf
')

GUI, Math Special Functions, Networking, File System

Many novice programmers, having passed the “Hello world” stage, are faced with real life tasks and are surprised to note that almost nothing can be done in such a powerful and cool language like C ++ in its basic configuration (compiler + standard library)! Neither you zababahat window, or 2 bytes sent over the network, nor XML parse. All you need is to search for individual libraries, use the operating system API, or manually plow up virgin soil of unwritten code. After that, there are quirks in the spirit of "and let the standard language be able to sing and dance." The opinion of the standardization committee is indestructible. Flies - separately, and cutlets - separately. Some of the things indicated in the paragraph heading are simply thrown overboard, others are planned for consideration in the next TR. In C ++ 0x they will not.

Thread pools, task launching, and reader-writer locks

With a general understanding of the importance of parallel programming (and one must admit that in C ++ 0x, a lot of things were added specifically for him), there is no possibility to implement all possible ideas. Those. I would very much like to, but the standard will have to be postponed for another 5 years. But the release date is already outlined, the red ribbons are stretched, the vodka on the buffet tables is heated, and the roast cools down. So, at a meeting in the city of Kona, the “compromise of Kona” was adopted, which, among other things, threw out of the standard pools of streams and some other cool things, promising, however, to consider them in the next TR or standard.

Macro scopes

In the frequently asked questions on the Stroustrup page you can read his criticism of macros . In general, it is similar to the thoughts of grandmothers at the entrance about contemporary youth: the macros, they say, do not know any boundaries, they don’t care for all areas of visibility, classes, namespaces and everything else. This disrespect and transition of frames is often fraught with both conflicts of macros and good old code, and, sometimes, the macros themselves with each other. It would be good to explain to these upstarts their place in the sandbox and designate its framework. It should look well, at least that's it .
Frankly, I did not find information about why this venture was not included in the standard. It seems to me that no one really understood the details of the interaction of these very regions and the good old #define and #undef directives. Somehow it is all unintuitive. In general, so far this thing in C ++ 0x will not.

Reflection

Those who know what it is, in this place shuddered. For those who do not know, I will explain - this is a way to obtain and manipulate information about the types of data and their insides for all mercenary purposes. You can find out if there is a method in the class with a specific signature, or change the method code “on the fly” or call a private class method from the outside or something else to do. This stuff is very useful when developing various loggers, mocks, plug-ins and other things. And, as it were, there are no objective reasons for the lack of reflection in C ++ - all the necessary information is in the code, it is available to the compiler and it could be obtained at runtime. At least, Stroustrup sees no obstacles for this. But it is clear that someone else sees it. So there will be no reflection in C ++ 0x.

findings

Cathedral and Bazaar

With regret, I would like to note that the collective work on the C ++ standard, unlike many other collective projects, goes to the C ++ language rather to harm than to benefit. If in C # and other languages, behind which large corporation creators stand, everything is solved individually and from the generation of a new idea to its realization a year goes by from force, then in C ++ there are some thoughts on which they cannot agree for 10 years. 12. The bazaar is the bazaar, and the cathedral is the cathedral. Nevertheless, life does not stand still, papers are transferred from folder to folder, email postmen carry e-mails and you and our grandchildren have the chance to see all the “live” things described in the article.

Deja vu

In the process of writing this article, the feeling of deja vu did not leave me. Somewhere I have already seen it all! But where? Oh yeah - in C ++ / CLI! In fact, C ++ managed, a strange brainchild of Microsoft, created not even as a new language, but as a bridge between the old C ++ code and the .NET platform, has almost everything described in the article - both concepts and garbage collection , and modules, and all the power of the .NET class libraries and Reflection. But it never helps him - no one will start a new project on pure C ++ / CLI (C # and VB are much more convenient), the language has occupied its niche exactly where Microsoft planned - in projects it is necessary to use the old code in C ++ and .NET. The fun thing about it all is not even the fact that Microsoft has managed alone, for garbage of time, to do what the transnational alliance has been picking for a decade and a half. Scary, what will happen next. There are 3 options:

1. The community accepts the Microsoft implementation as the standard of all the things described. It is humiliating, and therefore unlikely.
2. Conversations are delayed for another decade. The language is slowly deflating under the onslaught of more dynamic colleagues.
3. The Alliance accepts its own implementation of concepts, garbage collection, etc. with a different syntax. This is the most apocalyptic version, since the same things will be implemented differently in different dialects of the language. And this is kapets.

In general, wait and see how it will be. Write in C ++ and may the force be with you!