The spring 2012 meeting of ISO/IEC JTC1/SC22/WG21 (C++) was held on February 6-10 in Kona, Hawaii, USA.
Here’s the major takeaway: This is going to be a busy year as investment in C++ across the industry continues to increase, and that’s good news for C++.
Here are some highlights from the meeting.
Attendance
This was the second meeting after completion of the C++11 standard. After a standard ships, often attendance will decline for a while, especially if the intent is to “go quiet” for a time to let the industry catch up, as we did after completing C++98.
As you can see below, however, it’s clear that this time the C++ committee is gearing up, not gearing down, after shipping its latest major standard. That’s reflected in record attendance: 73 experts attended, with record numbers of participants from companies like Google and Intel and Microsoft and NVidia, to avidly begin planning for work on the next standard as well as other deliverables even in advance of the next standard.
Full speed ahead, part 1: C++1y
The biggest decision we knew would be discussed was to decide “what’s next” after C++11. Right away on Monday morning we decided that WG21 will immediately begin working on a new revision of the ISO C++ standard, including both language and library extensions, with a rough target of completing work on a new “C++1y” standard in approximately five years. That is, y is hoped to be approximately 7, but that’s intended to be only a rough scope guide at this point.
To have any chance of making y be approximately 7, C++1y can add at most one major new language feature, and there are already more language extension proposals than could possibly fit. The evolution working group (EWG), chaired as usual by Bjarne Stroustrup, therefore spent much of the week surveying the landscape of major evolution proposals we might consider in this round, and we had initial presentations of several, ranging from concurrency and parallelism to modules and static if.
We tried not to make any yes/no scope decisions at this meeting, and so many of these will come up again as updated and further-refined proposals at our next full meeting in October; at that point we intend to start saying yes and no to particular proposals we want to consider for the C++1y timeframe. In the interim, some of the proposals (notably concurrency/parallelism approaches, and the module system proposals) have enough interest that subgroups will hold additional smaller face-to-face meetings this summer in between full WG21 meetings so as to make more progress in these areas; more on this below.
Full speed ahead, part 2: Libraries galore
As I reported form our last meeting, the library working group (LWG) also has already decided to immediately continue working on new extensions to the standard library, and solicited proposals. In Kona, we reaffirmed that the door is open for library extensions, and our LWG chair Alisdair Meredith issued this call for library proposals.
But these libraries aren’t just for C++1y, because the LWG intends to work on shipping new libraries in smaller pieces in order to deliver work sooner and in smaller bites. Some libraries, such as File System and Networking, are big enough and separable enough to work on as independent pieces that can even ship separately from (read: earlier than) C++1y in the form of a Technical Specification (TS). (Terminology note: TS is the new ISO term for what we used to call Type 2 Technical Reports (TR), such as the first Library Extensions TR.)
These smaller pieces will be worked on independently, and once they’re ready to bring to the full WG21 LWG it will be the LWG that decides how to progress them – as part of the C++1y International Standard (IS) or as their own standalone TS or even IS.
Study Groups
Because we’re gearing up for all this work, and so much of its parallelizable, I’ve created the first four official WG21 Study Groups (SGs) that can meet independently to progress their work between full WG21 meetings. These SGs will help to refine and progress proposals faster by working on their own, but will bring all proposals to WG21 as usual for approval and further refinement before anything is published as a TS or IS.
The first four study groups, and their chairs, are as follows:
- SG1: Concurrency and Parallelism (Hans Boehm)
- SG2: Modules (Doug Gregor)
- SG3: File System (Beman Dawes)
- SG4: Networking (Kyle Kloepper)
There will be at least one face-to-face SG meeting, and there may be more. Here’s what I know about so far:
- Week of May 7, 2012: Bellevue, WA, USA (SG1 and SG4)
- (if needed) Summer 2012: Toronto, Canada (SG1)
Looking forward
Besides smaller Study Group meetings, here are the planned dates and locations for upcoming meetings of the full ISO C++ standards committee:
- October 15-19, 2012: Portland, OR, USA
- April 15-20, 2013: Bristol, UK
Sutter’s Mill 
I can only cast my vote for Modules too, but not necessarily because of compilation speed.
Modules enable a *strict* dependency order, which in turns means we could get rid of the infamous **Initialization Order Fiasco** and its counterpart the **Destruction Order Fiasco**.
The mere fact that a specific paragraph in the Standard is required for `std::cin`, `std::cout` and `std::cerr` to circumvent the issue is a clear indicator that there is something fundamentally wrong there.
Personally, there are only two things I’m really really missing in C++11 right now. The first, which I think is quite feasible for C++next, and which only requires a library component and some small language changes, is a proper delegate system. That is a way of binding not (just) a parameter to a function but to bind an instance of a class to a method, which can be stored in std::function or a new std::delegate (slightly different semantics than std::function).
It can be done in C++03, but only with some serious functionality limitations and an ugly syntax. I’m working on the “nicest possible version C++11 can do” which I’ll be publishing some time later, but the best C++11 can do is pretty far from what is ideal, due to one small issue: function/member pointers passed to templates cannot be passed through constexpr pointers because the type system loses knowledge of the linkage of the functions.
It ideally should be possible to write something like:
struct my_type { int method(int const& lhs, int const& rhs) const; };
std::function foo = std::make_delegate(my_ptr, &my_type::method);
With some extra optional std::delegate type parameters to specify the object lifetime policy (raw pointer vs shared_ptr vs unique_ptr, etc.).
The other major feature I’m missing is compile-time type introspection. I saw the Google proposals for the type-rich pointers, but I cannot stress strongly enough how unsuitable those will be for many users. Their biggest problem is that they are entirely non-extensible, and almost every real use I’ve had for introspection has required some kind of metadata that is not part of the C++ type system.
With compile-time introspection, rather than the run-time introspection that Google proposed, it would be possible for me to write the necessary metaprogramming code to generate the type metadata that my application needs. As is, I have to use and abuse some disgusting macros and metaprogramming to get an almost-but-not-quite good enough metadata system (primary problems being the runtime initialization and overhead it requires, as it cannot generate static constant tables of data).
@rbmj: most platforms do have a standard C++ ABI. It is largely only Microsoft’s platform (and various non-mainstream platforms) that has several different ABIs, hailing from the bad old days of non-standardized C++. Most UNIX-like platforms have long since standardized on the “Itanium C++ ABI” (even on non-Itanium platforms) and there’s virtually no problems with mixing compilers.
If MIcrosoft were to more clearly document their C++ ABI (and ideally, document their PDB format too, so other compilers can produce symbols files that can be used by Microsoft’s debuggers), things would definitely look a lot better for C++. In any case, it’s not really the C++ committee’s job, especially given that the ABI is going to be heavily dependent on the platform in various cases (e.g., how dynamic library linking or exceptions work on Windows is very different than how it works on ELF-based UNIX platforms).
Sure. It can be done with multiple inheritance, too, and there’s a few thunking tricks as well. But I think there’s always at least some overhead and it kind of defeats the point of reducing complexity :) .
Its a little bit more work, but you could define a nested class that is a friend of both classes and has a private interface to handle communication between the classes (say it takes a T& in the ctor and then operates on that reference). Then define a method to return an instance of that class. It should optimize and inline down to just calling methods on a pointer. It is more verbose and isnt necesdarily the most elegant pattern, but it works.
friend is also an exceedingly blunt instrument though. It grants access to an entire class, not a specific portion of it, and it requires the object providing the interface to be aware of the implementation of the object making calls into it.
It’s great for granting access to specific friend functions for value types, but not in these one-program-built-of-subprograms cases where you want to define a really fine-grained interface in order to make sure that part-of-program A only talks to part-of-program B via a minimal interface.
Smaller and stricter interfaces are (in my very limited opinion) the number one route to reducing program complexity and that’s what something resembling this idea would help promote.
@Dave:
Isn’t that what friend is for?
And I mean semi-standard ABI. Make it an “optional” part of the standard. This way, on major platforms, you can add a command line switch to the compiler to use the standards compliant ABI, even if it is slightly less optimal. Maybe use generalized attributes (though that would be verbose). And if you’re working on an embedded platform, then you can specify you wish to use a more optimal ABI.
The mild frustration I most commonly run up against in C++ is the coarse grain of class access control (public / protected / private).
In programs which construct a complex system by subdividing it into smaller entities with (generally noncopyable) objects – each component typically designed to slot into this particular system only, rather than being more generally reusable – it’s quite common for the public interface to end up cluttered with lots of functions which are for a specific other class to talk to that class, rather than for general use.
If you could specify something like
class Engine
{
public:
int GetTemperature() const;
public (class Car, class EngineTestBench):
void Start();
};
it would make it clear that although any external entity can check the engine temperature, only a Car object or an EngineTestBench object can ask the engine to start, and some other object (maybe an Exhaust which needs to know which Engine it is attached to) can’t.
It’s not a big thing for libraries, but for real-world programs constructed out of myriad object it seems to me like it would be pretty useful – essentially, this is a feature like const; optional, but improves program self-documentation while allowing the compiler to catch a certain class of errors. (And it looks a fairly easy add to a compiler, with a simple parsing rule).
I think partial classes introduces too much uncertainty into the language.
The one big feature that I see as essential is a standard ABI. I think we would see a lot more libraries written with c++. Theres less incentive to write a library in c++ as any program that uses the library has to use the same compiler. Also, the higher degree of complexity in writing language bindings for these libraries pushes library writers, especially in the open source world where interoperability is key, to write in C.
If we are to be serious about increasing the use of c++ as a library language (which is something it is very good at), then a standard ABI (yes, it is hard) is necessary.
I think they are useful for keeping the code written by people separate from code written by a computer. I’d rather not mix the two in one file if I don’t have to. The status quo has weaknesses, but it allows me to keep computer-generated and human written code in separate files — http://webEbenezer.net.
Are there any channels for mere mortals to participate in the working group discussions?
Opening up the proposal process has been proven fruitful for e.g. Python – additions usually start from a discussion in the python-ideas mailing list and are developed into a formal proposal in open collaboration.
Open process has obvious downsides too – signal-to-noise ratio will be definitely smaller than in controlled environment.
(To bring an example from my personal list: using lambdas as template arguments would open up many interesting possibilities (and functions work, so lambdas should too) – to name one, implementing properties (an oft-requested feature that was raised again during Bjarne Stroustrup’s Going Native 2012 talk) in expressive way would be trivial:
struct S
{
std::property<int,
[] (int& value) { log(std::default_get(value)); }, // getter
[] (int& value, const int& rhs) { log(std::default_set(value, rhs)); }> // setter, assignment not possible if omitted
some_field;
};
There’s a full-featured example at http://ideone.com/jrQzs that explains this better. This does obviously not work as of now – but without getting the discussion started, it never will :). )
Partial classes are an abomination. Why would you ever need them?
“The compilation model of C++ is simply pathetic and it needs to be solved ASAP.”
I hope modules with support for partial classes will be the priority. 2017 isn’t soon enough though.
Thanks, Herb. I appreciate the care with which the C++ standards process has been conducted, which means the care of people like yourself and Bjarne Stroustrup to balance desire for progress with the need to think things through and get it “right”. I wasn’t complaining about concepts’ exclusion, just expressing my own ignorance and misperception of the subject. Thanks for the clarification. It seems that static if will allow, at the least, proof-of-concept of concepts. ;-)
As to my characterization of static if’s potential, it may be grandiose and is unsubstantial as stated. Actual use of static if will be needed to see what boundaries are pushed upon, to determine future advancements for compile-time logic. Unlike my musing, your proposal for static if is well-thought-out, conservative, and concrete.
@David: It was Bjarne who gave his assessment at last month’s meeting that concepts wouldn’t fit into a C++17-or-so timeframe, though perhaps a “concepts lite” based on static if could be interesting and might fit. We’ll have to see how it all goes; it’s early days yet and we’re still in “survey” mode. We’ll know more about what specific proposals the committee is interested in pursuing after the fall meeting when we’ll start making some decisions about what we are and aren’t interested in working on for this revision.
I’m surprised, Herb, to read that concepts almost definitely won’t be included in the next standard, as Bjarne Stroustrup’s article on the subject made it sound like it just wouldn’t *quite* make it into C++11, in which it was originally planned for inclusion. Definite exclusion from the *next* standard relegates it to the back burner.
Since you write of there being room for only one *major* new feature in C++1y, it would help if you would identify features that qualify as “major” enough to be mutually exclusive.
In your earlier comment above, you clearly identify “static if” as a minor feature than can just be thrown in the mix, even though it has a major impact, even allowing implementation of a “concepts light”, “concepts” being described as “huge”. From what I’ve read, implementation of “static if” seems pretty straightforward as to its natural syntax and logic.
Though conceptually simple, I think “static if” has potential for far more impact than has been realized, which will in due course be uncovered. In particular, “static if” opens a world of possibilities by supplying as a first-class compile-time logic construct *the* fundamental element of logic flow — heretofore operational, as such, only at run time or in arcane template “tricks” or in detached and clunky preprocessing directives.
As to static if’s potential, recall that it was only through serendipity that it was discovered that C++ template metaprogramming was Turing-complete at compile time. It’s amazing to think that this capability was “discovered” (like a force of nature) in a feature *after* it was added to the language, not as reason for its inclusion. Further, as Bjarne Stroustrup wrote on page 10 of his paper, “Evolving a language in and for the real world: C++ 1991-2006”, Alexander Stepanov “had inspired me to work harder on generality and efficiency of some of the template mechanisms, but fortunately he failed to convince me to make templates more like Ada generics. Had he succeeded, he wouldn’t have been able to design and implement the STL!”
I believe “static if” has great potential in making logic flow a compile-time, rather than just a run-time, reality. Included in this is making template metaprogramming far less arcane, to look more like “normal” programming. Further, there is a part of the C++ language definition which is “Turing-complete-at-compile-time”, but this “completeness” is in theory only, as the vast majority of demonstrations end in compiler failure, not a complete runnable program that utilizes the arbitrarily complex results of the compilation. The results are just spit out as a “side-effect” to ultimate compiler failure. “Static if” could be a step toward making it possible for a programmer to decide more or less freely what he wants determined at compile time, by the compiler, not by manually entering it, and what he wants deferred until run time. If the “Turing-completeness-at-compile-time” of C++ is consciously developed into a first-class part of the language, with natural flow and syntax, it should be possible to have that freedom and power.
@Ivan: Deprecating old pointer syntax might be nice but since pointers are so widely used and the current syntax is so ingrained (both in terms of habit and culture), I doubt that the standards committee would go for it. It would literally break every C programmer on the planet. Yes, the old syntax would still be available, if deprecated, but if this were the case I don’t think anyone would switch to the new syntax. On the other hand, const ptr[void] vs ptr[const void] is more obvious than const void * vs void * const…
This is minor, but I feel like uniform initialization would be a lot more uniform if initializer list constructors no longer got special treatment, so in order to call std::vector[T]::vector(std::initializer_list[T]) you would need to write std::vector[T] var{{some_t1, some_t2…}}; or std::vector[T] var = {some_t1, some_t2…}; This way no constructors are hidden.
Modules would be nice, but I personally would prefer to see static if. The hacks/workarounds using SFINAE are (IMHO) unnecessarily complicated. Polymorphic lambdas would also be powerful in highly generic code.
The standard library is the most important feature of all, though. I don’t see *any* reason C++ shouldn’t have a standard filesystem and socket library.
(replace [] with angles throughout)
@Andrzej: Right, the wiki is not public at this time.
Hi Herb. The post-Kona mailing often refers to links at address http://wiki.edg.com/twiki/bin/view/Wg21kona2012.
Is it something that only the Committee members have access to?
Despite of my previous rant, if I would vote on one single major feature, it would also be modules.
I believe it would really speed up the compilation time a lot, not having to parse the include files over and over again. Not sure how this would play with conditional compilation though.
Does the “(Doug Gregor)” after “Modules” imply a reboot, or will this continue to build on Daveed Vandevoorde’s work earlier in the C++0x process?
Modules would also be my preferred One Big Feature. Partly because it’s the biggest competitive disadvantage (I don’t think other mainstream languages have great answers to par/conc either, and I don’t think *anyone* has hit on the One True Obviously Correct Way, but almost everyone else has semi-sane modules now). Partly because it’s the one whose absence can’t be alleviated by libraries *at all*.
I so absolutely hope the next major language feature is going to be modules. It is THE number 1 drawback C++ has, compared to any other mainstream programming language. The compilation model of C++ is simply pathetic and it needs to be solved ASAP.
Every day, I see C++ programmers not getting their dependencies right, because there is no clear concept for that. Library A depends on B, but B still includes stuff from A, etc.
Need… modules… .need… modules…. need …..
Argh… bracket eating blog comments…
So new syntax for void star star would be
ptr left_angle_bracket ptr <left_angle_bracket void right_angle_bracket right_angle_bracket
Herb tnx for your answer…
but I have 3 small Y/N questions…
1) Do you see C++Prime(how you called it in one C9 interview) coming before 2020(are there any plans for this) and(super important)
having C++ to human readable C++Prime translator/compiler.
2) Do you see committee simplifying C++17 syntax(eg deprecating raw ptr syntax and replacing it with ptr (so you have ptr<ptr> :))) if somebody makes C++11 to C++17 human readable code compiler?
3) Do you see somebody(MS, Google, FB, Santa :) ) funding some rapid prototyping of C++17 stuff so that committee could actually be more aggressive in standardising.
btw I use word compiler how we used it in college… any source lang to and dest, obviously dest is here also source not asm code.
@pjmlp: Actually our compiler is implementing much of what’s new in C11 (delta from C99) in this release — e.g., memory model and atomics, which are closely aligned with C++11. The jury’s still out on whether many of the features that C99 added should be prioritized over other work (e.g., C++11 conformance) because: (a) some of them conflict with C++ features or are not obviously well defined in a C++ setting with constructors and destructors etc.; and (b) I still don’t see the strong demand for some of them — it’s widely acknowledged, including within C, that C99 was a bit of a misstep while the committee was mostly composed of a special interest group, and at the beginning of the C11 process there was even some discussion about repealing some of the C99 features by deprecating or removing them in C11 (this did not happen though).
@Simon,all: NP, and besides, several “minor” features add up to a major. :)
Concepts definitely won’t fit into C++17 because it’s (a) huge and (b) still experimental and needs more bake time… unless the static if proposal I’m championing progresses well enough to do a “concepts lite” for a subset of the broader concepts direction that is well understood and useful.
The two big reasons why I’m excited about static if: 1. It “will” help bring many uses of template metaprogramming into the language by offering a feature to say directly what templates are (ab)used to say indirectly today. 2. It “may” let us get some of the benefits of concepts sooner — I’m all for simpler features that deliver lots of the benefit of a more complex feature, as long as they are not off in another direction but on the same path to the larger feature in the future if and when that’s ready.
@Mike: If you want to attend a Study Group meeting, just email the SG chair (or me). Here’s some canned information I send to people who email about how to participate in WG21 in general:
Are concepts one of the major language features being considered?
This is great news. I feel with what Ivan said – what “major” is for one person is maybe a “minor” for another. Even so I am thrilled to hear that the whole shebang is in motion. I just love coding in C++ and reading this makes it even more fun =)
I wonder for how long C++ will still be valid.
Personally I like C++11, but on the other hand I think the language is reaching the complexity border, up to the point no one will care about new standard revisions.
A bit like Microsoft is currently ignoring C99 and C11.
Standards are only meaningful if people apply them.
On the other hand any of the mainstream managed languages can also be used as native, and we also have Go and D adoption slowly growing.
Will anyone care about C++17, in what might be a completely different hardware architecture, specially if we consider the evolution of the last 10 years?
@Herb: Hey, I’m not complaining! Just putting my 2c into what I find most attractive in the N*s I’ve seen. On the other hand, I can’t speak for how I’ll feel in ’17 – but don’t take that the wrong way either.
I mean if C++ fails, maybe Herb would develop a passion for the D programming language :)
@Simon,Ivan: Note I said one “major” language feature. I’m sure there will be several. Personally I’m working on (and pushing for) polymorphic lambdas and static if, among others. And a lot can be done in pure libraries, including task-based parallel algorithms and concurrent containers… and as noted libraries don’t necessarily need to wait for the next full standard.
Herb, if someone were interested in getting more involved in this process (e.g. Study Groups), how would you recommend they go about it?
1 language feature in 5 years… sorry to hear that because I think that is pathetic. TBH IDK why even bother… LWG part is nice and needed but I mean seriously IMHO you either make a big change or u are wasting your time… Imagine if next AMD CPU design was projected to be released in 2 y and 7% faster than the current one. Somebody smart would say either make it 30% or dont bother making it… So if you can do 1 feature in 5 years you better dont bother. You think Im just being mean… but seriously c++ either gets all it needs (modules, concepts, static_if …) or it is dead. No amount of PR can change that. And ofc 5y time horizon is a joke. Consider the speed of C# evolution to speed of C++ evolution. Again I know that C# and C++ have “different” funding mechanisms, but that is not the point. Point is that in 5 y people wont really care about the whole philosophical cr*p of ISO vs proprietary…. theyll care that language they use is a modern one. And the fact that you cant make in 5y what is needed to make c++ modern lang today is tragic. Still I appreciate all the hard work done on the C++ by you and other members. My point is that it is either all of the features, C++Prime, or nothing. 1 lang feature is IMO just a wasted five years.
“SG2: Modules (Doug Gregor) ”
You do not know how happy this makes me. You just do not know. The standards committee sounds like they’re serious about making this work for C++1y.
Really, what someone needs to do is take Clang and make a module-ized version of it, just as a proof-of-concept that the idea functions and can provide useful compile-time results. There’s already a “Concept Clang” out there.
For the study groups, will there be additional mailings from these? Or will internal progress and deliberation be kept only by the members of the SG?
Sounds really good. (Hawaii? You bastards! Well, OK, you deserved it!)
If I had to pick *one* language feature, I’d have to go with Modules, in at least the eliminating headers sense (though I wouldn’t complain about a well-defined ABI for, eg dynamic libraries!) I believe much of the “modern” feeling that other (static) languages have is their automatic handling of visibility, if we get far better compile times out of it, so much the better!
Much of the other stuff “missing” from C++ can be done in libraries, in most cases you can just use existing 3rd party libraries or wrap OS APIs. so those are less “exciting”. Rather than trying to get the C++ libraries to .NET framework size, have you (the Committee) perhaps considered some sort of library package specification/site a-la CPAN, PyPl or NuGet? It’s a big, gnarly issue, involving all sorts of cross-platform headaches, but I feel putting the same effort into integrating libraries into the standard library would not give as much benefit.
C#-esque “await” would be really nice, but I’m not holding my breath on that one.