Many developer considered concepts to be a key new feature of the upcoming C++0x specification. Yet, the C++ standards committee decided to remove concepts from the standard, mainly on the grounds that the design was not sufficiently ready for large-scale consumption by all C++ developers. In a recent interview, Bjarne Stroustrup Expounds on Concepts and the Future of C++, C++ language creator Bjarne Stroustrup discusses what concepts were designed to accomplish in the standard, and why they were eventually not included:
[Concepts] were introduced to do one thing: provide direct language support to the by-far dominant use of templates: generic programming. They were intended to allow direct expression of what people already state in comments, in design documents, and in documentation. Every well-designed template is written with a notion of what is required from its arguments. For good code, those requirements are documented (think of the standard's requirements tables). That is, today most templates are designed using an informal notion of concepts...
The reason we need direct language support for concepts is that an informal notion is not good enough: Compilers do not read comments, design documents, or standards and "informal" in the hands of most programmers (I don't except myself) means "imprecise." That is, the lack of formal, language supported concepts is a source of bugs as well as poor error messages. I think the analogy between concepts in template declarations and arguments in function declarations (function prototypes) are more relevant than many like to believe.
Even through concepts were going to be an important enabler of more reliable metaprogramming, Stroustrup discusses why they didn't make it into the upcoming standard:
I am not of the opinion that concepts have failed. My position was that we needed only a few weeks to "fix" what in my opinion were serious usability problems. Obviously, a majority of the committee didn't agree with that timescale. But just about everyone I talked to expressed support for the idea of concepts and I had to warn against over-optimism about the timescale to get concepts back once they were removed from the working paper...
How do I feel? Disappointed, but not crushed. Things could have been much worse. In particular, we could have made the seriously flawed "concepts" part of the standard...
Stroustrup notes that while concepts are not difficult to grasp, they are rather hard to implement:
Concepts are hard to design because they represent a formalization of the C++ type system. Doing concepts right implies a more formal specification of much of C++, and requires reaching a new level of precision in the description of the C++ standard library. In other words, doing concepts right implies clearing up many dark corners of the C++ specification...
Doing concepts right also implies using them does not mean significant increases in compile time, decreases in run-time performance, or erecting new barriers to effective generic programming. My worry about concepts as present in the pre-Frankfurt working paper was the last point. Others worried about the first.
Some in the C++ committee were concerned that introducing concepts would have complicated the work on the "average" programmer. Stroustrup rejects such an elitist notion, however:
Realistically we are all "Joe Coder" outside our little comfort zones. Modern software is far too complex for a single person to be more than a novice in most aspects. I'm "Joe Coder" most of the time, and so are you. Since we are all "Joe Coder" most of the time, let's retire that way of talking and start attacking the issue of complexity in all its varieties the best we can. "Divide and conquer" is the basic weapon; abstraction and layering are popular and effective variants...
Most programmers could use their time better writing idiomatic code; we need good programmers far more than we need yet-another language lawyer.
What do you think of Stroustrup's explanation of concepts, and why they didn't make into the upcoming standard?
it continues to blow my mind how the things which come out of Mr. Stroustrup's mouth are often so right on the money. i mean, if i were just looking at how bad C++ is (not entirely, of course; there are several good things which come along with the unfortunate baggage) i would not have thought of him as being so otherwise sane. it is like some kind of buddhist lesson.
In this interview Stroustrup also talks about the C++ standards process - that's interesting, especially in light of recent debates about the effectiveness of the JCP (for Java).
That is, the lack of formal, language supported concepts is a source of bugs
How can that happen? concepts is a compile time proof system and has nothing to do with the run time.
as well as poor error messages
It could be fixed if the error message reports the error at the line of template instantiation, not inside the template.
Concepts are hard to design because they represent a formalization of the C++ type system. Doing concepts right implies a more formal specification of much of C++, and requires reaching a new level of precision in the description of the C++ standard library. In other words, doing concepts right implies clearing up many dark corners of the C++ specification...
Why don't we forget C++ alright and make a proper language this time from the beginning, compatible with C++? a language that is translated to C++ and therefore can use C++ existing code.
introducing concepts would have complicated the work on the "average" programmer
It's amazing that they worry about that and not about memory management/array bounds checking, which is an equally or greater problem than the complexity of concepts.
Most programmers could use their time better writing idiomatic code; we need good programmers far more than we need yet-another language lawyer.
Most programmers could use their time writing functionality and not dealing with the language's problems. Unfortunately, this day has not dawned yet.
> That is, the lack of formal, language supported > concepts is a source of bugs > > How can that happen? concepts is a compile time proof > system and has nothing to do with the run time.
Templates can be instantiated with types that do not meet the requirements and the problem is not detected at compile-time e.g. using auto_ptr<T> where a type with conventional copy semantics is needed.
> as well as poor error messages > > It could be fixed if the error message reports the error > at the line of template instantiation, not inside the > template.
I'm still not convinced this will help significantly but you seem to be, so have you tried suggesting it to compiler writers, e.g. opening a GCC bugzilla report requesting the change? If you can demonstrate that it produces better diagnostics in a majority of cases then I expect people will pay attention.
> Concepts are hard to design because they represent a > formalization of the C++ type system. Doing concepts right > implies a more formal specification of much of C++, and > requires reaching a new level of precision in the > description of the C++ standard library. In other words, > doing concepts right implies clearing up many dark corners > of the C++ specification... > > Why don't we forget C++ alright and make a proper language > this time from the beginning, compatible with C++? a > language that is translated to C++ and therefore can use > C++ existing code.
Who is "we"? You are free to do exactly that, or to contribute to an existing language such as D, but I don't think it's unreasonable for the C++ committee to continue working on C++. If you want to forget C++ go ahead, but if you want everyone else to forget it then you need to provide a better alternative.
> introducing concepts would have complicated the work on > the "average" programmer > > It's amazing that they worry about that and not about > memory management/array bounds checking, which is an > equally or greater problem than the complexity of > concepts.
Who says the committee don't worry about that? The new standard library includes three types of smart pointer and a fixed-size array template and the language includes a new range-based for-loop to simplify iterating over arrays.
I hear lots of people say "why are they wasting time on X instead of Y" but that assumes it's not possible to do both.
I registered with GCC/bugzilla, but it requires a lot of work from my part. I don't have the time currently to read all the previous bugs regarding template errors and the how-tos for posting a bug.
Templates can be instantiated with types that do not meet the requirements and the problem is not detected at compile-time e.g. using auto_ptr<T> where a type with conventional copy semantics is needed.
It can be achieved with template specialization.
Who is "we"? You are free to do exactly that, or to contribute to an existing language such as D, but I don't think it's unreasonable for the C++ committee to continue working on C++. If you want to forget C++ go ahead, but if you want everyone else to forget it then you need to provide a better alternative.
"We", as the C++ committee and the C++ programmers. I would have done so, I don't have the time. The C++ committee has time to design a new language with all the C++ goodies but none of its problems.
Who says the committee don't worry about that? The new standard library includes three types of smart pointer and a fixed-size array template and the language includes a new range-based for-loop to simplify iterating over arrays.
They haven't done so until now. Smart pointers should have been available 10 years ago. And the operator [] in vector and array templates should be bounds-checked.
> Templates can be instantiated with types that do not > meet the requirements and the problem is not detected at > compile-time e.g. using auto_ptr<T> where a type with > conventional copy semantics is needed. > > It can be achieved with template specialization.
It can be, but that doesn't scale.
If I write a template which requires conventional copy semantics I can provide a partial specialisation to prevent it from compiling with auto_ptr<T>. But if you write your own type with unconventional copy semantics, I cannot possibly provide a specialisation of my template for your type, because I have never heard of it. Similarly I can't provide specialisations for other users' types, which may not even have been written yet.
You can provide a specialisation of my template, but that requires you (the library user) to understand all the requirements of the template and to invest the time in preventing it from being misused. Concepts allow me (the library author) to state the requirements once, in advance, and have them checked for all users' types.
There is a huge difference between the library author enforcing the requirements in advance and expecting every user to enforce the requirements themselves for every type that shouldn't be used with the template.
> Who is "we"? You are free to do exactly that, or to > contribute to an existing language such as D, but I don't > think it's unreasonable for the C++ committee to continue > working on C++. If you want to forget C++ go ahead, but if > you want everyone else to forget it then you need to > provide a better alternative. > > "We", as the C++ committee and the C++ programmers. I > would have done so, I don't have the time. The C++ > committee has time to design a new language with all the > C++ goodies but none of its problems.
I'm sorry, but that's ridiculous. The committee is composed of organisations with a vested interest in C++. Their remit is to standardise and evolve the existing language, not invent a new one. I don't think that would even be allowed as part of the ISO standardisation process (certinaly national bodies meant to serve the interests of C++ users in their country should not be turning their back on those users and telling them to use a new language which doesn't even exist yet.)
Nothing prevents any group, including members of the C++ committee, from working on a new language, but that would have to be separate to the ISO standardisation effort.
> Who says the committee don't worry about that? The new > standard library includes three types of smart pointer and > a fixed-size array template and the language includes a > new range-based for-loop to simplify iterating over > arrays. > > They haven't done so until now. Smart pointers should have > been available 10 years ago. And the operator [] in vector > and array templates should be bounds-checked.
If you want bounds-checking use vector::at(), if you don't then use vector::operator[] - the choice has always been there.
The standardisation process and C++ itself are certainly not perfect, but they are a lot more useful than armchair commentators who don't have time to do anything except criticise other people's efforts.
You can provide a specialisation of my template, but that requires you (the library user) to understand all the requirements of the template and to invest the time in preventing it from being misused. Concepts allow me (the library author) to state the requirements once, in advance, and have them checked for all users' types
How does that differ from understanding your constraints? concepts are not magical. They can not tell what I do in my copy constructor, for example. I would still have to understand your constraints and adjust my code accordingly.
In the case of auto_ptr, for example, how would you express the concept of not transferring ownership? even if concepts allowed you to tell that all members of the source object, which is const, should not be mutable, I would still have to read your documentation, just like when I would have to provide a template specialization for my code. There is no difference in practice.
There is a huge difference between the library author enforcing the requirements in advance and expecting every user to enforce the requirements themselves for every type that shouldn't be used with the template.
How is it that template specializations is not the library author enforcing the requirements in advance? if the client code does not compile because of missing template specialization, then it's because the library author has provided a constraint.
I'm sorry, but that's ridiculous. The committee is composed of organisations with a vested interest in C++. Their remit is to standardise and evolve the existing language, not invent a new one. I don't think that would even be allowed as part of the ISO standardisation process (certinaly national bodies meant to serve the interests of C++ users in their country should not be turning their back on those users and telling them to use a new language which doesn't even exist yet.)
Why is it ridiculous? you can write new code in this new language, and old code in C++. The new language would be translated to C++ anyway.
If you want bounds-checking use vector::at(), if you don't then use vector::operator[] - the choice has always been there.
What if I am using a library that does not use vector::at()?
The standardisation process and C++ itself are certainly not perfect, but they are a lot more useful than armchair commentators who don't have time to do anything except criticise other people's efforts.
I have a full time job as a programmer - at 14 September, I have to deliver a huge project to my customer. The program runs, but it crashes a lot. It is written in C++. I have to spend my days and nights debugging not only my code, but the libraries I am using as well. My wife complains that she does not see me a lot lately. Are you sure that I am an armchair commentator? If I had the time, I would create a new language. If I had the money, I would quit and devote myself to this new language. Please stop criticizing the others if you don't know the circumstances.
> In the case of auto_ptr, for example, how would you > express the concept of not transferring ownership? even if > concepts allowed you to tell that all members of the > source object, which is const, should not be mutable, I > would still have to read your documentation, just like > when I would have to provide a template specialization for > my code. There is no difference in practice.
The CopyConstructible<T> concept requires T to have a copy constructor taking a const T& parameter. auto_ptr<T> fails that requirement.
There's no checking for mutable members etc. so if you really want to cheat the type system and shoot yourself in the foot, you can do it (but please stay away from my code.)
As the template author I can say that my template requires CopyConstructible parameter, and it will reject any types that don't meet it. It's not 100% foolproof, but it scales better than expecting users to write a template specialization for their types to enable/disable them from being used with my template.
> There is a huge difference between the library author > enforcing the requirements in advance and expecting every > user to enforce the requirements themselves for every type > that shouldn't be used with the template. > > How is it that template specializations is not the library > author enforcing the requirements in advance? if the > client code does not compile because of missing template > specialization, then it's because the library author has > provided a constraint.
Maybe we were talking about different things - "template specializations" is not very precise!
I was talking about preventing templates from being instantiated with unsuitable types. And I thought you meant that you could do that by specializing to prevent compilation (which is true, but doesn't scale.) e.g.
template<typename T> class MyLibraryComponent< std::auto_ptr<T> > { private: // trying to use this partial specialization will fail MyLibraryComponent(); };
Do you mean that the template author should provide a trait-like class, and expect users to specialize it, and the template can't be used otherwise? i.e. the traits type acts as a compile-time adaptor pattern?
If so, yes, that can work - but still requires extra work from users to define the specializations. And it allows the user to lie by providing a specialization for unsuitable types.
Concepts allow the compiler to detect if the type is suitable and reject it if not. That means it is checked by the compiler, and saves time so you can debug your crashes instead of writing lots of traits specializations.
> I'm sorry, but that's ridiculous. The committee is > composed of organisations with a vested interest in C++. > Their remit is to standardise and evolve the existing > language, not invent a new one. I don't think that would > even be allowed as part of the ISO standardisation process > (certinaly national bodies meant to serve the interests of > C++ users in their country should not be turning their > back on those users and telling them to use a new language > which doesn't even exist yet.) > > Why is it ridiculous? you can write new code in this new > language, and old code in C++. The new language would be > translated to C++ anyway.
It's not ridiculous to invent a new language.
It's ridiculous to ask the C++ committee to invent it.
If I don't like the sport of football (aka soccer) then it would be ridiculous for me to go to FIFA (the sport's ruling body) and ask them to invent a new game.
Do you see my point?
> > If you want bounds-checking use vector::at(), if you don't > then use vector::operator[] - the choice has always been > there. > > What if I am using a library that does not use > vector::at()?
That's your problem, use a different library or complain to the vendor, don't insist the standard must be changed.
Flat View: This topic has 50 replies
on 4 pages
[
1234
|
»
]
Previous Topic
