Login | Register   
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
 

The State of the Language: An Interview with Bjarne Stroustrup : Page 3

C++ founding father assesses the language on the eve of its new standard.


advertisement

Let's talk about rvalue references. Will they also be "mostly invisible" as concepts, allowing library writers to implement perfect forwarding and move semantics or will they affect the average C++ programmer's code more visibly? For instance, will C++ have a fifth canonical member function called a move constructor?

Yes, rvalue references are very much a "technical extension" meant to be invisible to 99.9 percent of programmers. Their main effect will be some speedup in the implementation of common containers (e.g. vector) and algorithms.

The basic idea behind rvalue references is that we often copy a value when all we wanted was to move it; that is, after a=b, we have two copies of the value of b, but often the very next thing we do is to destroy b. With rvalue references, we can write a function move() so that we can write a=move(b) to express that idea. If b is something large (e.g. a string or a matrix), the performance advantage can be significant (i.e. a factors rather than a small percent). Such move operations will be sprinkled around in the standard library implementation so that you gain the performance advantage even if you have never heard of rvaluereferences.



For example, some standard library classes (e.g. string and vector) will have "move constructor":


T::T(T&&);

which can basically be read as "Tdoesn't waste time making copies where it can move."

In your recent SD West lecture, you predicted that "concepts are going to be sexy for awhile, then overused and then people will get sick of it. When things calm down, we'll find out when and where they're actually useful." Where do you draw the line between valid, welcome usage of concepts as opposed to "overuse"? In other words, what shouldn't we do with concepts?

I'm pretty sure that was a comment about generic programming in general, rather than about concepts in particular. I'm hesitant to draw a sharp line. Doing so would imply that I thought I knew what would be right (and not) for essentially all people in essentially all application areas. I don't, and drawing such lines is also a sign of paternalistic language design. You can "draw lines" for individuals and organizations (that's what coding standards are for), but not for a set of general language features for a general-purpose language. The point about "general" is that programmers will discover techniques beyond the use cases that the language designers thought of. When a new and powerful feature becomes available, it gets overused as adventurous programmers try to push it to the limit. In the early days of C++, we got inline virtual overloaded functions in multiply inherited classes. When templates were new, we got excessively clever template meta-programming. This will happen again with the C++0x feature set. I just hope that this time more people can tell the difference between an experiment and something ready to put into production code.

"Actually, many of the C++0x features, including concepts, are there to ensure that less cleverness is needed to express interesting things and to make what is expressed better checked."

Actually, many of the C++0x features, including concepts, are there to ensure that less cleverness is needed to express interesting things and to make what is expressed better checked. Naturally, that will free up time and energy for even more extreme/interesting experiments.

What shouldn't we do with concepts? I don't know, but first, I'd use them to precisely and exhaustively express the requirements of generic algorithms on their (template) arguments. That should keep me busy for a while. For starters, there is all of the Standard Library (being done by the committee and in particular by Doug Gregorand friends) and all of classical mathematics. Once that is done, we should have the experience to do a good job at less regular or more complicated uses of templates. However, please remember that the aims are simplicity, regularity, and performance. You don't prove that you are clever by producing the most complicated code.

Is your prediction regarding concepts based on what happened with meta-programming? What is your stance regarding meta-programming in general? Does this paradigm really offer something indispensable or is it sheer "cuteness" that has been overstretched?

Partly, but more directly my guess is based on what happened with class hierarchies and overloading. Every powerful new language feature or programming technique goes through a period of overuse. Later, when understanding is better diffused in the community, the more reasonable, effective, and maintainable uses become standard practice and the "interesting" uses get relegated to experimental uses. I think that there are uses of template programming that go beyond both "classical generic programming" and "cute." I think a first attempt of those would be generative programming where the template meta-programming techniques are used to generate pretty straightforward code, possibly generic code.

Would it be correct to say that concepts make type traits less needed (or even redundant) in C++0x? Or do type traits still offer capabilities that concepts don't have?

Concepts can and should eliminate most uses of traits, helper functions for dispatch, and SFINAEoverloading. Basically, the relationship between concepts and traits is that concepts make overloading simple and straightforward without scaffolding (including traits). For example, assuming a suitable set of concepts we can write:


template<RandomAccessIterator I>
requires Comparable<I::value_type>
void sort(I b, I e);

template<Container C> void sort(C& c) { sort(c.begin(),c.end()); }

template<Container C, Callable Cmp>
	requires Callable<Cmp,C::value_type>
void sort(C& c, Cmp cmp) { sort(c.begin(),c.end(), cmp); }

Picking the right sort()is trivial:


vector<string> v;
// …
sort(v);
sort(v.begin(),v.end());
sort(v,Not_case_sensitive());

There are uses of traits that do not relate to overloading, such as character_traits, which will remain after concepts become universal. However, most of the prominent uses of traits will be eliminated.



Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap