According to Hoyle...

C++0x Part 1: What is it (and does it even matter)?

October 2009

by Jonathan Hoyle

macCompanion

http://www.jonhoyle.com

C++0x is the designation for the upcoming C++ programming language specification. The original ANSI/ISO C++ spec was released in 1998, and thus is referred to as C++98. Five years later, this specification was updated, fixing mostly textual errors, incorrect wording and some misunderstandings communicated by this earlier spec. This update became known as C++03. However, C++03 did not involve functional changes in the language, so there is little point in distinguishing between C++98 and C++03 (for our purposes anyway).

However, since that time, the ISO committee has been working on true updates to the C++ language, involving improvements for both the novice and the expert. This initiative became known as C++0x, with the expectation that this work would be completed prior to 2010. In late 2007 and early 2008, some (including myself) even began calling it C++09, knowing that it could not be released any earlier than 2009, and not believing that there would be a delay beyond that. Sadly, it appears likely that the standards work will continue past 2009, and even 2010, making 2011 the earliest probable date of publication. The engineer in me would therefore like to rename this C++1x, but C++0x has become so standardized as its name that it has stuck. (Some wags have suggested to looking at the x as hexadecimal, so that C++0B == C++11; I have not chosen to observe this.)

C++ Today

The C++ community is experiencing a bit of attrition these days. Those developing for the Microsoft Windows operating system are finding that C++, once a favorite son and considered to be THE professional programming language for the platform, is becoming persona non grata. Microsoft has stopped all principal development on its older tools (e.g. Visual C++ 6.0) and is pushing .NET. As anyone in the field knows, native .NET development is being done primarily in Visual Basic or C#. Although Microsoft has constructed a frankenstein C++/CLI language to allow C++ programmers to continue developing with .NET, it is an awkward and uncomfortable merging, making neither C++ nor .NET purists very happy.

Similarly on the Macintosh, Apple's move away from the Carbon API is dealing a major body punch to C++ users on the platform. Cocoa development (that which is needed to support the newest features of Mac OS X) is principally done in the Objective-C programming language. Just as Microsoft constructed a compromised C++/CLI language for its developers, Apple has an Objective-C++ offering, which merges the two languages. But this union is not a comfortable one either, and Apple has no desire to change that. In fact, the latest Clang compiler front end being offer in Xcode 3.2 supports C and Objective-C, but not C++ (yet, anyways).

Why this language disjunction across operation systems? It may be a matter of control. C++ is an independent language, controlled by the community at large, and by the ISO committees in particular. It is intended to be a platform neutral language. However, C# is created and controlled by Microsoft. Although technically it has its own standards committee, ECMA: TC49-TG2, the reality is that it is directed by Microsoft. Likewise, no one uses Objective-C anymore, except Apple and its development community. By controlling the primary programming language needed to develop for your OS, you control the development community. Back in the day when platform-neutral languages (eg C++, C, Pascal) were dominant, third party development environments tended to outsell those by Microsoft and Apple. Sure, Microsoft C and MPW had strong followings, but Turbo Pascal, Think C and Metrowerks CodeWarrior tended to outsell them. Today, it would be next to impossible for a third party to sell a C#/.NET solution on Windows which was as good as Microsoft's. Likewise, no one else could compete with the freeware Xcode's Objective-C compiler.

C++ remains strong on the Unix/Linux platforms, however. This makes sense considering that the Linux world thrives on community efforts, and like the Hokey Pokey, this is what C++ is all about. And there is still a huge repository of C++ code out there, including legacy source code, open source code available for developers to use, and yes, even brand new development work. Despite whatever evil machinations may exist in the minds of Apple and Microsoft tool developers, C++ is here to stay, and stay for quite a while.

The Evolution of C++0x

After the first C++ specification was ratified in 1998, a deliberate 5 year period of silence was taken to allow compiler vendors to catch up with the standard, and for the committee to receive defect reports against the C++98 spec. At the end of that period, the ANSI Standards Committee released an updated specification containing bug fixes and wording improvements. These defects were documented in Technical Corrigendum 1, in 2003 as part of the C++03 update mentioned earlier. The changes therein were mostly minor; reiterations of things intended but were not properly spelled out. The biggest change in it was the making explicit that memory allocated by the vector<> container must be contiguous. This updated version of C++ is referred to as C++ + TC1, and became simply C++03, as mentioned at the beginning of this column.

A Technical Report on Library Extensions was initiated in 2004 and completed in January 2005; this report became known as TR1 for short. It recommended a number of extensions to the C++ Standard Library, many of which came from the Boost framework. By April 2006, the Standards Committee accepted all the recommendations of TR1 with the exception of certain high-level mathematics libraries (which were considered too difficult for all vendors to implement). GCC 4.0 has ported of much of TR1 under the std::tr1:: namespace so Xcode users can use them now. Metrowerks CodeWarrior 9 & 10 also had a port of TR1. Virtually all of TR1 has been accepted as part of C++0x, and will be examined in this series of articles.

In October 2008, the Standards Committee released a draft of C++0x, which can be viewed here. The committee is still accepting comments on this draft, and it is hoped that a final document with all accepted revisions can be finalized within the next year.

Coming Up:

C++0x Part 2: A Step Forward

C++0x Part 3: Making Coding Easier

C++0x Part 4: Smart Pointers

C++0x Part 5: Rvalue References

C++0x Part 6: Final Thoughts

To see a list of all the According to Hoyle columns, visit: http://www.jonhoyle.com/maccompanion

http://www.maccompanion.com/macc/archives/October2009/Columns/AccordingtoHoyle.htm