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."
That's what C++ needs: More features! They had better introduce sidgils like in Perl so they can have room for more keywords.
Templates produce very bloated code. Most embedded programmers working in C++ use a very small subset of the language for a reason. But C++ has lots of other problems. It was nice when it saved you from having to hand-build vtables doing OOP in C. Now after the meta-programming fads have gotten into it the language seems all over the map.
The vagaries and complexities of C++ as it progresses in it's specification is reminiscent of efforts to get epicycles to explain motions of heavenly bodies. Geez, people are snide about Perl syntax. Now we have &ref, &&global_ref, [](args){my_lambda_code();}, copy constructors, move constructors, 'override' to fix virtual function breakage. This is just a mess of a language.
In a band? Use WheresTheGig for free.
OK, thanks I will correct people spreading such rumors.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Do you know what I never hear a carpenter saying? "Geez, look at all these tools. I wish I had fewer tools in my toolbox."
C++ is a language toolbox. You can use the parts of it useful to you, and largely ignore the rest if you don't happen to need it at the moment.
Irony: Agile development has too much intertia to be abandoned now.
> "Geez, look at all these tools. I wish I had fewer tools in my toolbox."
No, but I do here people who go in to modify something say "Gosh, I wish there weren't so many different types of connectors, why does this screw have a starburst and this one a rhombus on it?"
Remember that for every Clever Lad who writes this code, an army of dudes has to come through and read and modify it over time.
That's not to speak against it- merely that as the language gets broader, supporting it becomes slower and more expensive.
The key difference between this and interfaces in Java seems to be push vs pull, does a class explicitly declare that it is say sortable or do you just check if it has functions that match something that's sortable. If you look at the example he does on page 8 with Shape.draw() and Cowboy.draw() sure you could be more explicit in the template requirements or you could demand that the cowboy explicitly has to say he's "drawable". To me Stroustrup's idea sounds a bit too much like the story about the blind man and the elephant, if you only touch it in enough places you can be sure it's an elephant. The obviously problem is that once you have a birth defect or amputee with only three legs, it all fails.
For example I might like to define a class "SequenceNumber" that has functions like setInitialValue(), getNextValue() etc. but lacks typical characteristics of a number like being able to add and subtract them, but I can still sort sequence numbers. If it's explicit I only have to declare it sortable and implement the necessary functions. If it looks at the "concept" number it'll say nope, you're not a real number because we can't add two of you together.
This could be trivially avoided by having the possibility to supplement class definitions as implementing additional interfaces, like here's a library with the Circle shape header and I say it's a drawable even though it doesn't say so itself. It'll still have to actually fulfill the interface, but that way you're not bound by the ones supplied by the library. Since that's purely a synthetic check on whether your code should be able to call that code I don't see how that should be a problem.
Live today, because you never know what tomorrow brings
Well, part of being a professional programmer, at least IMO, is not going batshit-insane with fancy language features when they're not needed. C++ is a language in which you can write some really, really horrible code if you're determined to do so. And I don't think I've ever heard anyone describe it as a language that's easy to master. But for highly experienced C++ programmers like myself, it's an incredibly powerful language, and that's what's important, at least when I use it professionally.
It's pretty easy to list off a litany of problems with C++. It's bloated, it's ugly, it's hard to learn, full of strange idioms and tricky rules. But it has three characteristics that make it indespensible for certain industries and applications:
* It's ubiquitous. Nearly every platform has a C++ compiler, and there's a lot of sample C or C++ code available to use. It also makes hiring and training easier.
* It's efficient. You don't pay for features you don't use, and it compiles down to fast, efficient, native code.
* It's got reasonably good abstraction features that don't require paying a heavy price for that safety, enabling large, complex programs to be written more easily.
There are a lot of great new languages coming out, but nearly all of those fail on the first point. Unfortunately, that's a deal breaker for many projects.
Irony: Agile development has too much intertia to be abandoned now.
As a C++ programmer, I don't know if I'll ever use "concepts" in my own code.
That said, I'm nevertheless very much looking forward to them becoming part of the language, if only so that when I do something wrong when using an STL class, the compiler can come back with an error that tells me what I did wrong, rather then five pages of incomprehensible gibberish.
Many C++ features are like this, aimed not primarily at the average C++ user, but rather at the STL developers.
I don't care if it's 90,000 hectares. That lake was not my doing.
Seems everyone I run into these days who says "I'm a software engineer" has zero CS instinct
That's because software engineering has very little to do with computer science. A software engineer solves real-world problem with software.
How many cops do you run into these days that have more than the strict minimum knowledge of the law needed to do their job? Does that make them incompetent cops, or is it possible that maybe a different skill set is required?
If you want to stick to academia and horse around in labs that depend on grant money and alumni, knock yourself out, nobody is stopping you - there will always be a need for abstract thinkers. But out there in the real world, people must build things on time and on budget, and while we all wish that the best algorithms and the most elegant code is the way to achieve that, when push comes to shove, shipping the product is what pays the bills and if that means ugly code, then ugly code it is. Do you think the POS software on the cash register that allowed you to buy grocery this week is a masterpiece, or that the algorithm that decides when and how to to take over your car brakes is flawless? No, it's probably full of bugs and hard-coded passwords and antipatterns. But guess what, you still got that food in your fridge and you've made it alive on the freeway. Good. Enough.
lucm, indeed.
C# and C++ do not cover the same application space. C++ is a bare-metal language. C# requires a large stack, which is suitable for enterprise software but not for performance or embedded software.
Therefore, one can not say C# > C++, or C++ > C#.
That's actually a really good point. I've watched some conference talks in recent years that explained how C++ is actually two languages... one designed for library writers (where a lot of the most hard-core features are aimed, such as move-semantics or template-related features), and a simpler subset for library-users, who often just call the code that the library writers write. The real world is not quite as clean-cut as that exactly, but I think it's true to some degree, certainly.
All this makes for libraries which are incredibly easy-to-use while at the same time are both safe and efficient. In many cases, the user doesn't even have to know about all the optimizations that have been made. They can simply take advantage of the new language features like shared_ptr without having to worry about all the language features and work that went into making sure it works as naturally as though it were a built in language feature and not a library class. It's hard to describe how transformative the C++ 11/14 standard was for C++ as a language to people who still view it through the lens of what it was a like a decade or two ago. I often remark that C++ actually feels a lot like a managed language like C# now, only with much uglier syntax.
What's remarkable to me is that this was done without breaking existing code out in the wild. I joke about the ugly syntax, but a lot of that comes from the reluctance to introduce new operators and keywords, which would invariably break existing code. Many of the complaints about C++'s "bloated" nature also comes from features left in place for backwards compatibility. If I had to offer a fourth quality to C++, it would be "stability", for which we can thank the C++ design community, who (along with various working groups) have been doing an amazing job this past decade. You can see modern examples of how traumatic it is for a language-using community when backwards compatibility breaks, something that many more modern language designers don't seem to feel as reluctant to do as I think they should.
Hell, C++ 17 is only now removing support for trigraphs, for goodness' sake, an artifact of ancient keyboards that didn't support all the characters required to program C/C++. Hilariously, IBM is opposing its removal (it's already been delayed since C++ 11, largely thanks to them), which tells you that there's some rather ancient C/C++ actually living out there in the wild, as well as indicating how conservative the C++ community is in this regard.
Irony: Agile development has too much intertia to be abandoned now.