Slashdot Mirror
C++ Creator Wants To Solve 35-Year-Old Generic Programming Issues With Concepts (cio.com)
C++ creator Bjarne Stroustrup is arguing that we can improve code by grounding generic programming in concepts -- what's required by a template's arguments. An anonymous reader quotes Paul Krill's report on a new paper by Stroustrup:
In concepts, Stroustrup sees the solution to the interface specification problem that has long dogged C++, the language he founded more than 35 years ago. "The way we write generic code today is simply too different from the way we write other code," Stroustrup says... Currently an ISO technical specification, concepts provide well-specified interfaces to templates without runtime overhead. Concepts, Stroustrup writes, are intended to complete C++'s support for generic programming as initially envisioned. "The purpose of concepts is to fundamentally simplify and improve design. This leads to fewer bugs and clearer -- often shorter -- code"...
Concepts, Stroustrup believes, will greatly ease engineers' ability to write efficient, reliable C++ code... The most obvious effect will be a massive improvement in the quality of error messages, but the most important long-term effect will be found in the flexibility and clarity of code, Stroustrup says. "In particular, having well-specified interfaces allows for simple, general and zero-overhead overloading of templates. That simplifies much generic code"
Concepts are already available in GNU C Compiler 6.2, and Stroustrup wants them to be included in C++ 20. "In my opinion, concepts should have been part of C++ 17, but the committee couldn't reach consensus on that."
Concepts, Stroustrup believes, will greatly ease engineers' ability to write efficient, reliable C++ code... The most obvious effect will be a massive improvement in the quality of error messages, but the most important long-term effect will be found in the flexibility and clarity of code, Stroustrup says. "In particular, having well-specified interfaces allows for simple, general and zero-overhead overloading of templates. That simplifies much generic code"
Concepts are already available in GNU C Compiler 6.2, and Stroustrup wants them to be included in C++ 20. "In my opinion, concepts should have been part of C++ 17, but the committee couldn't reach consensus on that."
Well, when I was thinking about programming languages a long time ago, I have come to a grudging respect for Windows, and backwards compatibility. Really good compilers, IDEs and debuggers will take many man years before production code can be made. In order to get that fancy stuff, you need a really big market to justify all that expensive development. That god scripting languages don't require such complicated tooling, and one has choices. I'm looking at you Javascript!
I used to be a C/C++ dev, and wrote a lot of COM objects for the financial space back in the day. The ten different ways to cast something was becoming a pain to deal with. .NET/C# for my company in about 2001, liked what I saw and moved over to C# with a short stint in Java along the way, and I have NEVER looked back.
Writing LOB applications is all about delivering functionality for the end user. In C# I've designed the most, developed the most and maintained the most applications I've ever managed to do in my 30 year career in software development.
I was tasked to evaluate
Beautiful generics, LINQ, clean looking code, interoperability with legacy code, ultra-rich APIs and a rock-solid dev environment, ECMA-standardised are clear winners for me and C#.
A greybeard trying to breathe new life onto a now 30 year old language he put together doesn't surprise me, but C++ is never going to get the attention it once had. Sorry Bjarne, I saw it all before with Bertrand Meyer trying his darndest to keep Eiffel relevant. Same thing's happening with your baby, sorrry to say.
Really. After doing a little Ada programming, or even java with interfaces, not having a hard separation between interface and implementation is infuriating.
[...] you're one of those so-called "hard core" C guys, who had a look at C++ for 5 minutes back in early-to-mid-nineteen-ninety-whatever, didn't understand it, and decided that therefore it was a stupid language for all time.
That would describe me. When I went looking for a book about compilers, I recently ordered a used copy of "Writing Compilers and Interpreters" by Ronald Mak. I got the 1991 edition because it was written in Borland C and easier to translate into a modern dialect of C. According to the reviews, later editions used C++ that's almost impossible to translate into a modern dialect of C++. Long live C!
I found it easy when I learnt it too. Then I studied it a bit more, used it a whole lot more, and realised I was wrong and it was in fact a rather complex and obscure beast.
Richard Feynman and Albert Einstein both did exactly this. You really can't understand quantum mechanics or general relativity without math. You can think you do, and both of them were great at providing simple explanations that gave the illusion of understanding... but it was only an illusion, which of course they knew perfectly well.
I don't know about Einstein, but Feynman was also good at explaining things using math in a way that gave a typical physics student the illusion that you understood it. But that was only an illusion, as when you got back to your dorm room to do the homework you realized that he explained it in a way that you could not replicate because to him the math (usually path integrals) was so intuitive that he could breeze through it on the chalkboard, but you would actually have to grunge out the calculus because of your relative ignorance. Even the TAs weren't able to help you understand it the way he explained, but they would usually also have to grunge out the math to explain it to you.
It was then you realized that not only was he good at explaining things at a high level that gave you the illusion of understanding, but he knew the stuff so thoroughly in a way that you only wish you could understood it, someday.
Even in Physics X, he always had a few mathematical gems that seemed completely unrecreatable outside the lecture room. And if you ever heard him describe his techniques to pickup women, well, those were also something you might think you understand, but were totally unable to replicate later either... ;^)
I've been playing around with D for a year or so and it features 99% of the stuff you wish C++ had. Modules are one of them.
Plenty of the features in D end up in C++... except (literally) more than ten years later.
The same thing everyone always bitches about D (as a reason for not trying it), is the garbage collector. But GC isn't actually required and can be disabled entirely or for critical sections. The standard lib uses GC but there's no reason someone couldn't bother to write an identical GC-free one... there's just no incentive for the existing community. You can also use data types that are not seen at all by the garbage collector and go RAII till the sun goes down. The power is yours to decide.
Don't get me wrong, it's not a perfect language. But the language itself is .1% of the problems you'll encounter. The other 99.9% of the problem is the relatively small (but very helpful!) community, lack of tutorials and references, relative lack of D-specific libraries. When Javascript, C#, C++ and whatnot, you can literally google "C" + [any topic], and get pages of tutorials with great ones at the top. With D, there are much fewer and you'll end up with questions that don't have easy Google answers like "What does double colons mean here?"
But as for the language? Man, I love it. INTEGRATED UNIT TESTING. Compile-time evaluation of complex functions. Built-in 2-D/3-D arrays. Built-in dynamic and static arrays. Static if statements. Contract programming. Ranges beat iterators. Immutable types (which are NOT the same as const, which can be cast away.) Pure functions. Array slicing. constructors named this() instead of classname() so you can rename them simply. No stupid .h/.cpp file. No extern. NO CIRCULAR OR FORWARD DEPENDENCY PROBLEMS. Parsing is TWO PASS. So you don't have to forward declare a class that uses another class... ten lines lower in the damn file. I mean what is this, 1978? Support for directly calling C code, (and direct C++ is supported in a fork called Calypso.)
I could spend PAGES going on about each feature I learned and when I had a eureka moment for each one going, "MY GOD. THAT'S SO MUCH EASIER/MORE POWERFUL."
I'm currently building up a framework basis for a moderate-sized game and I'm honestly having _fun_ writing this D code. I don't spend time writing boilerplate. I spend my time writing code that does stuff.
I honestly hope, and can't wait, for the day that D becomes more popular.
So, a concept is just a fancy name for an interface or an abstract class?
Really? Prior to 1998, there was no standard library, though the Standard Template Library from SGI was pretty much treated as the standard library. When C++ was standardised in 1998, most of the STL was incorporated into the C++ standard library, so almost everything that you'd learned from the STL would still be relevant. The next bump to the standard was in 2011. Lots of stuff was added to the standard library, but very few things were changed in incompatible ways (auto_ptr was deprecated, because in 13 years no one had figured out how to use it without introducing more problems than it solved) and almost all C++98 code compiles without problems against a C++11 library. C++14 and C++17 have both added a lot more useful things but removed or made incompatible changes to very few things.
Let's look at a commonly used class, std::vector. The only incompatible changes in the last 18 years have been subtle changes to how two of the types that are accessible after template instantiation are defined. Code using these types will still work (because the changes are not on the public side of the interface), but the chain for defining them is more explicit (e.g. the type of elements is now the type of elements, not the type of things allocated by the thing that allocates references - code would fail to compile if these weren't the same type). The changes in std::map are the same.
That said, you do need to learn new things. Modern C++ shouldn't use bare pointers anywhere and should create objects with std::make_shared or std::make_unique. The addition of std::variant, std::optional, and std::any in C++17 clean up a lot of code.
I am TheRaven on Soylent News