Bjarne Stroustrup wrote the following a few minutes ago on the concepts mailing list:
Let me take this opportunity to remind people that
- "being able to do something is not sufficient reason for doing it" and
- "being able to do every trick is not a feature but a bug"
For the latter, remember Dijkstra’s famous "Goto considered harmful" paper. The point was not that the "new features" (loop constructs) could do every goto trick better/simpler, but that some of those tricks should be avoided to simplify good programming.
Concepts and concepts lite are meant to make good generic programming simpler. They are not meant to be a drop-in substitute for every metaprogramming and macroprogramming trick. If you are an expert, and if in your expert opinion you and your users really need those tricks, you can still use them, but we need to make many (most) uses of templates easier to get right, so that they can become more mainstream. That where concepts and concept lite fits in.
Some of you may find this hard to believe, but "back then" there was quite serious opposition to function declarations because "they restricted the way functions could be used and the way separate compilation could be used" and also serious opposition to virtual functions "because pointers to functions are so much more flexible." I see concepts lite (and concepts) in the same light as goto/for, unchecked-function-arguments/function-declarations, pointers-to-functions/abstract-classes.
Reminds me of the related antipattern: “Something must be done. This is something. Therefore we must do it!”
Sutter’s Mill 
@Jeremy.
Microsoft has such compilers for the Singularity project and now for Windows Phone 8 apps.
And Xamarin has it for Mono.
I think it is just a political issue inside Microsoft dev units not investing in such a compiler for the desktop.
Not sure why, continually, language and runtime keep getting confused. C# is a fantastic language, the .NET runtime is the slow part. If a native C# compiler were developed, C# could be just as good as C++. C++ only benefit is old (well tuned) compilers which generate native code.
I believe the statement “being able to do something is not sufficient reason for doing it” neatly encapsulates (pun intended) a great deal of the controversy associated with C++. More than most other languages, C++ is incredibly flexible in its allowing varations of its constructs and features (e.g., overloaded operator overloading). This is all well and good, but the question arises, is it necessary to use the most complicated construct when a simpler one would achieve the same purpose within the same restrictions (memory, performance, etc.)? I have seen a lot of C++ code which I believe is unnecessarily complicated because the writer was more interested in showing off their knowledge of the language’s features than solving the problem at hand. It appears to me that for these people using the language has become an end itself, not a tool to accomplish a task. On a more pragmatic level, the use of complex constructs tends to increase maintenance costs in terms of modification effort, breakage risk, and required retesting. This is supported by the fact that in general the same code is read more often than written.
Also, my experience has been that the further into the obscure feature realm you venture the less likely it is that different compilers will produce the same results.
I am not one of those who thinks C++ has too many features or should be simplified. I do believe, however, that in a production environment the simplest constructs that meet the required performance, modularity, and expandability goals should be used. I definitely agree that this is a difficult balance to strike and it requires much more analysis than I am able to provide :).
@Jack:
I really hope that was a joke linking Google’s C++ style guide…
I think that concepts in combination with modules could open up a whole new style of programming, at least new to C++. So far, templates basically break the compilation model, that’s a given. Concepts will do so as well, because even for concepts the compiler needs to know the “real” type. But in combination with modules what we could end up with is a way to write most of the code generic, because it doesn’t have the bitter aftertaste of current generation templates. Therefore, one really could write against interfaces and not types – without losing performance. (Making everything virtual is often not a viable choice.) The question on how two express relations between two types, I think, is sadly still not completely solved, but with static if one could do fine here as well. :)
“C++: The Good Parts”:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
quote: Scott Meyers (2005)
Q: Every language has its flaws. What are the three things you dislike most strongly in C++?
I’d like to answer this question with “complexity, complexity, complexity!”, but naming the same thing three times is cheating. Still, I think that C++’s greatest weakness is complexity. For almost every rule in C++, there are exceptions, and often there are exceptions to the exceptions. For example, const objects can’t be modified, unless you cast away their constness, in which case they can, unless they were originally defined to be const, in which case the attempted modifications yield undefined behavior.
As another example, names in base classes are visible in derived classes, unless the base class is instantiated from a template, in which case they’re not, unless the derived class has employed a using declaration for them, in which case they are.
Such complexity affects more than just people who write programs in C++. It also affects people who want to write tools that analyze C++ programs. One of the reasons why there is a relative dearth of tools such as refactoring browsers for C++ is that C++ is just so darned complicated.
A related aspect of C++ I dislike has to do with what I perceive to be an attitude on the part of the standardization committee that such complexity is not a problem. I suspect that many members of the committee would object to my characterizing their attitude that way, but I’m talking only about my perception of their attitude. I know that the people on the committee work hard to make C++ as good as it can be. I also know that there are proposals before the committee whose goal is to simplify C++. Still, my impression is that the committee as a whole is unsympathetic to arguments that C++ has become too complex, and I find that frustrating.
c++ 2011: take the new stuff, embrace it. Each time you find something that can replace C++98 idioms, use the new one, it’s better.
The stuff left from C++98 to C++11 is just there for legacy: don’t break the old code.
Forget about the old arrays, forget about char *, forget about explicit iterators. Pass by value, embrace the move semantics.
Clean, simple and fun
> > We’re long overdue for “C++: The Good Parts”.
> Also from Bjarne Stroustrup: “Within C++, there is a much smaller and cleaner language struggling to get out”.
Also from Bjarne Stroustrup: “Programming — Principles and Practice Using C++”.
> We’re long overdue for “C++: The Good Parts”.
Also from Bjarne Stroustrup: “Within C++, there is a much smaller and cleaner language struggling to get out”.
Tito – Absolutely correct! Barring auto and support for parallel the new c++ represents an even better environment for bad and complicated code and more long nights for the maintenance guys in the future. We really do need the best of C++ preferably as a standard such a c++ 11 g ( for good). This time keep the gurus off the panel just the people who have to clean up the mess to define the good bits. Locked in a room guess it would take less than a week before white smoke would be seen!
“Something must be done. This is something. Therefore we must do it!”
a.k.a. the politician’s fallacy
Giving a programming language too many features and too much flexibility is how you end up with one of the best books for the language being named: “Javacript: The Good Parts”.
Crockford correctly espouses that much of JS should just not be used. (Amusingly, he puts the ++ operator pretty high on the “do not use” list.) However, if you do restrict yourself to “the good parts”, you can end up with a clean system using the langauge.
We’re long overdue for “C++: The Good Parts”.
“being able to do every trick is not a feature but a bug”
Very, very good point. Something similar occurred during recent standard proposal discussion; a concern was raised over a single class abstracting two back-end versions – very nice to have from interface abstraction/simplification standpoint but imposes significant space (4x) overhead for the smaller back-end; a real-world scenario of million objects not fitting into a CPU cache surfaced. That’s a problem, for sure. However, is the culprit (a) the object size or (b) trying to put too many of them into a small space at the same time.
A real world example: housing for one million persons.
Solutions: A 100,000-story skyscraper? Mandate each person to dwell in 2 square feet? Build a city?
“Something must be done. This is something. Therefore we must do it!”
Ran into the same. Dev in question wanted to remove some legit new code because it was crashing. The new code *was* legit, the problem is in some outer frame and the new code just happens to smoke it out. There’s no convincing some people.