How interesting.
I’m at the ISO C++ meeting in Santa Cruz, CA, USA this week. Ten minutes ago we had a committee straw poll about whether we should remove, deprecate, or leave as-is the export template feature for C++0x. The general sentiment was to remove or deprecate it, with deprecation getting the strongest support because it’s safer per ISO procedure. Deprecation would not remove it from C++0x, but would put the world on notice that the committee is considering removing it from a future standard.
Note: Nothing is happening to export at this meeting. The effect of this straw poll of the committee was to give guidance to the core language working group (CWG) on the committee’s general sentiment on this issue. The CWG is taking this as guidance to produce a detailed proposal to take some action on export at our next meeting in Pittsburgh in March.
I’ll write a longer trip report in the next week, but this was worth noting in real time because it’s the first time export template has been discussed in committee since the highly controversial discussion of my and Tom Plum’s proposal to remove export at the Oxford meeting in 2003.
Sutter’s Mill 
While I absolutely agree with you that a networking library is much more important and generally useful that a few obscure math functions, I guess the committee here is doing the Right Thing.
Since with their current procedures and bureaucracy (much of which I guess is out of their control) there is absolutely no hope of getting the network library right (although “asio” is pretty close, if you ask me) adding those math functions is easy and uncontroversial, plus proposals and a working design and implementation already existed.
Basically, and I think you do know this, there choice was probably between adding the math library (or other special-purpose and small stuff) now, or adding a networking library in 2015 and nothing else.
I guess sometimes doing the “shortest job first” is the only way to accomplish anything usable.
@Nicol I don’t mean to denigrate the work done on threading. In some sense I agree that it should be higher priority to get in the language standard, since threading needs compiler support, a memory model, etc, whereas you can get by with networking from a third party library like Berkeley sockets, or asio.
However, networking is still a ridiculous thing to be missing from a modern programming language. I wish they’d just break this off into a separate committee, and get it done relatively quickly. No language changes are going to be needed.
Sorry; I meant “many-core”. Chips with dozens of processors, ala Larrabee and GPUs.
Multicore “coming up”. Where the hell have you been these past few years. Multicore is old news!
On Export: Really, if Modules for C++ ever gets done, nobody will miss export (not that it was ever usable). Modules is export done *right*.
@peirz: True, Concepts isn’t in C++0a because it needs polish. But one of the demonstrations of that need for polish was the GCC implementation. Another problem was that the GCC version stopped being developed, so new ideas for Concepts could not effectively be tested. That’s why they need more time on it.
@Brendan: Networking is not a “no brainer” in terms of design. The need for one is important, but not nearly as important as a standard threading layer. Threads will be far more important in the coming years than having to manually abstract the differences between WinSock and the Linux and MacOS equivalents.
Not every application needs networking. Threading is something that, particularly with multicore coming up, virtually every application of any real size will use.
@Brendan
You are right. I’m a bit surprised about the priorities of the standard committee.
Think about mathematical special functions in TR1. Who needs a ‘confluent hypergeometric function’ or a ‘cylindrical bessel functions of the second kind’. Yes nobody, only a few mathematician who already implemented these functions for their special algorithms.
What about a socket or network abstraction library for C++? THIS is really IMPORTANT, not some fancy math functions.
I wish they’d do something to change how the standardization process works… the slowness of the committee to make no brainer changes is ridiculous.
2009, and they aren’t even *talking* about adding a standard networking library.
@Vat: yes, see the excellent discussion of export in the C++ Templates book by Vandevoorde, who’s team of 3 actually implemented it.
@Neil: concepts are implemented in a custom version of gcc, immediately putting it in a different league than export. Most people also seem to agree that it would clean up the huge mess that has become type trait hacking; it’s not in C++0a because it needs polish and that would stall the whole thing.
@Simon: the frontend does the heavy lifting and implements the language/parsing. The backend “just” generates assembly code from whatever intermediate language came out of the frontend.
That should of course be vector of bool – how does one do angle brackets here?
Isn’t this just another example of a feature that should never have been in the standard in the first place? And of a feature that (not coincidentally) was designed by the standard comittee without a working implementation. One thinks of other great successes such as vector and concepts – isn’t it about time that the standard comittee recognised that they should be very, very reluctant to do language design?
To add to hoang’s comment, after this was implemented by EDG, there was a two-part article in C++ Report( by Herb himself, i believe?) about they implementation process. Essentially, export doesn’t work like the standard & people expected it to, and it’s not useful, even if it would have worked like we wanted, it wouldn’t be useful :)
@Hoang: What does that mean in the context of a full compiler? What would Comeau have to do (or have to have done) to implement export on their backend, since I imagine that would be the difficult part?
Export has been implemented by EDG which is the front end for Intel C++ and Comeau.
Forgive me if I’m being ignorant, but was this ever implemented by a compiler? I though export was just ignored by compilers in general…