C++0x Features!

Posted on March 31, 2008
Filed Under Computer Science |

I’m not going to lie, I get things done faster with Python, with less annoyance in Java, and more elegantly with any functional language.

However, C++ is an old love of mine, being the first programming language I ever learned. C++ is still relevant, is still the best programming language for a few different jobs, and the new standard has some nice features. I’ve been scrounging through Sutter’s Mill and the first proposal, as well as Wikipedia’s entry, and the most exciting proposals follow.

Concepts

If you’ve spent enough time reading the C++ standard, you’ve seen that classes sometimes have special names that describe their interface. For example, if a class is Assignable, it defines operator=(). However, there is currently no compiler enforcement for this, which leads to trouble. Let’s say that you write a class, Blarg, with a private operator=(). This is not an Assignable class. You’ll get a compiler error when you use it, but not at the right line.

Let’s say you have this function:

    template <class T> 
    void add_elements(T some_element);

and it requires T to use the assignment operator. With the current C++ standard, if you call add_elements(my_blarg), you will get a compile error, but somewhere inside of the function add_elements().

Why is this bad? We want to see the error at the actual line we made the error! Theoretically, we know that it’s wrong if the input type is not Assignable, so we should be able to see the error at the call add_elements(my_blarg).

Concepts will tell you in one error line what is wrong about the code you entered. If the class you fed an iterator is not Comparable, you will find out in very clear terms that you need to implement a comparison function. ConceptC++ is a project that currently allows you to use concepts, so this is a feature that you can currently use.

From Wikipedia, it looks like the new syntax will look something like this:

template <LessThanComparable T>
const T& min(const T & x, const T &y)
{
    return y < x ? y : x;
}

Opt-In Garbage Collection. Oh Wait, Nevermind. We Were Just Kidding. Maybe Later.

Initially, the committee wanted to include garbage collection as an opt-in feature. It looked like they were going to do a good job, with little-to-no changes needed to get your program fully garbage collected. However, it looks like we’ll have to wait for a TR2 or a similar revision for the garbage collection to make it to the language. This is unfortunate.

Herb Sutter reports that in the October 2007 C++ standards meeting, it was decided that out of the three features that had yet to make it into the draft (concepts, garbage collection, and advanced concurrency libraries), and out of these, Concepts were the most important feature that needed to make it to the draft. The others could easily be released in a future Technical Report specification, much to my chagrin.

Basic Threading Primitives

Threads, mutexes, condition variables, and locks. All you need to do the basics of multithreaded programming. It looks like thread pools are going to have to wait for a future C++ Technical Report, which is unfortunate.

Type Determination

auto a = my_vec.begin();

In the spirit of the new use of the auto keyword, enough said.

That “>>” Template Fix That Was Long Overdue

You know what I’m talking about. The one that doesn’t let you write the following:

  vector<vector<double>> a; // Compile error??

I think we all remember the first time this bit us. For me, it was definitely when I compiled a huge project on a non-standard C++ compiler (It may have been Visual Studio 6.0) and saw that I had hundreds upon hundreds of errors. From the sound of it, this was one of the first things the committee implicitly decided, so they hated it as much as we did.

Regular Expressions!

This is one of the most exciting features of C++. I’ve been using Boost.Regexp for a long time, but the fact that I can now use them no matter what computer I’m sitting at is wonderful. I know that they’re in TR1, but as far as I know, they never make it to g++, making it irrelevant.

Better Random Numbers!

uniform_int<int> distribution(0, 99);
mt19937 engine ;
variate_generator<mt19937, uniform_int<int>> generator(engine, distribution);
int random = generator();  // Assign a value among 0 and 99.

These kinds of facilities have been available for a long time within Boost, but it’s nice that everyday programmers have access to random number generators that aren’t linear congruential. Hash tables and home-brewed crypto schemes will thank the C++ standard library.

Unicode!

Stop laughing, every other programming language. Better late than never, right?

I also really like the syntax for defining different kinds of string literals:

  u8"I'm a UTF-8 string."
  u"This is a UTF-16 string."
  U"This is a UTF-32 string."

Lambdas!

Herb Sutter announced recently that lambdas and closures were accepted into the language. The biggest impact this will have (on my code, at least) is defining comparison functions inline rather than in functors (since I can count on one hand the number of times I’ve needed to store state in ANY kind of a functor).

Who knows? Maybe this change will start to get programmers to start seeing the light on these functional language things. This feature is largely sugar for features that already exist in C++, but this will make C++ code much more bearable to write.

So what do these magical inline functions look like?

for_each( w.begin(), w.end(),
    []( const Widget& w ) { cout << w << " "; } );

O.K., I like how Haskell does it better, but it won’t take very much to get used to this.

Random Aside

This Reddit comment has probably ameliorated the syntax for me:

Think of it as a box. “What’s inside?” “A function! Merry Christmas!”

Popularity: 50% [?]

Comments

2 Responses to “C++0x Features!”

  1. Barry Kelly on March 31st, 2008 5:08 pm

    I would submit to you that the reason you don’t store state in functors is because the language makes it very tedious to do so.

    Take that snippet again:

    —8<—
    for_each( w.begin(), w.end(),
    []( const Widget& w ) { cout << w << ” “; } );
    —8—

    What if you wanted to stream those elements to an ofstream, rather than the console? And you wanted to create that stream on the stack?

    This is a trivial scenario where capturing outer state is useful when you have language features that automate it, but is tedious and not very “shareworthy” without those features. By shareworthy, I mean that the code you’d have to write up manually isn’t very reusable, so consequently you’d probably write a for-loop instead (notwithstanding that that may be the better solution for this particular example).

  2. Bryce on March 31st, 2008 11:15 pm

    That was a sweet rundown. Nice job Jake.

Leave a Reply