RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


The Rise and Fall of C++0x Concepts : Page 2

The C++ standards committee has voted to remove concepts from C++0X, leaving a huge hole in the next specification.


Standardizing Existing Practice

Generally, the standards committee is best at standardizing existing practice, that is, wordsmithing features that some compiler vendor has already implemented independently. For example, consider thread-local storage. The committee based this proposal on a similar non-standard extension that several vendors had been offering voluntarily for years. Hashed containers (called unordered containers in C++03) were also based on previous non-standard extensions of various vendors. By contrast, concepts were designed ex-nihilo, and were never tested in real-world projects outside the committee's sandbox.


Concepts Didn't Eliminate Template Complexity

Concepts didn't live up to their promise. They were supposed to make template programming and usage easier. Instead, they transferred the complexities from templates into concept maps and axioms. Pedagogically, concepts were a disaster. There's no way that Joe Coder would ever master such a huge, confusing and unintuitive set of rules and constructs.

No Deadline

Concepts took seven years to design, without reaching satisfactory results. It might have been a good idea to reconsider the whole idea after a certain time limit. How many software projects go on forever without a clear deadline? How many years should a new feature take to design?

What Next?

At this stage, no one really knows how difficult (and dangerous) the removal of concepts will be. Rewriting every piece of code and sentence that refer to concepts will be a painstaking process. Yet the main problem here isn't just editorial. In the past five years C++0x has pretended that concepts are a done deal. Therefore, every phrase in "conceptese" will have to be rephrased in plain English. To illustrate the extent of this problem, consider article 30.3.1/3 of the CD:

"A Mutex type shall be DefaultConstructible and Destructible. […] A Mutex type shall not be copyable nor movable."

These two sentences alone reference four different concepts! And the CD contains 1,340 pages of text, charts and code.

The removal of concepts leads C++ developers back to square one. The same problems that have been troubling C++ users and library designers for years are back with a vengeance. Presently, there's no real alternative to concepts. We'll simply have to make do with C++03-style hacks and improvisations such as SFINAE and type traits. Although the authors are free to refine concepts or redesign it from scratch, don't hold your breath. That could take years—and I doubt that committee members will risk a second fiasco.

The removal of concepts was probably the right choice, no matter how painful it will prove to be. However, I suspect that it will haunt the C++ community for many years to come.

Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date