Future support for C++0x in Sun Studio

Question

I've recently been having to defend my choice of using the sun studio compiler against several gcc advocates here in the office. The one reasonable issue they keep bringing up is when the upcoming C++0x (more like C++1x or even C++2x at the pace the standards committee is operating at) features will be available in complete fashion in sun studio. They say, and I have to begrudgingly agree, that judging by the amount of time it took studio to support boost (template templates, certain partial template specializations, etc), there could be a long delay between the release of gcc's C++0x support and that of studio's.
I understand that many of the new features of C++0x, even from initial glance, appear to be quite complicated, especially lambda functors and their associated []/auto return types, variadac template parameters and class concept checking. In addition, I understand gcc has an unfair advantage so to speak since it is being used as the test bed for many of the committee proposal submitter's proof-of-concept implementations (the variadic template parameter feasibility implementation written for gcc comes to mind).
Could a developer please assuage my fears and inform me that the studio team has a roadmap/timeframe in place to release a studio that fully supports the new language-level features in a reasonably competitive time frame? It apparently will be the responsibility of the STLPort team to essentially copy many of boost's libraries (shared_ptrs, random numbers, type_traits) and rename them and move them to the std namespace and also supply the new unordered<> containers, to name a few.
I for one can't wait until boost::mpl, boost::fusion, boost::format and others are all reduced from 10's of 1000's of lines of pre-processor generated crufty template definitions to a single variadic template declaration. Also, I won't feel quite so willfully derelict to efficient code every time i bust out an std::for_each and drop in a boost::bind generated functor and instead can use a lambda function with the various efficiency gains ranging from direct referencing to the stack variables passed in as the closure arguments to the ability for the compiler to actually inline the body of the lambda function where appropriate.
I'm in no way trying to accuse you compiler developers of being slow to implement features, but just would like to be assured that there is nothing to worry about and there is a plan and current work being done on the required features. I know it's still a couple of years off, but I personally can't wait to replace hundreds of lines of boost::bind() calls with their more efficent lambda equivalent, and in addition clean up interfaces that could have used boost::bind if it weren't for the unacceptable overhead introduced often executed blocks of code.
Thanks,
Chris Knight - Faithful sun studio user through at least 2 major name changes and since at lest when it was called Forte 4.2 and RougeWave and classicIO libraries roamed the earth in vast quantities.
P.S. I truly fear that the other 3 major compilers (gnu, intel, ms) will be out the door with C++0x in around the same time and boost will then willingly drop support for the sun compiler if it doesn't support the required language features at that time as they had no problem not supporting studio at all until Studio 12 so I'm sure as soon as the 3 compilers they run nightly tests with support it, they'll be just as eager to
make use of the new features as I am.
This leaves someone who has based their entire system on Solaris + SunStudio + Boost in a potentially undesirable situation. Solaris is far too stable and Linux to ever-changing to ever consider Linux as a platform for critical systems yet the idea of running g++ on Solaris w/ gcc's propensity to change their ABI on a weekly basis gives me immediate heartburn.
Thanks again.

Answer 1

You raise some very good points, and believe me, we are even more aware of them than you are!
Short answer: We are planning to bring out a compiler conforming to C++0X in a timely fashion.
Longer answer:
Right now, we are working on providing binary compatibility with g++ as an option in the next compiler release. When we are done, you will be able to use g++ headers with Sun C++, and link the code with binaries created by g++. The first implementation will be on Linux. (Which versions of g++ and which versions of Linux? Stay tuned.)
Implementing all the new features of C++0X will require a re-design of parts of the compiler front end. The current compiler organization does not support "concepts", for example. (We've been looking for an excuse to re-design the front end for a while, and C++0x is not just an excuse -- it's a requirement.) With the g++ ABI work done, we'll ready to start the re-design, and begin to implement C++0x features.
We won't release an official (stable, fully-supported) product with C++0X features until the standard is final. Until then, any feature could change in unpredictable ways. We got caught by that problem with C++ 4.2 and C++98 -- we implemented what we thought were final features that changed dramatically after we released the compiler. We won't do that again. Compiler stability is one of our most important considerations.
Beginning some time next year, we expect to have Express releases with some C++0X features. Express releases are our way of providing compilers with experimental features that might not be stable yet. It gives our customers a chance to try them out and provide feedback before they become part of a stable release. That is to say, a feature flagged as experimental is subject to change, and compatibility with other Express or official releases is not guaranteed. We can therefore fix bugs and catch up with late changes in the Standard as necessary.
We have not yet done all the planning for our C++0X compiler, so I can't give you any estimates about specific feature availability and time frames. When we are farther along, we'll post the road map on a public site, and I'll announce it here.
Steve Clamage
Sun C++ Team