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.

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.

One of the issue we were concerned about at this meeting was the intent to deprecate trigraphs. We wrote a paper indicating why we oppose this. This was reviewed in the Evolution Committee and many delegates accepted our position and need to support existing customers. This is good for existing trigraph users.

However, discussion in committee indicate that if we can find an alternate way to support these users then we should explore that with the blessing of the committee. I will be looking at alternatives in future postings.

The C++ Standard Library Working Group also ratified four proposals into the C++0x draft.

C++0x Stream Positioning

C/C++ I/O files predates modern file sizes, and are usually based on int or long. This proposal allows them to work better with the new long long type in C++0x.

Specifying the complexity of size() (Revision 1)

This paper addresses the issue of testing size() and not knowing their complexity constraint. This makes it difficult to use containers where testing size is a frequent operation.

Thread Unsafe Standard Functions

This paper does not make C++ Standard functions thread unsafe, despite the name. Its intention is to clearly identify functions adopted from the C standard that need explicit exemption from the general prohibition on data races.

For example, these are already exempt:
asctime, ctime, gmtime, localtime, strerror, strtok, rand,

The following functions may have previously been thread unsafe, but must be thread safe to enable effective programming. By failng to mention these functions, the standard implicitly requires them to be thread safe.

atexit, at_quick_exit, exit, fclose, free, quick_exit, malloc, signal

Furthermore, C++ locale objects are already adequate for thread-safe locales; setlocale() is thread-unsafe.

Fixing freestanding: iteration 2.2

A freestanding platform is one that has an Operating System. This proposal aims to:
· enable the intent of the freestanding specification compliance to be preserved, by adding only two headers to it relative to its C++98/C++03 contents, namely <initializer_list> and
<type_traits>
· maintain the historically low dependency of the C++ language, and of C++ compilers, on a corresponding library

The benefits of this proposal are:
· it enables current users of the freestanding specification to continue using that specification
· it enables compiler implementers to work fairly independently of library supply
· it enables library implementers to work fairly independently of compiler supply

On July 20, I will be giving a talk at Aachen University jointly with Forschungszentrum Jülich GmbH where we have our JUGENE Supercomputer, at the invitation of Christian Terboven, a research associate, whose blog I read regularly:
http://terboven.wordpress.com/

This will be a 3 hour talk to cover the latest updates from the C++ Standard Committee (and there are many) and C++0x Concurrency. Here is the poster:

http://www-949.ibm.com/software/rational/cafe/servlet/JiveServlet/imagePreview/1670/75-75/aachenjulichabstract.pdf

Aachen University carries a large IBM backup / archive solution and are using IBM Tivoli Identity Manager software throughout the whole university (and were the first in the whole world to do that).

For those curious about JUGENE, this is gathered from wikipedia entry.
This is a BlueGene/P with 65,536 PowerPC 450 cores, clocked at 850 MHz and housed in 16 cabinets the computer reaches a peak processing power of 222.8 TFLOPS (Rpeak). With an official Linpack rating of 167.3 TFLOPS (Rmax) JUGENE took second place overall and is the fastest civil/commercially used computer in the TOP500 list of November 2007.

In February 2009 it was announced that JUGENE wil be upgraded to reach petaflops performance in June 2009, making it the first petascale supercomputer in Europe.

On May 26, 2009, the newly configurated JUGENE was unveiled. It includes 294 912 processor cores, 144 terabyte memory, 6 petabyte storage in 72 racks. With a peak performance of about one PetaFLOPS, it is the third fastest supercomputer in the world, ranking only behind IBM Roadrunner and Jaguar. The new configuaration also incorporates a new water cooling system that will reduce the cooling cost substantially.

Do you use trigraphs?
If so, you may be interested that the C++ Standard Committee will vote to deprecate trigraphs (to Appendix D) in the next meeting in July 12-18 in Frankfurt as I discussed in my last trip report:
http://www-949.ibm.com/software/rational/cafe/blogs/cpp-standard/2009/05/27/the-view-or-trip-report-from-the-mar-2009-c-standard-meeting

Trigraph sequences are

??= # pound sign
??( [ left bracket
??) ] right bracket
??< { left brace
??> } right brace
??/ \ backslash
??’ ^ caret
??! | vertical bar
??- ~ tilde

One of the reason they were invented was because a character like '#' have code points that differ across EBCDIC code pages.
It is safe to use '?' and '=' because these share the same code point across all EBCDIC code pages.
Another reason is that on some international keybaords, these characters do not have representation and they must be typed in using this sequence of text. They get replaced in quotes because they are handled in phase 1 of translation and can be replaced even if found inside another token, such as a quoted string, or character constant.

There are some possible alternatives. Digraph supply a subset of trigraphs:

But it does not represent these trigraphs and cannot be a complete replacement:
??! |
??' ^
??/ \
??- ~

Digraphs also are handled during tokenization and must always be a full token by itself. This means it will not be replaced inside quotes.

Now you can use something like an alternative spelling for operators to cover 3 of those 4 cases:
bitor
or
or_eq
xor
xor_eq
compl

But one of those four, '\' truly has no replacement possibility.

Even in the ASCII world, the loss of trigraphs can be problematic if a keyboard does not have backslash. Does this happen? I would like to know.
Loss of backslash also can lead to other characters that are variant, including the half-width backslash in Japanese, and the yen sign in Shift-JIS.

So why is there enthusiasm for this deprecation?

It is precisely because of the ability to replace trigraphs in quotes. They can look like question marks, and in some cases they are especially when inside a quoted string. There is cause for confusion. Specifically, one National Body comment urge the removal of trigraphs because:
'Trigraphs are a complicated solution to an old problem, that cause more problems than they solve in the modern environment. Unexpected trigraphs in string literals and occasionally in comments can be very confusing for the non-expert. "

Are there others, I would like to know. Some folks have mentioned how this can be a problem is modern Perl searches.

I would be interested if you agree with these statements and what opinion you may have on the deprecation of trigraphs.

The next C++ Standard meeting is rapidly approaching. This meeting will be the first meeting after the Committee Draft (CD) for C++0x was released last year in September. A CD is like an alpha of the C++ Standard.

Since then, there has been one update to the CD in December with minor fixes:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2800.pdf

This will be the first meeting where we will process defects, and National body comments. Most people will be watching for any show stoppers which can cause a delay to the proposed schedule of the C++ Std as outlined at the right side panel of this blog.
http://www-949.ibm.com/software/rational/cafe/community/ccpp/standards

So far, from watching the discussion on the reflector, there has not been any major of note. But that does not preclude them from being discovered as we work through the comments and defects.

The C++ Std meeting is open to anyone, and if you are in the Summit New Jersey area (specifically Grand Summit Hotel), and is interested in contributing to the Standardization process, please drop by. But first you need to notify the convener. I can help with that.

As usual, IBM will be sending two representatives to this meeting. Both of us will represent the Canadian delegation.

Something that Java, C++/CLI, and C# already has, is called delegating constructor. This is the ability for one constructor to delegate to another within the same class.C++03 does not have this capability because you cannot name a constructor within the same class in one of its constructor's initializer list. It can use constructors of other class types, including base classes and member objects.

In fact, it causes a serious problem when people who learn these other language come to C++, and try using it because what looks reasonable, will compile and run, but does not do what they think it does.

And it is more common then you think, because in many cases constructors may differ by the parameter list with common bodies. If the constructor can use default arguments, you could common the bodies. If it can't then you are out of luck today:

class A {};//has a conversion operator to double
class C
{
int x;
double y;
void startup();
public:
 //C(): x(0), y(1.23) { startup();} // I can collapse this into the following constructor and common up the body
 C(int i=0) : x(i), y(1.23) { startup();}
 C (const A& a) : x(0), y(a) {startup();} // I can't with this one
};

class X {
  Y y_;
  Z z_;
  void init();
public:
  X() { init() };
  X( int i ) : y_( i ),z_(1.23) { init(); }
  X( Widget w): y_(3.21), z_(1.23) { init(); }
};

class X {
  Y y_;
  Z z_;
  void init();
public:
  X(){ init(); };
  X( int i ) : y_( i ),z_(1.23) { X(); }//I know both constructors are run because I can see it in a debugger
  X( Widget w): y_(3.21), z_(1.23) { X(); } //same here
};

class X {
  Y y_;
  Z z_;
  void init();
  void *operator new(unsigned int, const X*);
  ... //assume we also have corresponding delete
public:
  X(){ init(); };
  X( int i ) : y_( i ),z_(1.23) { new (this) X; }//I know both constructors are run because I can see it in a debugger
  X( Widget w): y_(3.21), z_(w) { new (this) X; } // Same here
};

class X {
  Y y_;
  Z z_;
  void init();
public:
  X( int i, const Widget &w): y_(i),z_(w) { init();}
  X(){ init(); };
  X( int i ) : X( i, 1.23) {  }
  X( Widget w): X(3.21, w) {  }
};

We live in interesting times.

At no times is this more true then today's C++ as we move towards a new
Standard code named C++0x, to be released, tentatively 2009.

But x could be A, B, C, D, E, F

Hi, my name is Michael Wong. I am the Canadian C++ Standard
representative for evolution and language. Robert Klarer is the representative for
library. We would like to invite you to watch this blog for discussion on C++ Standard
happenings. We will use this space to file trip reports on the C++
Standard meetings, as well as interesting happenings in the C++ community.

With loads of new features in C++0x, such as Concepts, Concurrency,
move semantics, auto type inference, new initialization syntax, C++0x
will be promising big things. Can it deliver?

But that is not all. C++ has gone through a renaisance of ideas with
the support of Generic Programming, metaprogramming, and Boost
Libraries. How about functional programming, domain-specific languages or garbage collection?

So come back regularly, and watch the story as it develops.

Thanks.