This sounds to me like "we will make it simpler by adding more features (that are presumably simpler to reason about)." The problem with C++ (and the reason that it is too complex) is that it has too many features. This proposal will do nothing to eliminate all of the cruft, the real source of complexity. That would require actually removing features, backwards-compatibility be damned!
I rarely see anyone present well thought out specifics of what should be removed from the language when making these types of claim. There are some complex areas (two phase name lookup springs to mind) that might be done differently if designed anew but I haven't seen too many good examples of things that could be "easily" removed, backwards compatibility be damned, that I have found to be actual problems in practice. The best examples are usually legacies of C.
Yeah Metaclasses in Python are obviously so powerful and make programs so easy to read, so let's just go ahead and add those as well. Now we only write struct Point { int x; int y; }; to get the oh-so-needed class Point { private: int x; int y; public: Point() =default; ~Point() noexcept =default; Point(const Point&) =default; Point& operator=(const Point&) =default; Point(Point&&) =default; Point& operator=(const Po…
You can still write the former and it's just fine.
Yeah Metaclasses in Python are obviously so powerful and make programs so easy to read, so let's just go ahead and add those as well. Now we only write struct Point { int x; int y; }; to get the oh-so-needed class Point { private: int x; int y; public: Point() =default; ~Point() noexcept =default; Point(const Point&) =default; Point& operator=(const Point&) =default; Point(Point&&) =default; Point& operator=(const Po…
You can still write the former and it's just fine.
This sounds to me like "we will make it simpler by adding more features (that are presumably simpler to reason about)." The problem with C++ (and the reason that it is too complex) is that it has too many features. This proposal will do nothing to eliminate all of the cruft, the real source of complexity. That would require actually removing features, backwards-compatibility be damned!
Looking at this post https://news.ycombinator.com/item?id=15613848 , I wonder if it could help to simplify C++ by moving some of the existing features into libraries, which you would have to include for backwards compatibility, but could do without if you didn't need backwards compatibility.
Backwards compatibility in C++ means "your existing code still compiles and does the same thing". Can you give an example of a situation where that could be achieved with your proposal?
You can still write the former and it's just fine.
Except, I need to think the latter?
Not for a Plain Old Data (POD) type. You need to think about the latter if you're manually managing memory or OS resources in your class (which should be rare) or you're trying to optimize performance when you have members that can be moved more cheaply than copied (usually because they manage memory) which should also usually be rare and the result of identifying a performance issue through profiling.
Simplifying every day usage is entirely a different thing than simplifying the language. I’m not denying the inprovement in usage, just that you should expect the complexity of the language to continually increase because that’s the needs of the c++ community.
My question then is why should I care about "increased complexity" by this definition more than about "simpler usage"? Adding well thought out language features that simplify my every day usage is a good thing and the sense in which it increases complexity is not a sense that particularly concerns me. I think C++ is generally making good choices about what features to add. Generic complaints about new features tautol…
Agreed. You have to choose between "large scale removal of features from the language" vs "30+ years of back-compat". You can't have both. A huge strength of C++ is it's legacy and the maintainers would be foolish to throw that away in a C++ 2.0 movement.
Instead, they add new features that lets new code be written in new ways without requiring you to toss out your old code. Your old C code is full of mallocs and frees. Your old code still works when you partially update it using the newest features. But, once C++ added new and delete, you rarely ever needed to type malloc or free any more unless you were overloading new and delete. Your old C++ code is full of news and deletes, but new language features added in C++11 made unique_ptr and shared_ptr possible. And, now you rarely need to type new or delete unless you are making your own unique_ptr/shared_ptr variant.
Interesting; i think it’s fairly clear by now engaging with C++ is not going to lead to reduced complexity at all. When was the last time it removed support for a feature? That’s not what the language needs because it’s more interested in preserving existing code bases than it is at improving them (the latter being a huge effort, truly massive, so i understand the decision and don’t mean it as a slight in the least).
C++17 removed trigraphs. C++17 removed dynamic exception specification which is deprecated since C++11. C++17 removed operator++ for bool which is deprecated since C++98. C++17 removed the “register” storage class.
Simplifying every day usage is entirely a different thing than simplifying the language. I’m not denying the inprovement in usage, just that you should expect the complexity of the language to continually increase because that’s the needs of the c++ community.
My question then is why should I care about "increased complexity" by this definition more than about "simpler usage"? Adding well thought out language features that simplify my every day usage is a good thing and the sense in which it increases complexity is not a sense that particularly concerns me. I think C++ is generally making good choices about what features to add. Generic complaints about new features tautol…
Why would you care? Well the complexity makes tooling difficult, the engineers expensive, and arguably ongoing development could be slower depending on how many c++ features they have to deal with in one code unit. Are these any strikes against the language itself? No, of course not, but one can see why e.g. using go instead might afford more flexibility if the underlying c++ distinguishing features aren’t necessary. The language complexity is still something to consider even if c++ is sufficient.
I am by no means arguing that C++ committees are making any mistakes.
My question then is why should I care about "increased complexity" by this definition more than about "simpler usage"? Adding well thought out language features that simplify my every day usage is a good thing and the sense in which it increases complexity is not a sense that particularly concerns me. I think C++ is generally making good choices about what features to add. Generic complaints about new features tautol…
Why would you care? Well the complexity makes tooling difficult, the engineers expensive, and arguably ongoing development could be slower depending on how many c++ features they have to deal with in one code unit. Are these any strikes against the language itself? No, of course not, but one can see why e.g. using go instead might afford more flexibility if the underlying c++ distinguishing features aren’t necessary.…
I don't think we disagree on much. Jonathan Blow is of the opinion that what games programmers need is a new language designed from scratch, in part because he believes the most viable (and dominant) language used for games, C++, is irredeemably complex. I recognize that there are complexities to C++ but I'm of the opinion that it's been getting better and will continue to do so for games development and that the new features in practice are making the language simpler to use even if technically they are making it "more complex" in the sense of having more features. The tooling is also getting better, despite the complexity, and Clang has played a big part in that. The case for switching to a different language is not compelling to me, especially to a completely new language rather than something with some track record.
The interview covers proposed metaprogramming features in upcoming versions of C++. In particular, it demonstrates metaclass as a way for users to define new kinds of types, instead of relying solely on class / struct / union / enum . For example, Java has an interface , in which methods are declared but not defined. The proposal for metaclass gives a demonstration of what an interface in C++ could look like: interfa…
That is not a step toward simpler code. Under that proposal, people looking at your code will have to look up definitions of basic things that ought to be keywords---like "interface"---in order to reason about the code.