Demand for C++ and Beyond has been exceptionally strong, and so Scott, Andrei and I have got together and scheduled a second “encore” event on December 13-16. It will be identical to the October event: same format, same talks, same location, just making the event available to a new set of 60 people who weren’t able to get into the first one.

See the C&B Encore announcement for details. Registration for C&B Encore will go live soon, as will the finalized list of talks each of us will be presenting. Watch the C++ and Beyond site and RSS feed for announcements.

Today, John Gruber wrote about Internet Explorer 9:

The new UI removes most of the junk from the UI. Kind of interesting how web browsers have evolved to expose fewer UI elements. Most apps go the other way over time.

Of course, that’s because the page/site is the real app. And like most apps they are indeed going the other way.

The browser is not really an app; it’s a shell, like the OS shell, just a runtime necessity to run the real app and provide some convenience housekeeping tools. Shells generally try to remove clutter (though admittedly this goes in waves) because they know they’re not the main attraction.

You can download the just-released Internet Explorer 9 beta here.

The summer 2010 ISO C++ meeting was held on August 2-7 in Rapperswil, Switzerland. The post-meeting mailing is now live, including meeting minutes and other information.

In March (trip report), we voted the last set of feature changes into a Final Committee Draft (FCD) and, after two weeks of scurrying to apply the changes, the result was balloted among ISO national bodies from Mar 27 through Jul 27. That means we received the ballot results and ~250 pages of comments just in time for the start of this meeting, and have busied ourselves with starting to process them.

Where are we in the process?

For this and the next couple of meetings (Batavia IL in November, and Madrid in March), the committee is doing ballot resolution and dealing with national body comments. Because we issued a Final Committee Draft, ISO C++0x can officially no longer add new features. All that we can do is address national body comments, and make any other bug fixes we find.

The good news is that comment volume and content is considerably lighter than the comments on the CD ballot, and we expect to be able to finish handling all of them in two more meetings and, barring any surprises, vote on the Final Draft International Standard (FDIS) for C++0x standard after the Madrid meeting in March. If that happens and that ballot succeeds, the C++0x standard will be published in 2011 and we can start truthfully calling it C++11 and stop pretending about the ‘0’.

Low probability contingency: If between now and Madrid something unforeseen arises and we feel the standard is not in good enough shape to ship and needs more work, the fallback route would be to instead issue a second Final Committee Draft (FCD), which adds another comment cycle and another year to the overall process. We hope that won’t be necessary.

What did we do at this meeting?

In Rapperswil, the Core, Library, and Concurrency subgroups spent the week triaging the comments and beginning to resolve the biggest or most potentially controversial questions first.

We accomplished a lot. Here are the key decisions, some of them tentative:

Attributes: alignment, noreturn, and virtual control. My biggest (but not only) beef with C++0x [[attributes]] is that the standard itself was abusing attributes as disguised [[keywords]]. Attributes are acceptable as pure annotations, but they should have no semantic effect on the program. The problem was that some C++0x attributes did have such an effect, notably the virtual control attributes, so I’ll start with those.

My personal hot button for this meeting was that C++0x not look like the following example, which is taken almost verbatim out of the FCD ballot draft. The semantics are excellent and desirable, but the syntax is clearly not what anyone would design in a fresh programming language:

class [[base_check]] Derived : public Base {
public:
  virtual void f [[override]] ();
  virtual double g [[final]] ( int );
  virtual void h [[hiding]] ();
};

The road to the above was paved with good intentions. But it’s a clear example of adding language keywords dressed in attributes’ clothing, and not something I want to be responsible for forcing three million C++ developers to live with until the end of time.

Fortunately, the committee has tentatively agreed and decided to pursue replacing these attributes with keywords. For the next meeting, I and several other experts volunteered to write a concrete change proposal paper on this, and will include a description of two categories of options:

• fully reserved words, which can break existing user code that uses the words as variable or type names and so would mean we need to pick uglier names; and
• contextual keywords as done in C++/CLI, which does not break existing user code and so lets us pick the ideal nice names, but which would be the first contextual keywords in ISO C++ (and there’s always resistance to being the first).

This week’s straw poll sentiment favored fully reserved keywords over contextual keywords, but both had stronger support than attributes.

The other two kinds of attributes that we considered changing to keywords were [[align]] to specify the alignment of a type, and [[noreturn]] to specify that a function never return. We decided to pursue changing [[align]] to a keyword, and leaving [[noreturn]] alone.

noexcept, part 1: Destructors noexcept by default. This is a tentative resolution to be written up and voted on at the next or following meeting. To me, this is an important achievement, because we have always taught people never to throw from destructors (see Exceptional C++ Item 16, subtitled “Destructors That Throw and Why They’re Evil”) and now the language will enforce that at least by default.

Background: Why are throwing destructor bad? Because any type with a destructor that could throw is inherently unsafe to use nearly all the time. Any type whose destructor could throw is already banned from use with the standard library (i.e., can’t be put in a container or passed to an algorithm), cannot be reliably used as a class data member (because if while constructing the containing object another class data member throws an exception, and then as the destructors of the already-constructed members are called this member’s destructor throws an exception, the can’t-have-two-active-exceptions rule kicks in and the program terminates immediately), and cannot even be reliably used as an array (because if while constructing the array one constructor throws an exception, and then as we call the destructors of the already-constructed objects one of those throws an exception, the can’t-have-two-active-exceptions rule kicks in and the program terminates immediately).

We acknowledged that this change will break some code by making it call terminate. We (not quite unanimously) agreed that such code not only deserves to be broken, but in fact is already broken in a less obvious way; for some examples, see GotW #47. Granted, we know that a small but steady trickle of developers have regularly tried to be clever, claiming they have legitimate uses for a throwing destructor. I’ve seen a number of such claims, and they’ve always turned out to be bad, unsafe code. This change will do the world a favor by making such code terminate deterministically at test time the first time you try to execute it.

If someone really truly feels they are an exception, that’s fine, they are allowed to write “noexcept(false)” on their destructor. Personally, though, I’d recommend that companies consider automatically rejecting attempts to check in any C++ source file containing that string.

no except, part 2: noexcept will be applied to the standard library. This also is important. At our previous meeting, we voted noexcept into the language (and deprecated exception specifications) but didn’t yet have time to apply noexcept to the standard library (which was still using exception specifications, and it’s odd for the standard to keep using a deprecated feature). That will now be done.

First, all empty exception specifications (which is all of them), currently spelled “throw()”, will be replaced with “noexcept”.

Second, all standard library functions whose description include “Throws: Nothing” will be changed to “noexcept”. This is an even bigger improvement, because it changes normative documentation/commentary into actual normative code.

Third, an analysis will be done of all move constructors used in the standard library, and we’ll see if all of those can also be changed to “noexcept”. That analysis will be reviewed at a future meeting and a course of action on this decided there.

noexcept, part 3: terminate stays. It was reaffirmed that if you violate a noexcept specification, your program will call std::terminate and not continue execution in what would be a corrupt state. Stack unwinding is not required.

Looking forward

Finally, here are the scheduled dates and locations for the next few ISO C++ standards committee meetings:

• November 8-13, 2010: Batavia, Illinois, USA
• March 21-26, 2011: Madrid, Spain

Herb

C++ and Beyond 2010 (October 24-27) is filling up quickly. As of this writing, nearly 40 of the 60 places have been taken since registration opened last month.

If you’re thinking of registering, it would probably be good to do it soon. 60 attendees is a hard limit; as I’ve written before, we want to have lots of face time with individual attendees. So once we hit 60, registration will close, although we’ll probably set up a waiting list for those of you that don’t quite make it into the first 60 so that you’ll get dibs if there are any cancellations.

I’m looking forward to seeing many of you in beautiful Snoqualmie, WA, USA this fall.

The Inquirer isn’t normally this silly, and it isn’t even April 1. Nick Farrell writes:

Why Apple might regret the Ipad [sic]

THE IPAD HAS DOOMED Apple, according to market anlaysts [sic] that are expecting the tablet to spell trouble for its maker. … Rather than killing off the netbook, the Ipad [sic] is harming sales of the Ipod [sic] and Macbooks… if the analysts are right the Ipad [sic] has killed the Ipod [sic] Touch.

This is just silly, for four reasons. Three are obvious:

• The iPod Touch fits in your pocket and can be easily with you all the time. Nothing bigger can ever kill it, but only replace it for a subset of users who don’t need in-pocket portability. (Besides, even if all iPod Touch buyers bought an iPad instead, the latter is more expensive and so the correct term would be not “kill” but “upsell”.)
• The laptop has a real keyboard and full applications. Nothing not full-featured can ever kill it, but only replace it for a subset of users who don’t need the richer experience and applications.
• Even if it was killing the other business outright, which it isn’t, it’s always better to eat your own lunch than wait for a competitor to do it.

And the fourth reason it’s silly? Let’s be very clear: The iPad has sold 1 million units in its first 28 days. At $500-700 a pop, that means the iPad is becoming a new billion-dollar business in two months.

Nick, I don’t think “regret” is the word you’re looking for.