Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Bjarne Stroustrup Expounds on Concepts and the Future of C++ : Page 2

Danny Kalev asks Bjarne the hard questions about concepts and C++'s future.


advertisement

Concept Awareness

DK: In March 2009, several months after the acceptance of Concepts into the WD, Howard Hinnant was the first to ask: "What is the risk in requiring Joe Coder to be concept-aware?  What is the benefit?" It's surprising that these questions hadn't arisen much earlier during the design process. Doesn't that indicate the committee should have more checks and balances, especially when it comes to adding a new feature that is as pervasive as concepts?

BS: The committee is not perfect—no organization is—but it is far more responsible and competent than you imply. I suspect some members of the committee will seriously resent those questions and consider them proof of ignorance or ill will.



The quantity and quality of published papers on the WG21 site speaks volumes about the seriousness and thoroughness of the committee's work—and that doesn't even cover the endless formal and informal discussions.

Obviously, Howard wasn't the first to worry about risks or to try to weigh risks against benefits. That has been done by everyone seriously involved with concepts from day one. In fact, I worried about the tradeoffs related to template-argument checking from the first days of the design of templates (1986 onwards, see D&E). The reason we don't already have something like concepts, is that in 1988 I did not know a solution that gave flexibility/generality, performance, and good early checking. As far as I know, nobody else knew either. I chose flexibility/generality and performance at the cost of delayed checking and appalling error messages. In 2006 or so we had solutions to the major problems. That's a significant difference. The problem in 2009 was that some of us felt that even though the progress over the years had been significant, and we had gained valuable implementation and library design experience, we were "not quite there." That is, some aspects of concepts needed further refinement before standardization. In particular, I felt that some of the lessons learned using concepts had not been fed back into the concept design.

Howard may have asked about risks and benefits (others certainly did), but I don't recall that. What he did ask was a question about usage. From my "simplifying the use of concepts" paper:

That thread started when Howard Hinnant asked that question in the context of a design (of a utility) that could be done in two ways: One would require quite a lot of users—not necessarily expert users—to write concept maps. The other design (arguably less elegant) would avoid concept maps (and concepts) so as not to require users to understand anything significant about concepts.

Alisdair Meredith had earlier asked the related question (I paraphrase): "Should auto concepts be recommended only for legacy code."

My primary concern was (and is) with usability.

The committee operates according to ISO rules. Those are quite ponderous and biased in favor of not upsetting status quo. They combine perfect openness—anyone can join without requirements of experience, education, or commercial interest—with formal votes at the level of national delegations. The documents of the C++ committee are available on the web. The C++ committee is a pioneer here. Furthermore, the national standards committees and individual members have made sustained efforts to involve the various communities of C++ developers. My publication record, interviews, and speaking record is just one example among many.

It is extremely difficult to make major changes to a language in world-wide use. That's probably good: one of C++'s greatest advantages compared to proprietary languages is stability. I don't think we need more formal "checks and balances." If anything, the balance may have tilted too far toward caution for the long-term good of the language.

DK: Allow me to be more specific about the "checks and balances." The Boost organization enables the committee to experiment unofficially with new libraries in the real world, and get feedback from a vast number of C++ programmers before accepting those libraries into the standard. However, the committee has no similar "field research lab" for core language features. Consequently, pervasive core language features might be incorporated into the WD without sufficient experience and testing. That's what happened with concepts I believe. Would a "staging core C++" organization be feasible and useful?

BS: You are wrong in your characterization of what happened to concepts. In that case, we did have a "staging lab." It was conceptGCC, the people working on concepts (mostly at Indiana and Texas A&M universities), and the people trying to use concepts in libraries (many from Boost). The concerns about concepts focused on whether that effort was sufficient, whether the design was sufficiently refined (my main worry), and whether more time was needed so that it might delay the standard (the majority's worry).

In fact, essentially all new language features are tried out in some compiler or other. The question is, "How much experimental work is sufficient to validate a design?" I think the answer depends critically on the language feature in question.

It would indeed be nice if we had a common testing ground for new features, but we don't. The reasons are: talent, time, and money. It's hard to build an infrastructure for language design experimentation; good compiler writers are not common (nor cheap); and implementing and testing a feature can be very time consuming. The people who can do this tend to be very busy people with demanding day jobs and careers. Also, few people are willing to base a project on an untried language feature in an experimental test bed. I don't think that the analogy to library testing is particularly good. Compiler/language-design skills are far rarer than library design and implementation skills and the required infrastructure for compiler experimentation is far larger and more expensive.

It would make perfect sense for the major users of C++ and the major vendors of C++ to chip in a few tens of thousands of dollars a year each to create and maintain such a "C++ design and validation lab"—but they don't seem interested. It is a variant of "the tragedy of the commons" that they would rather spend 100 times more money on something proprietary in an attempt to gain a differential commercial advantage.

DK: I know I'm going to get a lot of flak for this but I'm starting to sense a Concepts déjà vu with rvalue references. Initially, rvalue references were meant to be transparent for most users but that's no longer the case. Joe Coder will probably have to know what a move constructor is; that function overloading rules have changed; that the following signatures have different semantics: void A::f(); void A::f()&; and void A::f()&&; and that rvalue references no longer bind to lvalues. Aren't rvalue references becoming too complex, unstable, and pervasive too? Are they really worth the trouble?

BS: Again, I object to the "Joe Coder" moniker. At best, it is patronizing. 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.

Bjarne Stroustrup: You may be right in feeling a similarity between concepts and rvalue references.

All language design is layered. At the most casual level, programmers simply use std::vector or a Matrix class and find that performance has improved. Only if we look closer do we find the move constructors that are the source of the improvements (moving a container is far cheaper than copying it). At the next level, programmers write move constructors and "perfect" forwarding functions. Only where std::move() and std::forward() become insufficient is there a need for more than a superficial understanding of rvalue references. Most programmers need not go there—and in my opinion, far too many programmers agonize over obscure details, such as "what does void A::f()&&; mean?" and "how is std::move() implemented?" I try to understand and answer such questions only when I have a reason to. Most programmers could use their time better writing idiomatic code; we need good programmers far more than we need yet-another language lawyer.

You may be right in feeling a similarity between concepts and rvalue references. Both are type system issues (and therefore inherently pervasive and complex) and both have a "user interface" that saves sensible programmers from the details. However, "concepts" is by far the larger, and in the long term, the more important of the two features.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap