views:

740

answers:

9

At the July 2009 C++0x meeting in Frankfurt, it was decided to remove concepts from C++0x. Personally, I am disappointed but I'd rather have an implementable C++0x than no C++0x. They said they will be added at a later date.

What are your opinions on this decision/issue? How will it affect you?

+5  A: 

I was looking forward to them. Mostly for better error reporting when the compilation failed. Nothing like reading through 1000 character strings to figure out your dumb errors.

Matt Price
Me too. This is sad :(
GMan
+2  A: 

I didn't get involved into concepts much yet. However, what I noticed was, that they generally were quite verbose. I think I wouldn't want them in STL library. I know the library already, I can easily parse any compile-time errors. No need for concepts. However, concepts would be nice to describe my own classes, so that co-workers would learn them faster and avoid misuses. Each concept is as far I understand a constraint, that limits the usage of a type. That would be nice when creating fresh interfaces that someone else has to learn.

+7  A: 

Personally I'm not too unhappy of the removal as the purpose of concepts were to mainly improve compile time error messages, as Jeremy Siek, one of the co-authors of the Concepts proposal, writes (http://lambda-the-ultimate.org/node/3518#comment-50071):

While the Concepts proposal was not perfect (can any extension to C++ really ever be perfect?), it would have provided a very usable and helpful extension to the language, an extension that would drastically reduce the infamous error messages that current users of template libraries are plagued with.

Of course concepts had more purpose than just enable the compilers to give shorter error messages, but currently I think we all can live without them.

EDIT: Herb Sutter also writes on his blog:

Q: Wasn’t this C++0x’s one big feature?

A: No. Concepts would be great, but for most users, the presence or absence of concepts will make no difference to their experience with C++0x except for quality of error messages.

Q: Aren’t concepts about adding major new expressive power to the language, and so enable major new kinds of programs or programming styles?

A: Not really. Concepts are almost entirely about getting better error messages.

dalle
+3  A: 

I am sad to see them drop off the list.

Personally I like the types I use to obey a known interface, be they primitives, structs or classes. This way I know how I can use the type and what I have to implement to provide the type.

This is all easy to achieve with standard object oriented programming. However in my opinion while technically generic programming is strongly typed it looses the interface concept that typing provides OO. In fact generic programming, is kind of like dynamic typing but resolved at compile type from an interface perspective.

For instance I pass an iterator into an algorithm it has to provide some operators but there is no interface to specify what those operators should do, or what their contracts are (only documentation). If you have operator++() and operator*() it will compile but it does not give you the same type guarantees that interfaces give you in OO.

For me Concepts bring types to generic programming and the the certainty interfaces bring to OO, the better compile are just a bonus.

I know that we are all c++ programmers and we are very smart and we read the documentation and understand operator overloading and the subtleties of generic programming. But when the language providing guarantees that I can rely on and the compiler can test, I can spend more brain power solving the problems I am paid to solve.

iain
+1: Good points! And when looking at concept maps it also brings "external interface implementations" to the generic programming.
rstevens
Interfaces provide no more guarantees you can rely on. It just says "the programmer intended this class to work in this context". Nothing about whether it actually behaves as you'd expect. Anyway, this was exactly the reason why it was removed. This kind of explicit interfaces was considered a *bad* thing. The problem is that it really makes generic programming a chore, and in non-trivial cases, virtually impossible.
jalf
+1  A: 

I like concepts very much! The possibility to make very different types behave the same by an external definition (the concept mapping) is a very powerful and useful feature (Especially as it occurs on compile time and so does not affects run-time performance).

I think it is even more powerful and better than implementing all useful features directly into the type and access them via interfaces like done in .NET. This does not allow the extensibility later on (Okay, .NET knows extension methods since 3.0 (or 3.5, not sure) but it's not the same).

Improving error messages is another (and the original) great improvement that concepts bring.

But one of my first thoughts when reading about concepts was: This will take a LOOOOONG time until GCC and MSVC will support it.

So I think it makes sense to remove it from the upcoming standard. BUT what I would wish is a fixed agreement of features for post C++0x standards which contains concepts. This would allow the compiler vendors to better prepare for the C++2x standard.

So I really hope that we will see concepts in the not so far future.

rstevens
+1  A: 

I think they made the right decision. I'd love to see a high-quality implementation of concepts added to the language, but the spec was headed in the wrong direction, putting too much burden on the user to specify concept maps explicitly. Stroustrup's paper did suggest some fixes to this, but that would be a fairly radical change so late in the process, I think. And with no compiler to test it on.

In summary, concepts as they were specified towards the end, would have been a big step backwards, hindering generic programming, and possibly splintering the C++ community, with a large group of programmers sticking with C++03.

Concepts, as proposed "fixed" by Stroustrup, would, as far as I can see, have been ok, but it would be risky to adopt these changes so quickly. (And I'm not convinced that it wouldn't have caused further delays.)

Honestly, I'm glad to see they played it safe and removed them for now. We've survived without concepts until now, and I can live without them for another 5 years.

jalf
+1  A: 

It is very sad. Bringing concepts to C++ would bring its type system almost to the same level of power as Haskell typeclasses, and it would've been awesome - a language optimized for speed, letting you do whatever you want, and yet strictly typesafe unless you use escape vents (while still remaining fast!). It was also supposed to fix the long-standing problem of STL and Boost (and template libraries in general) being hard to use because of lax "compile-time duck typing" nature of C++03 templates, and the consequent troubles with compiler error reporting.

Pavel Minaev
A: 

I too thought that this was a bad call and that C++0x will be the worse for the removal but having just finished reading Stroustrup's Simplifying the use of Concepts I've changed my mind. I had no idea that the concepts proposal was that complicated and I think it's a good thing that it will be well thought out before added to the language. Even though Stroustrup is preaching for keeping concepts his article convinced me that as it now stands concepts would do more harm than good and even though BS proposes a solution I fear that it may be rushed and not all implications yet understood.

Motti
A: 

I'am sad.

I checkout the ConceptGCC and it's great! I already write some simple library using this, and I see some disadvantages like more code to write or some mind trouble thinking of the power of abstraction of the Concepts. The std concepts library really makes problems, so including such one in standard is just misunderstanding. I think the coming standard should only standardize grammar of concept, and provide some hints how to use it.

lionbest