C ++ 0x. Not included
On Habré articles on the new standard C ++ 0x already ran through - what enters into 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. If very briefly, then the concept allows us to put forward requirements for the type used in the template. For example - you can require the presence of a public constructor and destructor, support for a specific interface and some other things. There is an idea that concepts could be very useful - reduce the number of errors, avoid stupid compiler messages when working with template types, give the user an 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 the draft C ++ 0x in July 2009 with the wording “not ready”. There were several reasons for this:
- In the proposed form, it turned out too tricked out. The supplement describing the concepts took one and a half hundred pages (despite the fact that the rest of the standard is about 800). It was a bit complicated. They tried to simplify it - but it turned out even worse. Half of the people began to complain that they had cut the necessary things, the second - that the rest was still too complicated.
- A couple of separate groups of programmers, as part of a personal initiative, tried to implement the concepts in the compiler. At GCC, of course. It turned out, for example, this and a couple more options. All of them showed 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. Implementations were recognized as "proving a theoretical possibility", but not suitable for real use.
Garbage collector
Automatic garbage collection in C ++ - here it is, a fertile field for holivar! Sharpen your spears, the noble Knights of the Mouse and Keyboard, because here you will find a great battle both among themselves and with a crowd of different trolls! Well, it would seem, what for garbage collection in the holy of holies - C ++ ?! On the other hand, everyone who knows this forbidden fruit in other languages, having looked down, notes that it is sweet. With the third - how to implement it, # $%, in C ++, without breaking either backward compatibility, or type safety, or common sense? With the fourth - well, in other languages, did you somehow solve this problem? Fifth, other languages are for housewives and Indians, and C ++ is for those who know Tao. In general, somewhere after the 25th thought on this subject, I go astray and forget the beginning. Somewhere in the same plane isand C ++ standardization committee. In C ++ 0x there will be no garbage collector.Modules
You probably know that, if necessary, create a component (library) for reusable use at the output of your work, you get a * .h file and, in fact, a compiled library (well, or source, if you are for opensource). At the same time, in other languages (in the same C #) there is only one artifact at the output - the library itself, which contains in the metadata a self-description of all its types and functions. 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 desync errors, reveals fewer details of the code implementation and is generally very convenient. But how can this be used if there are no * .h files? Something like that:import std; // Module import directive.
int main() {
std::cout << “Hello World\n”;
}The idea to get rid of centuries-old tradition of dividing the source into header and implementation files excites the imagination. The world is not yet ready for such shocks. In C ++ 0x, do not expect this feature.
A good document describing the undertaking: www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2316.pdf
GUI, Math Special Functions, Networking, File System
Many beginning programmers, having passed the “Hello world” stage, are faced with real life tasks and are surprised to note that in such a powerful and cool language as C ++ in its basic configuration (compiler + standard library) you can do almost nothing! You shouldn’t get a window bogged down, send 2 bytes over the network, or parse XML. All you need is to search for individual libraries, use the operating system API or manually plow the virgin lands of unwritten code. Then there are kooky in the spirit of "and let the language as a standard will be able to sing and dance." The opinion of the standardization committee is unbreakable. Flies - separately, and cutlets - separately. Some of the things indicated in the heading of the paragraph are simply thrown overboard, others are planned for consideration in the next TR. In C ++ 0x they will not be.Thread pools, task launching, and reader-writer locks
With a common understanding of the importance of parallel programming (and we must admit that in C ++ 0x a lot of everything was added just for it), there is no way to implement all possible ideas. Those. I would really like to, but I have to postpone the release of the standard for another 5 years. But the release date has already been set, the red ribbons are pulled up, the vodka on the buffet tables is heated, and the hot - it cools down. So at a meeting in the city of Kona, a “compromise of Kona” was adopted, which, among other things, threw out pools of threads and some other cool things from the standard, promising, however, to consider them in the next TR or standard.Macro scopes
In frequently asked questions on the page of the Stroustrup you can read his criticism of macros . In general, it is similar to the thoughts of grandmothers at the entrance about modern youth: macros, they say, do not know any boundaries, they do not care about all areas of visibility, classes, namespaces and all that This disrespect and the transition of the framework is often fraught with conflicts between macros and good old code, and sometimes the macros themselves with each other. It would be nice to explain to these upstarts their place in the sandbox and outline its scope. It should look just like that .Honestly, I did not find information on why this idea was not included in the standard. It seems to me that no one really understood the details of the interaction of these same regions and the good old #define and #undef directives. Somehow it is all unintuitive. In general, so far this thing will not be in C ++ 0x.
Reflection
Those who know what it is, startled in this place. For those who don’t know, I’ll explain - this is a way to obtain and manipulate information about data types 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 the private method of the class from the outside, or do something else. This thing is very useful in the development of various loggers, mocks, plugins 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, the compiler has it and it could be obtained on runtime. At least Straustrup does not see any obstacles for this. But apparently, someone else sees. So there will be no reflection in C ++ 0x.conclusions
Cathedral and Bazaar
With regret, I want to note that the collective work on the C ++ standard, unlike many other collective projects, goes to the C ++ language rather to the detriment than to the advantage. If in C # and other languages, which are supported by large corporations-creators, everything is solved individually and a year passes from the generation of a new idea to its implementation, then in C ++ there are some thoughts that cannot be agreed upon for 10 years already 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, e-mail carriers carry emails and Deja vu
In the process of writing this article, I did not leave the feeling of deja vu. Somewhere I already saw it all! But where? Oh yes - in C ++ / CLI! In fact, managed by C ++, Microsoft’s weird offspring, created not even as a new language, but as a “bridge” between old C ++ code and the .NET platform, has almost everything described in this article - both concepts and the garbage collector , and modules, and all the power of the .NET and Reflection class library. It just doesn’t help him once - nobody will start a new project in pure C ++ / CLI (C # and VB are much more convenient), the language has taken its place exactly where Microsoft planned - in projects with the need to use the old code in C ++ and .NET. It’s fun in this, it’s not even that Microsoft alone managed to do the thing that the transnational alliance has been picking for a decade and a half. It’s scary what will happen next.
- The community takes Microsoft's implementation as the standard for all of the things described. This is humiliating, and therefore unlikely.
- Conversations drag on for another decade. The tongue is slowly blown away under the onslaught of more dynamic colleagues.
- The Alliance accepts its own implementation of concepts, garbage collectors, etc. with a different syntax. This is the most apocalyptic option, because the same things will be implemented differently in different dialects of the language. And this is kapets.