Introduction to C++0x

I’ve just recorded a short video introducing you to C++0x. Unless you’ve been living under a rock for the past few years, or don’t have an internet connection (and somehow still frequent my blog) then chances are you know about it anyway. You may well have been reading Dr. Stroustrup’s FAQ, my own C++0x articles, or some of the many other sources available on the new standard.

Anyway, this video is going to be the first in a series that will cover C++0x features in video form, rather than textual. Enjoy!

C++0x Support Chart, and a Revision to Nomenclature

Image by The Bob Collective via Flickr; unrelated to post... just added for some fun!

Thought you might like to ssee C++0x support for various compilers. Here is a list for GCC, or you can check out this comparison, which features many of the major compilers: Digital Mars’, Intel’s, Microsoft’s, IBM’s and, of course, GCC.

You’ll see that GCC has better support than many, which is in fact why I’ve recently switched from Microsoft Visual Studio to Code::Blocks and/or Qt Creator. I might post a little more about my experiences thereof at a later date. In particular, notice that both MSVC and GCC support long long and nullptr (about which I posted late yesterday). Indeed, long long has unanimous support across all the compilers mentioned in the chart.

And what about the last part of the title? Well I’ve been continuing to say C++0x (and probably will still do so), but as we can expect it’s release sometime this year, I guess I should start saying C++11. Ah well, I probably won’t. That is all.

Related articles

• C++0x Suffix Return Types (sfmlcoder.wordpress.com)
• C++0x Is Official: Unanimously (cplusplus-soup.com)
• Introduction to C++0x (sfmlcoder.wordpress.com)
• C++ 11 Approved (herbsutter.com)

Two Small C++0x Features

I’m going to mention two little C++0x features today. I don’t have much time, but I thought I may as well share them briefly. They’re both fairly small and quick to explain, so let’s get to it. I’ve put the one that’s faster to discuss first. As always, check out Dr. Stroustrup’s FAQ for more information.

I. long long Integers

The C++0x standard has a new type – the long long integer – which is guaranteed to be at least 64bit. No more annoyances because too many compilers make int and long int the same size – use long long int and you can be sure that you’ll get 8 whole bytes of integral goodness!

Apparently this feature was already supported by a number of compilers, but it’s standard now so you don’t have to worry about non portable code (well you do, but you can blame compiler vendors for being slow to comply with the new standard… ). There’s really not much to say here, merely that you have two 64bit types: long long (i.e. long long int) and unsigned long long (i.e. unsigned long long int). Also note the new literal suffixes: LL for long long and ULL for unsigned long long.

II. nullptr

This one’s exactly as the name suggests: that is, the nullptr keyword represents a null pointer. Previously one might have done something like this:

char* name = 0;

In C++0x, however, one can do the following instead:

char* name2 = nullptr;

These two examples have the same result, that is name == name2 would evaluate to true. On the other hand, while we can also assign the value o to an integral type,  we can assign nullptr only to a pointer variable. So the following would yield a compiler error:

int age = nullptr; // compiler error: age is not a pointer

This is all well and good, but it’s quicker to type 0 than nullptr. Why, therefore, should we use the latter over the former? Well the fact is that the double meaning of 0 as the integer 0 and as the null pointer 0×00000000 has the potential to cause problems. Allow me to demonstrate using Dr. Stroustrup’s example. Consider a function f with two overloads:

• void f(int)
• void f(char*)

We call f(0). What happens? Well in fact, f(int) is called, but what if we wanted to pass a null pointer to f(char*). Previously we should have had to resort to something like f((char*)0), which is rather undesirable, in my opinion at least (and, presumably in the opinion of committee members!). So, do the right thing and use nullptr to represent your null pointers.

More on Suffix Return Types

Previously I discusses suffix return types, and I provided an example of how it could simplify notation. This:

Icanos::System::String Icanos::System::FormattedLog::ApplyIndent(const String&);

became this, which I’m sure you’ll agree is tidier:

auto Icanos::System::FormattedLog::ApplyIndent(const String&) -> String;

However, there is another application which is perhaps more relevant. The above example is a matter of scope: String is not in scope before the function’s name, but it is after, so we don’t have to qualify it fully. But the following is also to do with scope.

Consider a C++ template function to find the quotient of two values (yes, I know it’s contrived…). It’s return type depends on the template types passed to it. Indeed, it’s return type is decltype(s / t) where s and t are the values to be divided. But we can’t put this as s and t aren’t in scope before the parameter list. They are, however, in scope after it.

template <class S, class T>
auto quotient(S s, T t) -> decltype(s / t)
{
return s/t;
}

And there we are. It works beautifully! Just as a contrast, here is how Dr. Stroustrup says you would have to do it with C++03/98 syntax. As he points out, it is much more messy.

template <class S, class T>
declytype(*(S*)(0) / *(T*)(0)) quotient(S s, T t)
{
return s/t;
}

While s and t aren’t in scope before the parameter list, S and T (the types themselves) are in scope. Thus we can cast 0 to a null pointer to S and a null pointer to T, and then dereference it. This wouldn’t be acceptable at runtime, but it works as decltype is evaluated at compile time. Though it works, the former solution is clearly nicer.

Read more about it on his FAQ.

C++ Articles

My favourite C++ website, the C++ Resource Network, has just received a revamp – giving it a brand new article system. Articles can now be rated and categorised, and their content can now contain HTML. Not to mention, once can upload files to be attached to the article. All in all it’s a massive improvement, and I can but give my most heartfelt thanks to the site’s operators.

Check out the new articles section now! And you can find my article on there – about C++0x suffix return types. It’s on the blog too, of course

C++0x Declared Types

Sometimes you might want to know the type of an expression. At runtime you can use RTTI (runtime type information) and typeid. But what about compile time? You can use typeof in some cases, but that is a nonstandard extension. C++0x provides a new keyword decltype which adds this functionality to the standard.

decltype stands for declared type and you can read more about it on Dr. Stroustrup’s FAQ. In summary though, if e is an expression, declytype(e) represents the type of the expression. So decltype(4) would mean int and decltype(4.0f) would mean float. Naturally this can be extended to user types.

Note that decltype is supported by Microsoft Visual C++, Intel Composer XE and GCC/MinGW.

class Blog {
	// etc
};

Blog SFMLCoder;
decltype(SFMLCoder) // <--- this means 'Blog'

Read on for examples!

C++0x Suffix Return Types

Time for another little C++0x feature. Like auto, it is supported by Microsoft Visual C++ 2010 and MinGW. If you have a different compiler, then you can’t go wrong by trying it anyway. Just remember that if you get compiler errors, it could mean the feature isn’t supported by your compiler.

Let’s get straight to it with an example. Consider the following example of how we would normally code a function:

bool Init()
{
	// etc
	return true;
}

And here is the way using trailing return types:

auto Init() -> bool
{
	// etc
	return true;
}

Why would we want to do this? It’s more work after all. Well yes, it is more work in this case, but now consider a real world example. In my game engine’s log, I have a function which takes a string, applies some formatting to it and returns it. The string type is a typedef‘d std::string called String in the Icanos::System namespace.

This is how I had written the function before I took advantage of this C++0x feature.

Icanos::System::String Icanos::System::FormattedLog::ApplyIndent(const String& message, const String& source)
{
  // etc
}

I have to qualify the String return type in full. But if I could put the return type after, the String type would already be in scope as we’ve qualified the function’s scope, thus simplifying notation.

auto Icanos::System::FormattedLog::ApplyIndent(const String& message, const String& source) -> String
{
  // etc
}

After the function name, everything in Icanos::System is already in scope, so we don’t need to qualify the namespaces on String again.

Well I hope you’ve enjoyed my introduction to suffix return types – which you may also see referred to as trailing return types. If you’d like to read more about them, check out Dr. Stroustrup’s FAQ.

Coincidentally, it was originally suggested (as noted in Stroustrup’s FAQ) that suffix return types be signified using [] rather than auto. However, due to controversy, auto is suggested as an alternative. Both MinGW and Microsoft Visual C++ generate a compiler error if [] is used.

Related articles

• The C++0x auto type (sfmlcoder.wordpress.com)
• C++0x in Qt (labs.qt.nokia.com)

SFML and C++0x

Having trouble with the latest versions of the SFML 2.0 source in Code::Blocks? Getting errors about long long not being supported in the C++ 1998 standard?

Then go to Settings -> Compiler and Debugger -> Global compiler settings and make sure that Have g++ follow the coming C++0x ISO C++ language standard is checked. This means that the compiler will now accept the long long (at least 64bit) type as part of the C++0x standard.

C++0x!

Image via Wikipedia

If you haven’t yet looked into C++0x, then you really should. While many of the features aren’t of course yet provided by compilers, various vendors seem to have started adding some – I know for a fact that Visual Studio has a fair few. If you want to read about the new standard, Bjarne Stroustrup’s FAQ isn’t a bad starting point.

http://www2.research.att.com/~bs/C++0xFAQ.html

Related articles

• The C++0x auto keyword (sfmlcoder.wordpress.com)
• ISO C++ Committee Approves C++0x Final Draft (developers.slashdot.org)

Beware auto!

So yesterday I shared with you all the joys of the auto keyword. It’s certainly at neat feature, and I know I’ll be using it from time to time.

BUT! There is one point you need to take very seriously with auto, and I can’t put enough stress on this point. Please, please don’t just start using auto to declare all your variables, such as those with obvious types. This is just going to make the code hard to read, and doesn’t really achieve anything. Anyway, auto is longer than int and the same length as char, long, and bool.

My point, is that auto should be used in situations where the type to be used is not easy to write out yourself and not otherwise. As Dr. Stroustrup says on his FAQ, the use of auto is ”obviously most useful when that type is either hard to know exactly or hard to write”. So what does this mean?

Well let’s consider two examples based on those from Stroustrup’s page.