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."

Comments

Epicycles

[helixcode123]

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.

Just what we needed

[tphb]

I was just saying, "You know, C++ is too straightforward, and there are too few ways to get things done. It needs a few more keywords and paradigms to make it make it work."

What a freakin' mess.

Re:Just what we needed

[cfalcon]

> "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.

Re:Just what we needed

[Dutch Gun]

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.

Re:Just what we needed

[Jeremi]

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.

Re:As someone with a masters in this -exact field-

[ShanghaiBill]

Bjarne Stroustrup, Doug Lea, Knuth, etc... still make feel like a moron on a almost daily basis....

If someone makes you feel like a moron when they explain something, then maybe they are not as smart as you think they are. If you are a true master, you should be able to explain concepts in a way that even a child can understand. Richard Feynman was famous for this. So was Albert Einstein. Of course you can go too far, and simplify too much, so the children only think they understand. Donald Trump is a good example of that.

Re:Is it true?

[Anonymous Brave Guy]

I never saw that in the many years I was working primarily with C++ and a regular reader of the related newsgroups. When Bjarne did contribute in any forums I followed, he generally seemed direct and reasonable, and it was usually in the more advanced discussions about tricky areas or the future of the language.

Sounds overly complicated

[Kjella]

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.

Re:how about modules?

[Anonymous Coward]

Really. After doing a little Ada programming, or even java with interfaces, not having a hard separation between interface and implementation is infuriating.

enough with the pedantic attitude

[lucm]

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.

Re:As someone with a masters in this -exact field-

[slew]

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... ;^)

Re:A new fad?

[serviscope_minor]

No, not a new fad.

Concepts have been coming in C++ since the 90s.

There are two parts of concepts. On the ideas side, Stapanov came up with the idea with the STL. A concept of X is anything X-like. So loosely speaking if you have an array concept, then anything giving [] and having indexable pointers/iterators matches. So, builtin arrays match, as does std::array and vectors from Eigen would match too.

This makes sense: they're semantically the same and if you wrote an algorithm (eg. sort) using any of them, it would look identical. In this way, it's like a specification. If your class matches the specified "array" concept, then any algorithm written against that spec (the array concept) will work correctly on your class.

It's a great idea.

The other bit is language support. So, much C++ code is written using the idea of concepts, but the language does not assist in any way. Templating is completely generic, you say essentially "accept any class", but if you've written against the array concept, and the class doesn't match, you'll get a compile error right in the guts of the algorithm where you try to use [] on an array.

It would be nice, instead of saying "this function accepts any class" to say "this function accepts any class matching the Array concept", or in short "this function accepts any Array". The compiler knows the types and can tell in advance if the class matches. That way if you try to sort a set with that function, for example, it would simply tell you that the set is not an Array.

You can kind of finesse and finagle something better by utterly abusing a different language feature. The language has a mechanism called SFINAE (substitution failure is not an error), which is designed to make function overloading in the presence of templates sane. When the compiler does overload resolution, it substitutes the current type into any templated functions which match the name in question. If that substitution yields a compiler error, the compiler ignores it and removes that option from the list of overloads. This prevents unrelated templated overloads from breaking builds in irrelevant places. It's supposed to be a hidden detail which makes templating "just work". Except you can abuse it to enable/disable functions based on compile time tests for features of a class. IOW you can use it to implement concepts. Accordding to Stroustrup this means "you know too much :(".

He's right: just because you can do it like that doesn't mean it makes life easy.

Putting concepts into the language gives explicit support, with clean, clear, consistent syntax, not using brittle SFINAE hacks. People have been working out how since the 90s, and there have been several major proposals. It's not actually that trivial. You have to avoid breaking any old code, no matter how perverse. It has to work and work cleanly with old, non concept aware code (otherwise it would get slow/no adoption) and it needs to make life simpler for language users and not be an expert only feature, etc etc.

It looks like the concepts TS is finally hitting enough of the targets to actually work.

So basically, no, concepts is not a fad. It's been a major part of the C++ world for 2 decades.

Re: A new fad?

[TheRaven64]

Yes, except with compile-time specialisation instead of run-time specialisation. One of the big problems that I have with C++ is that it has entirely separate mechanisms and syntax for implementing the same thing with compile-time and run-time specialisation and they don't always compose well. Languages such as Java sidestep this by providing only run-time specialisation and expecting the JIT compiler to generate the equivalent of compile-time specialisation.

With an abstract class in C++, you'd require that every method be called via a vtable, which makes inlining hard (though modern compiler can do devirtualisation to some extent). This often doesn't matter, but when it's something like an array access, which is 1-2 instructions, the cost of the method call adds up. In contrast, if you use a template then the compiler knows exactly which method implementation is called and will inline any trivial methods (at the cost of now having one version of each templated function for every data type, which can blow away your instruction cache if you're not careful). The down side of the template approach is that you have no (simple) way of saying 'this template argument must be a thing on which these operations are defined' and the error message when you get it wrong is often dozens of layers of template instantiation later and totally incomprehensible without a tool such as Templight.

Re:More features.

[TheRaven64]

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.

Re:More features.

[TheRaven64]

For embedded systems, you really don't want exceptions. The runtime for RTTI and exceptions is bigger than the flash on most systems (I wrote the one that ships on FreeBSD, the PS4, and a few other places - it's not a huge amount of code in the context of a desktop OS, but it's 100KB of object code for the C++ bits, plus the generic stack unwinder - you don't want to burn 150-200KB of space on an embedded system for this) and stack unwinding performance is very hard to reason about in anything realtime. The reason that the Embedded C++ subset excluded templates was that they make it very hard to reason about code size. A small amount of source code can easily become 10-100KB of object code if you instantiate templates with too many different types. Writing foo() is now not a simple case of set up the call stack and jump, it's either that simple if someone else has instantiated the same template function, or it's creating an entirely new copy of foo and all other templates that it refers to using the template parameters. This makes it very difficult to work out what changes were responsible for pushing the size above the available space. Actually, it's even worse, because the specialised function might now be simple enough to inline everywhere and give an overall space saving, but reasoning about exactly where that balance is becomes very hard. It's not that C++ generates bigger code than C, it's that object code size in C++ has far less of a direct correspondence with source code size than C.