Standards love to add things. They remove very little, but they do like to deprecate. This post will describe a collection of things that is heading that way, or not heading that way in C++ 0x.

In my posting on Intention to deprecate trigraphs in the next C++ Standard, we successfully demonstrated that much of the non-English speaking world will still need to rely on trigraphs as a way to get to UCN through "\" which may be inaccessible in some codepages. So we would object to deprecating it without an alternative.

In the last meeting in Santa Cruz, an alternative was proposed in Core issue 789:Replacing Trigraphs. In short, it does not so much deprecate trigraphs (which we like) as move trigraphs out of translation phase 1 so trigraphs are not recognized ahead of raw strings, but is still recognized ahead of other strings (as it is now). It seems that trigraph interaction with raw strings was always the real issue behind the original National Body comment. This interaction had become more prevalent because Raw strings are accepted as part of C++0x. This proposal will level the playing field to what it was again.

We reviewed the paper as a way of fixing the interaction of trigraphs and raw strings. We think the paper is ready to go, but we're holding it back because we're considering other approaches, including moving UCNs out of translation phase 1 or moving raw string recognition into phase 1.

We're still looking at deprecating exception specifications. Our current feeling is that we will deprecate them except for the ways of saying a function doesn't throw at all (e.g., the new noexcept feature, still being reviewed). This feature has been shown to be relatively useless since its inception.

We did a straw poll on deprecating or removing exported templates. I voted to support removal of export to reduce dialecting C++. However a straw poll in full committee seems to prefer deprecation. This feature has been implemented exactly by one company, and even their lead is not opposing its removal. We appreciate their selfless sense of the C++ community and appreciate their sacrifice in learning about why this feature was problematic. Sometimes, it does take doing to see the whole picture.

Finally, we deprecated the semantics of the register keyword. This keyword has been ignored by most compiler that I am aware of, so it is the right time to deprecate it.

As with all deprecation, have no fear. All compilers will generally continue to accept (and or ignore) these cases, so that your code will continue to compile.

Santa Cruz is a wonderful location for us to decide weighty matters such as how best to ship a C++ Standard with the overloaded number of issues. Normally a surfing town as I am told, I have not had a chance to even make it to the ocean shoreline as yet even though I am only mere blocks from it. So busy we are that let me waste no more time and recap.

1. P.J. Plauger (or Bill Plauger) has been the convener of the C++ meeting. There was an attempt to stop processing any new features in order to facilitate our promised shipping date for the Standard. The problem is what is new? Some issues are discovered late and are serious if not fixed. Some new issues are truly wish list and should be stopped. Other issues are somewhat in between but need to be weighted with all the other.

The vote that tried to stop all new feature failed probably because of how ambiguous the wording is, in my opinion. The issue isn't about stopping consideration of any new feature, but balancing all features based on their seriousness and only being able to handle a fixed number of them based on resource.

But the problem with that model of triage (which is often done in software industry), is that we are all volunteers and you just can't easily make volunteers do the hard thing, when they would rather do what they like.

The end result is that P.J. Plauger has tendered his resignation as convener. I and many would like to thank him for his service and his guidance which has enabled C++ meeting hostings well into 2011.

2. Both Evolution and Core Committees met in addition to Library. Evolution had to deal with a number of pending additions which had been long promised. The most significant discussion is the proposal to add Asynchronous and Futures to C++. This is a higher abstraction for concurrency that allows independent action with a return value.

This was controversial because there were two leading candidate proposals. The majority of the discussion allowed a unified proposal which offered:

• A restoration of the variadic thread and async functions. This restoration is a consequence of analysis and request of the British Standards Institute.
• A convergence on the "as if a new thread" in the launching of asynchronous work. This change avoids undefined behavior arising from any delay in destroying thread-local variables, but requires careful implementation to avoid excessive overhead.
• Removal of the is_ready, has_exception, and has_value query functions. The presence of these function requires still other functions in the synchronous case. Evolution Working Group direction is that the complexity in interface is as yet unjustified, and prudence dictates a smaller initial interface.
• Unspecified behavior for the use of timed wait functions when the unique_future was created from a deferred async.
• The conversion from unique_future to shared_future will execute any deferred work.
• The use of an enum class to better clarify the launching policy.

Interestingly, this discussion really only have bearing on two Library proposals which I will detail in a following blog post.

The formal motions for C++ Core language which resulted from this include the usual group of defect fixes, numbering into the 70 range. Basically, all Ready and Tentatively Ready issues of
n2962 except issues 799, 812, 861, 919, and 920.

There was also a paper called Reaching Scope of Lambda Expressions

n2998
Current lambdas restrict the referents of a lambda expression to the immediately-enclosing function or lambda expression. This restriction is severe and does damage to the utility of the lambda feature.

For example, a simple matrix multiplication kernal would require two enclosing scopes and there would be no captures. It is essentially equivalent to saying that the body of a nested loop cannot access function parameters.

Much of this is from the paper.

Consider the following function to multiply square matricies.

matrix operator*( const matrix& a, const matrix& b )
{
    int n = a.numrows();
    matrix c( n, n );
    for ( int i = 0; i < n; i++ ) {
        for ( int j = 0; j < n; j++ ) {
            double t = 0.0;
            for ( int k = 0; k < n; k++ ) {
                t += a[i][k] * b[k][j];
            }
            c[i][j] = t;
        }
    }
    return c;
}

Its rewrite into functions and lambdas, as intended by the adopted N2550, is as follows. Note that the rewrite is approximately the same size.

matrix operator*( const matrix& a, const matrix& b )
{
    int n = a.numrows();
    matrix c( n, n );
    for_range( 0, n-1, [&]( int i ){
        for_range( 0, n-1, [&]( int j ){
            double t = 0.0;
            for_range( 0, n-1, [&]( int k ){
                t += a[i][k] * b[k][j];
            } );
            c[i][j] = t;
        } );
    } );
    return c;
}

However this straightforward reformulation is ill-formed as per N2927 wording for 5.1.1 expr.prim.lambda paragraphs 9–12. To make the code well-formed, the function must be rewritten as follows, where inserted text shows new code, which sometimes alter variable references.

matrix operator*( const matrix& a, const matrix& b )
{
    int n = a.numrows( );
    matrix c( n, n );
    for_range( 0, n-1, [&]( int i ){
        const matrix& a1 = a;
        const matrix& b1 = b;
	int& n1 = n;
	matrix& c1 = c;
        for_range( 0, n1-1, [&]( int j ){
            const matrix& a2 = a1;
            const matrix& b2 = b1;
	    int& n2 = n1;
	    int& i2 = i;
            double t = 0.0;
            for_range( 0, n1-1, [&]( int k ){
                t += a2[i2][k] * b2[k][j];
            } );
            c1[i][j] = t;
        } );
    } );
    return c;
}

Such extensive mechanical editing will inhibit use, make errors more likely, and complicate code maintenance. Such editing is properly the domain of the compiler.

A third proposal n2989 "Unified Function Syntax" was not moved after significant discussion on whether it solved significant problem or not especially at this late stage, or just merely being a stylistic wish, especially if you have written large amounts of lambdas with the late specified return syntax and found current syntax ugly.

There was controversy because a previous proposal on auto lambda syntax was moved on the contingency that there would be room to explore a unified function syntax. However, as with all agreement in such a committee, the promise is always to allow the work to go forward with all the resource costs (such as authors and collaborators working together, review committee going over the proposal in this case over eight hours over several day), but there is no promise that it would be accepted. Such was the case, and of course the disappointment of the authors of this paper.

Well, in the next posting I will go over the Library proposal.

The mailing for the July C++ Standard meeting has been released. For those who do not understand this process, this is basically where everyone writes up their work for the upcoming meeting so we have something concrete to discuss.

IBM has submitted 2 papers. One is a direct response to the proposed trigraph deprecation as discussed here:

http://www-949.ibm.com/software/rational/cafe/thread/2293?tstart=0
and
http://www-949.ibm.com/software/rational/cafe/blogs/cpp-standard/2009/06/03/intention-to-deprecate-trigraphs-in-the-next-c-standard

are posed in these papers:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2910.pdf

We have also submitted a paper based on IBM research:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2911.pdf

on how to improve compatibility between C++ library implementations for C++ iterators:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2913.pdf

I will say more on these papers in a future blog.

Hi, all. I apologize for the lack of updates as an addition to the family has kept me hopping. But just as important is where is the C++ Standard, so here is the long delayed trip report.

The C++ Meeting in Summit, NJ on Mar 1-6 was the first meeting we had after the draft release for public comment of the C++ 0x Standard. In this meeting, we addressed the various National Body comments based on the draft that was released in the September San Francisco meeting.

A list of the National Body Comments can be found here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2837.pdf

Out of these National Body Comments, there were:

National Body Comments	Unresolved	Accepted	Modified	Rejected	Total
Core Language	93	32	8	43	176
Library	128	36	5	35	204
Editorial	28	148	14	21	211
Total	249	216	27	99	591

As a rough count, there are :

• Language
  • 70 features
  • 300 defects ( in the C++ Standard)
• Runtime
  • 70 features
  • 230 defects ( in the C++ Standard)

That is a lot of features and a lot of defects. Not all the defects will be in every compiler, because some defects are just textual changes. Almost every compiler I know of will be doing a phased released approach, delivering all these across multiple releases.

One unnamed compiler vendor I spoke to at the recent BoostCon09 joked that it may not be all delivered until 2020. I didn't think he was joking, on reflection.

While I am on BoostCon09, I did a 90 minute talk on the Overview of C++0x and compiler support. The external trip report for that talk can be referenced here:
http://par-con.blogspot.com/
and here:
http://revergestudios.com/reblog/index.php?n=ReCode.BoostCon09
My trip report is here:
http://www-949.ibm.com/software/rational/cafe/blogs/ccpp-parallel-multicore/2009/05/25/the-view-trip-report-from-boostcon09
The video of the talk will be online soon.

From my point of view, the other significant thing that happened was a total rewrite of the section on lambdas. The CD1 version of lambda, a significant feature had no examples at all, and did not deal with many, many edge cases (such as how are arrays passed). This section and its design was discussed carefully and a new section will appear in the next draft, which will address many of these problems.

Another interesting discussion is the intent to deprecate various potentially unused C++ entities. These include the meaning of the register keyword, and trigraphs.

On the register keyword, the intent is to deprecate the meaning of the keyword, which used to be that variables qualified as register may be allocated to a register, at the discretion of the compiler. With today's sophisticated register allocator, this advice is rarely taken anyway, and the compiler often would make independent decision based on an abstract machine with a register file that is far greater then what is normally present.

The deprecation of this meaning is welcomed. The keyword will remain for use by for some future meaning.

On the deprecation of trigraphs, the thought process is that there is concern about the confusion when trigraphs are used in quotes with normal usages of question marks, since trigraphs often start with multiple question marks. This one is more problematic from my point of view as it is not clear how their use will be substitutable on international keyboards where such code pages are not present or is represented differently. It does not seem digraphs will replace all the pieces. I will describe more on this in a future post.

The latest draft as of May 25, 2009 is:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2857.pdf

You can get a really good idea of what is in the 0x CD1, that is different from the C++98/03 draft in this excellent document by Alisdair Meredith. I have not reviewed it for completeness, but it is a great resource:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2871.html

Bye for now, and I will post again real soon.

Hi, I had the honor and pleasure of being invited to visit Professor Bjarne Stroustrup at Texas A & M University yesterday, delivering a talk on C++ in OpenMP:

http://parasol.tamu.edu/seminar/abstract.php?talk_id=586

I will say something more about this subject in the Parallel Computing blog. But I am interested in announcing something that Bjarne shared with me while I was in his office. This is a new C++0x FAQ which he is preparing on this page:

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

I will put this link up as a permanent link on the front of this hub.

Well, this is it!

In this meeting, we voted out a Committee Draft for the new C++0x,
which means all the work items are complete.This is like the C++0x
Standard going out as a Beta. A link to the draft C++ Standard is in
the Overview page under the Links section.

This draft will be available for public comment which we expect to take
all of 2009. The plan is that after addressing those public comments, the committee hope
to vote out a Final Committee Draft for more comments in 2010,
then its straight to the Final Draft International Standard, and then
it becomes an ISO Standard.

But those plans could change, if there are surprises in the comments.

You can find the link to draft in the forum section under C++0x Schedule

Its been 4 years of serious work, with the first item voted in 2004 in
Lillehammer. Here is a quick recap of what we did in the September 2008
meeting:

1. Concepts finally got voted into the core language part of the Working Draft.

Most of the standard library got conceptualized, too, but not all of
it. The rest of the library will get conceptualized over the course of
the next few meetings.

2. Yours truly's (Michael Wong's) paper on User-defined Literals
(formerly known as Extensible Literals) was finally voted into the core
language! This idea was initiated by IBM's Ian McIntosh.

3. Yours truly's (Michael Wong's) paper on attributes in C++ was also voted into the
core language.

3.1 Standard attributes for data-dependency ordering in multithreading
programs were added to the core language, by IBM's Paul Mckenney

4. The Working Draft was voted out as a Committee Draft for ISO ballot.
In about a year, the committee will issue a Final Committee Draft for
ISO ballot, and a year from that, the committee will issue a Final
Draft International Standard (FDIS). After the the FDIS ballot, the
FDIS will become the new International Standard, assuming nothing goes
wrong.

5. The Decimal TR was voted out for ISO ballot, by IBM's Robert Klarer

6. The special math functions from TR1 were voted out as the subject of
a Committee Draft that will eventually become its own International
Standard (i.e. the special math functions will not be in C++0x, but
they will be a separate standard).

7. The COW technique for implementing std::basic_string has been
outlawed in C++0x. This means that the std::string that we provide will
no longer be conforming in single-threaded mode (we don't currently do
Copy On Write/Reference Counting in multi-threaded mode because it's
not threadsafe).

8. You can now initialize non-static members of a class using C-style initializers syntax. Example:

int foo();

struct S {
static const int a = 1; // OK in C++2003, OK in C++0x
int b = 5; // Error in C++2003, OK in C++0x
int c = foo(); // Error in C++2003, OK in C++0x
struct C {
double real;
double imag;
};
// Initializer list:
C c_object = { 0.0, 0.0 }; // OK in C++0x
};

/* Equivalent to: (this is OK in C++2003)

struct S {
static const int a = 1;
S() : b(5), c(foo()), C_object(0.0, 0.0) {}
int b;
int c;
struct C {
double real;
double imag;
};
C c_object;
};

*/

9. enumerations can now be forward declared, as long as the compiler
has enough information to decide the underlying type of the enum

example:

enum my_colours : short; // forward declaration of my_enum with underlying type short int

// When you redeclare the enum, you have to restate the enum-base specifier:
enum my_colours : short { red = 0, green, blue, yellow };

10. A library was adopted for asynchronous futures in multithreading programs.

11. A paper to support bi-directional fences was voted in. This will support IBM's PowerPC architecture.