Latest Proposals for C++0x

CodeDemon writes "It looks like the ISO/IEC JTC1/SC22/WG21 working group has made some headway in reviewing new proposals for the C++ language. The long anticipated upgrade for C++, C++0x, may be just around the corner. Head on over to check out the proposals yourself."

Comments

where does the name come from?

[newsdee]

It may be a no-brainer for many of you, but can somebody enlighten me on why the name is C++0x? AFAIK C++ was named as such to indicate it was "more than C" [C++ is C = C+1 for the unlikely few who wouldn't know]. Is this the same kind of nomenclature (0x is zero in Hex), or is it something pronunciation-based ("plusox"?)...

Re:where does the name come from?

[alefbet]

The current version of C++ is often referred to as C++ 98 because it was finalized in 1998. The next standard should be finalized around 2007ish, so it's sometimes informally referred to as C++0x (think Windows 9x).

Anonymous array members

[Surak]

Honestly, I don't see how this is a big improvement. You have, basically:


struct somestruct {
int a;
int [3]; //3 pad bytes
int b;
}


vs.


struct somestruct {
int a;
int pad[3]; // 3 pad bytes, do not use
int b;
}


The only thing its really saving you is the variable name, and its giving you an extra check at compile time to ensure you don't use the 'pad' array. Which shouldn't be a problem with proper variable naming and documentation, right?

How 'bout range checking like purify?

[elwinc]

I think what C and C++ really lack is the option to turn on array range checking. Sure you can drop a couple grand for a purify license or learn to use valgrind, but it should be an easy-to-switch compiler option.

Lots of good papers there

[Eustace Tilley]

I liked this, which supports "Quality of Implementation:"

The development cycle of embedded software does not easily lend itself to the trial-and-error style of programming and debugging, so a stubborn C++ compiler that catches as many errors as possible at compile-time significantly reduces the dependence on run-time debugging, executable run-time support and compile/download/test cycles.

This saves untold hours at the test bench, not to mention strain on PROM sockets.

Williams, Stephen, cited by Lois Goldthwaite in her Technical Report on C++ Performance

Compiler Compliance

[wideBlueSkies]

I haven't read all the proposals, hence my early post, but the subjects look interesting. It'll be cool to see what makes it to the final standard.

But that's not why I'm posting.

It's nice to read about all the standards processes, and I can appreciate all the great work that these bodies perform. But after the standards are completed, and everyone goes home, it seems to take years for the compiler writers to implement the standards properly.

I'm not trying to slam the poor developers who have to implement the changes. But yet, it seems that the standards bodies don't seem to take acutual usage of the last set of changes into account before proposing the next set of standards.

What I mean is this: Take C++ 97. OK? How many of us have actually used a 100% compliant compiler, and used the latest features? Not too many. I know I haven't. But it seems to me that the language masters want to go ahead and move C++ along without getting real feedback from developers about how useful the language changes are.

It's almost like the big boys are saying "well, it'd be nice to have X, Y, and Z in the language" instead of "you know, everybody hates the way we did A, B, and C back in 97. Lets think about fixing that". The language masters, IMHO are basing the next round of changes on their experiences, not the experiences of the developer community at large.

C++ is already a big complicated language. Maybe the standards process should slow down a bit and give us ordinary developers a few more years to catch up.

SCO

[ikewillis]

Watch out, SCO thinks it owns C++:

MozillaQuest Magazine: C++ appears to be one of the properties that SCO acquired through Novell's acquisition of AT&T's UNIX Systems Laboratories and subsequent purchase of Novell's UNIX interests by SCO. At this time most Linux and/or GNU/Linux distributions include C++ compilers and editors. Is this something for which SCO currently charges? If so, just what are the current arrangements? If not, will C++ licensing and enforcement be added to SCO's licensing and enforcement program?

Blake Stowell: C++ is one of the properties that SCO owns today and we frequently are approached by customers who wish to license C++ from us and we do charge for that. Those arrangements are done on a case-by-case basis with each customer and are not disclosed publicly. C++ licensing is currently part of SCO's SCOsource licensing program.

MozillaQuest Magazine: How about GNU C++? Does GNU C++ use SCO IP? If so, could SCO license and/or charge for use of its IP in GNU C++?

Blake Stowell: I honestly don't know.

Re:COBOL

[Surak]

Actually, there *does* exist an Object-Oriented COBOL. (No, I'm NOT making this up!)

It's great to see some metaprogramming related...

[exp(pi*sqrt(163))]

...proposals. Without metaprogramming C++ really is glorified C. But with metaprogramming C++ becomes an entirely new system. The template system is computationally complete (see here for what that means) and so important work can be shifted to compile time. That doesn't just mean computing the answer at compile time, that would be silly. It means procedurally building and optimizing code. For example we all know that C is slower than FORTRAN because pointers (lacking in FORTRAN) bring in variable aliasing problems that stop the compilers reliably optimizing. C++ metaprogramming allows us to claw back some of that loss by intelligently building optimized math routines at compile time. See Blitz++ for examples. The net effect is the speed of Fortran combined with readable high level references to array and vector objects.

Unfortunately metaprogramming is a pain in C++. One of the biggest problems is the lack of reflection in C++ that would allow template metaprograms to easily determine type information. Some of the new proposals would remedy that issue. Also the use of local classes in templates, that is sorely lacking in the current standard, would be a great boon for such techniques.

And maybe one day there will be many more C++ textbooks that don't just relegate templates to half a paragraph in the "advanced techniques" section. Templates are fundamental to C++. If you don't use the benefits of C++ then C++ really isn't that interesting a language. No wonder so many people propose using C rather than C++. It's like programming in Lisp but refusing to use list datastructures.

C++0x is a Frankenstein Java

[Anonymous Coward]

After working on the internals of the Std C++ library for several years I can honestly say that C++ is the biggest mess ever. The ANSI C++ committee is now trying to patch the language into a frankenstein version of Java.

Unfortunately with Java 1.5, some of C++ is corrupting Java, mainly the completely academic confusing implementation of C++'s templates. Why not go for a more easier to understand concept of templates as implemented by languages such as Haskell?

So does everyone else.

[devphil]

The most popular suggestion, during the original standards process, was: every time someone proposes a new feature, they have to also propose an existing feature to be removed.

The followup suggestion: every time someone proposes a new feature, they have to donate a kidney. This ensures that proposals will be given serious thought, and that a serious idiot can only propose, at worst, two extensions.

No, I'm not joking. Those were some of the suggestions that received rare unanamous agreement.

Seriously, everyone on the committee, from Stroustrup and Koenig on out, agrees that the language is too complicated. They even said so before it was standardized. But...

Let's hear your suggestions on which stuff should be removed. Remember that no matter what you choose, people somewhere are currently using it, and you will break their code. No matter what you change, it will cause incompatabilities, which future generations of /. will then bitch and moan about.

Also, since compiler vendors don't like pissing off their customers, they can't really completely remove stuff even when the standard says it's okay.

This will help out companies

[Necroman]

If this standard does go through, aht GNU supports it via gcc or what have you, this will help companies in a big way.

The company I worked for used to write our software in C++, but moved over to java 3 or 4 years ago for the cross platform abaility of this. There are so many core parts of a program that are system dependent, that supporting 8 different operating systems in C++ is impossible without a standard library of some sorts. Add a standard socket structure will be very nice, and most OSs have very different ways of handling this. Threading is also the other huge issue with crossplatform, there is near zero standard on out threading works in C++.

The one thing that the new C++ proposal is missing is a standard widget/windowing commands. But there is no good way to make standard libraries for something like that, the best if to create a general class to create and control widgets, then write the system specific code for each OS you want it to run on.

It's something I'm looking forward to.

Cool

[be-fan]

Modern C++ really is a cool language. Its hardly clean, and its a big beast to learn, but (IMHO) it allows a great deal of abstraction without sacrificing much (if any) performance. Personally, I'd like to see the following features in C++ 0x.

1) Metafunctions. Like Lisp macros, they allow code-generation at compile time. They're less flexible, because they don't allow access to the AST, but they're much better than the current template-metaprogramming kludge.
2) Lambdas. Even if we don't get true lambdas, with continuations and closures, but I'd like to see some sort of anonymous functions. The STL desperately requires it. Overall, I'd like to see more functional stuff get into the language. Unlike many of the other features discussed, lambdas and higher order functions really need language-level support to work well.
3) Type inference. There is a proposal to allow a new use of the auto keyword like such:
auto x = new int;
The compiler will automatically detect that 'x' should be an int*. I've wanted this feature from the minute I saw stuff like:
int* i = new int;
Its so redundant! I'm surprised that Java (whose simple semantics would make type inference much easier) still makes you do stuff like:
foo i = new foo;
An additional motiviation is that:
vector::iterator i = vec.begin()
can be shortened to:
auto i = vec.begin();
C++ is seriously eating into the horizontal space, thanks to namespaces and nested typedefs and whatnot, and type inference would go a long way in alleviating some of that pain.

The nice thing about these features is they keep with C++'s philosophy. Most of the complexity here is in the compiler --- there is no overhead in the generated code.