JonHoyle.com Mirror of MacCompanion
http://www.maccompanion.com/macc/archives/October2009/Columns/AccordingtoHoyle.htm

Resources

Ixquick

Google

macCompanion

Internet

Alternative Energy User Group

 

Amazon Wishlist

 




 

oxysilver

 

Mountain House--The #1 Backpacking Food!

Nitro-Pak

 


Visit StepHouse Networks. Broadband DSL for Apple Users




 

Consultants

Developers

Devotees

Forums

Jobs and Carreers

Mac 3D

Macazines

News

Think Different

 

According to Hoyle...

 

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

 

October 2009

by Jonathan Hoyle

jonhoyle@mac.com

macCompanion

http://www.jonhoyle.com

 

C++0x is the designation for the upcoming C++ 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.

 

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 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 happy.

 

Similarly on the Macintosh, Apple's move away from the Carbon API is dealing a major body punch to C++.  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, Apple has an Objective-C++ language 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, 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 this period, the ANSI Standards Committee released an updated specification containing bug fixes and wording improvements. These defects were documented in Technical Corrigenda 1 in 2003. 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 std::vector<> container must be contiguous. This updated version of C++ is referred to as C++ + TG1, 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 September 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