Towards a more powerful and simpler C++ with Herb Sutter
-
I'd call it ++C++
-
-
C++++ => C++ => C#
++:confused:
In order to understand recursion, you must first understand recursion.
That would be one of the stories I heard. Not sure if it was apocryphal though.
TTFN - Kent
-
That would be one of the stories I heard. Not sure if it was apocryphal though.
TTFN - Kent
-
In the article, Sutter is quoted "I decided to focus my work on seeing if I could find ways to make C++ programs simpler." He has a very funny concept of simpler. I like the scrutiny the standards committee gives to new features and most the features of C++11/14/17 and proposed for C++20 are very good. Unfortunately, it seems that some members of the standards committee have fallen into the trap of thinking that inventing new C++ features has value in, and of, itself. They're losing, or have lost, touch with doing actual programming for a living. If they have time for some of these features, great (I can ignore them), but not if it pushes out practical and much needed things, like atomic shared pointers and networking (the delay of this is nuts.)
-
In the article, Sutter is quoted "I decided to focus my work on seeing if I could find ways to make C++ programs simpler." He has a very funny concept of simpler. I like the scrutiny the standards committee gives to new features and most the features of C++11/14/17 and proposed for C++20 are very good. Unfortunately, it seems that some members of the standards committee have fallen into the trap of thinking that inventing new C++ features has value in, and of, itself. They're losing, or have lost, touch with doing actual programming for a living. If they have time for some of these features, great (I can ignore them), but not if it pushes out practical and much needed things, like atomic shared pointers and networking (the delay of this is nuts.)
I absolutely disagree on this one. Metaclasses have the promise of being able to write libraries that can drastically reduce the amount of boilerplate code needed to accomplish some common tasks, and help remove the need for resorting to macros. Authoring them may be challenging, but I'm hopeful we'll see many libraries using them to simplify work for the majority of users.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
-
I absolutely disagree on this one. Metaclasses have the promise of being able to write libraries that can drastically reduce the amount of boilerplate code needed to accomplish some common tasks, and help remove the need for resorting to macros. Authoring them may be challenging, but I'm hopeful we'll see many libraries using them to simplify work for the majority of users.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
I'm probably being too harsh and will probably end up using them [metaclasses], however the concept still seems half baked and more theoretical than practical at this point. That said, I still maintain that the standards committee does a poor job at prioritizing new features, with too much emphasis placed on "cool" new things at the expense of things that could be used immediately and with great effect. That filesystem took so long was absurd and the delay in networking even more absurd. The lack of array_view makes no sense and the lack of comprehensive date handling creates a portability stumbling block. (Atomic shared pointers is another much needed feature.)
-
I'm probably being too harsh and will probably end up using them [metaclasses], however the concept still seems half baked and more theoretical than practical at this point. That said, I still maintain that the standards committee does a poor job at prioritizing new features, with too much emphasis placed on "cool" new things at the expense of things that could be used immediately and with great effect. That filesystem took so long was absurd and the delay in networking even more absurd. The lack of array_view makes no sense and the lack of comprehensive date handling creates a portability stumbling block. (Atomic shared pointers is another much needed feature.)
I can sympathise, but considering that the committee is entirely staffed on an unpaid basis, I think that they can work on whatever they feel like. There are separate working groups for the language and libraries, and most of the activity you describe is in the libraries area. However, some of the new language features will hopefully make it easier to develop libraries too, which may speed things along. Concepts, for example, together with many of the recent enhancements such as constexpr enhancements, and reflection, should make it easier to write template libraries. The GSL (Guideline Support Library) does offer
span, which is pretty well what array_view was, and is in the process of standardisation. Of course, if you feel some of the features you complain about are worth it, you can review the activities and contribute time to making them more robust. These things are not easy, and often must move necessarily slowly as its much harder to remove a badly designed feature, as existing code often relies on it. It takes time and effort to write a proposal for designs. Overall, I think the committee gets the balance pretty good overall."If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
I'm probably being too harsh and will probably end up using them [metaclasses], however the concept still seems half baked and more theoretical than practical at this point. That said, I still maintain that the standards committee does a poor job at prioritizing new features, with too much emphasis placed on "cool" new things at the expense of things that could be used immediately and with great effect. That filesystem took so long was absurd and the delay in networking even more absurd. The lack of array_view makes no sense and the lack of comprehensive date handling creates a portability stumbling block. (Atomic shared pointers is another much needed feature.)
You may be glad to know that the Networking group have reached PDTS (published draft technical standard), that means they are now waiting for implementation experience from C++ implementors before moving it into the standard - hopefully in time for C++ 20. [Networking TS^]
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.