C ++ 0x will no longer have concepts. Opinions? How will this affect you?

In July 2009, a C ++ 0x meeting in Frankfurt , it was decided to remove concepts from C ++ 0x. Personally, I'm disappointed, but I'd rather implement C ++ 0x than C ++ 0x. They said they will be added later.

What are your opinions on this solution / problem? How will this affect you?

+8
c ++ c ++ 11 c ++ - concepts
Jul 20 '09 at 17:58
source share
9 answers

Personally, I am not too unhappy with the deletion, since the purpose of the concepts was to mainly improve compilation error messages, as Jeremy Sick, one of the co-authors of the Concepts proposal, writes ( http://lambda-the-ultimate.org/node/3518#comment-50071 ):

Although the “Concept” sentence was not perfect (can any C ++ extension ever really be perfect?), It provided a very useful and useful language extension, an extension that drastically reduces the notorious error messages that current users of the library template suffer.

Of course, the concepts had more purpose than just letting the compilers give short error messages, but for now I think we can all live without them.

EDIT: Herb Sutter also writes on his blog :

Q: Was this C ++ 0xs one big feature?

A: No. The concepts would be great, but for most users, the presence or absence of concepts will not make a difference in their experience with C ++ 0x, except for the quality of the message error.

Q: Arent's concepts of adding core new expressive power to the language, and thus allow you to create new new types of programs or programming styles?

A: Not really. The concepts are almost entirely about getting the best message error.

+8
Jul 22 '09 at 7:51
source share

I was looking forward to them. Mainly to improve error reporting when compilation fails. Nothing like reading lines with 1000 characters to figure out your dumb mistakes.

+6
Jul 20 '09 at 18:01
source share

I am sad to see them drop out of the list.

Personally, I like the types that I use to obey a well-known interface, be it primitives, structures, or classes. That way, I know how I can use a type and what I need to implement to provide a type.

This is easily achieved using standard object-oriented programming. However, in my opinion, while technically generalized programming is strongly typed, it loses the concept of an interface that introduces OO. In fact, general programming is similar to dynamic typing, but is allowed in the compiler from an interface point of view.

For example, I pass an iterator to an algorithm that it should provide to some operators, but there is no interface to indicate what these operators should do or what their contracts are (documentation only). If you have operator++() and operator*() , it will be compiled, but it will not give you the same type of guarantee that the interfaces give you OO.

For me, Concepts bring types to general programming, and certainty interfaces bring to OO, the best compiler is just a bonus.

I know that we are all C ++ programmers, and we are very smart, and we read the documentation and understand the overload of operators and the subtleties of general programming. But when a language that provides guarantees that I can rely on and the compiler can test, I can spend more energy on the mind, solving problems that I get paid to solve.

+4
Jul 22 '09 at 11:34
source share

I have not participated in concepts yet. However, I noticed that they were usually quite verbose. I think I do not want them in the STL library. I already know the library, I can easily parse any compile-time errors. No need for concepts. However, it would be nice to describe my own classes so that staff will quickly recognize them and avoid abuse. Each concept so far I understand the limitation that limits the use of type. This would be good at creating new interfaces that someone else should learn.

+2
Jul 21 '09 at 20:30
source share

I really like the concept! The ability to create very different types behaves the same by external definition (concept mapping) - a very powerful and useful function (especially as it happens at compile time and therefore does not affect performance at runtime).

I think that it is even more powerful and better than implementing all the useful functions directly in the type and accessing them through interfaces, for example, made in .NET. This does not allow expanding the capabilities later (well, .NET knows extension methods from 3.0 (or 3.5, not sure), but this is not the same).

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

But one of my first thoughts in reading the concepts was: it will take LOOOOONG time until GCC and MSVC support it.

Therefore, I think it makes sense to remove it from a future standard. BUT, what I would like is a fixed agreement on the features of post C ++ 0x standards that contain concepts. This would allow compilers to better prepare for the C ++ 2x standard.

Therefore, I really hope that we will see the concept in the near future.

+1
Jul 22 '09 at 19:57
source share

I think they made the right decision. I would like to see a high-quality implementation of concepts added to the language, but the specification was directed in the wrong direction, which was too heavy for the user to explicitly indicate conceptual maps. Straustrup's document did offer some corrections, but that would be a pretty radical change so late that I think. And without a compiler to test it.

Thus, the concepts that were indicated at the end would be a big step backward, hindering the development of common programs and possibly breaking up the C ++ community, with a large group of programmers adhering to C ++ 03.

The concepts proposed by Straustrup were found to be, as far as I can see, in order, but it would be risky to accept these changes so quickly. (And I'm not sure that this would not cause further delays.)

Honestly, I'm glad to see that they played it safely and cleaned them for now. So far, we have survived without concepts, and I can live without them for another 5 years.

+1
Jul 24 '09 at 19:04
source share

Very sad. Bringing concepts into C ++ would make the system of its type almost at the same level as the Haskell cool classes, and that would be awesome - a language optimized for speed, allowing you to do what you want, and yet strictly types if you are not using escape holes (still fast!). It was also intended to fix the long-standing STL and Boost problem (and template libraries in general), which are difficult to use because of the laid-back "font typing" time compilation "of C ++ 03 templates and subsequent problems with the error report compiler.

+1
Jul 24. '09 at 19:24
source share

I also thought that this was a bad call, and that C++0x would be worse for deletion, but just finished reading Stroustrup Simplifying the Use of the Concept I changed my mind. I had no idea that the proposal of the concepts was so complicated, and I think it’s good that it will be well thought out before adding to this language. Despite the fact that Straustrup is preaching for the preservation of concepts, his article convinced me that since concepts will do more harm than good at the moment, and even though BS offers a solution, I’m afraid that he may be thrown, and not all the consequences are yet to be understood.

+1
Jul 29 '09 at 11:30 a.m.
source share

I'm sad.

I quit ConceptGCC and it’s great! I am already writing some kind of simple library using this, and I see some flaws, such as more code to write or problems with thoughts about the power of concept abstraction. The std-concept library really creates problems, so the inclusion of such a standard in the standard is simply a misunderstanding. I think that the upcoming standard should only standardize the grammar of the concept and give some tips on how to use it.

+1
Jul 29 '09 at 21:42
source share



All Articles