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

Re:where does the name come from?

[MrCocktail]

I too read it as "C++ followed by some hex number to be named later", but after skimming very quickly through the proposal, it seems they meant "C++ (20)0x, where x depends on whatever year the spec/implementation/whatever is released". Or, at least, that's what I think it means.

Re:Anonymous array members

[Abcd1234]

Okay, I'm normally not a vocal C++ basher (although I do dislike the language), but this is a really excellent example of the kind of cruft that has made it into C++. It's like everyone and their dog had some pet feature they wanted included in the standard, and the result is a huge mess of stuff that most people won't use but the compiler is forced to support.

I suppose this is what happens when you allow a programming language to be designed by a committee...

More on D

[Randolpho]

I know talking about D is already redundant on this article, but I'd like to anyway. Improving c++ is great, but where c++ *really* needs improvements is the syntax. It's time for c++ to move into the 90s and get rid of the preprocessor. It's unnecessary with modern compilers, and it's a pain in the ass.

One of the stated goals on the .pdf file linked is to make c++ easier to learn, but many of the syntactic kludges in c++ (like the preprocessor and the differences between a pointer and a reference) confuse the hell out of newbies. It's time to adopt a syntax more like Java while retaining the power of native compilation and library creation that c++ gives.

In short, it really *is* time to move to D.

hehe.. sorta

[Cthefuture]

I can understand where you're coming from. C++ is a complex beast. I've been using some form of C++ for over 10 years (well before it was standardised) and I still don't understand everything about it.

With that said, it's an extremely powerful and flexible language. Very much more powerful than Java or C#. The complexity is mostly due to its flexibility. You can do (almost) anything with it. Of course, we can argue whether that's good or bad.

I think C++ can learn from Java though. The default should be to pass all non-built-in-type function parameters by const reference and the programmer has to specify otherwise (basically opposite of the way it is now). That would clean up the code a whole lot since 99% of the time that's what you want anyway. And the standard C++ library should have some sort of garbage collector available.

Another problem I have with C++ is that even with all its power you have no way to get to the "left hand" variable of operations. For example, if you have a matrix class you can overload the "+" operator so that you can do things like "matrix3 = matrix1 + matrix2". However, that's not going to be very efficient (assuming that's why you're using C++ in the first place) because there is no way to get to the matrix3 variable from inside the + operator. That forces you to use a temporary variable to add the two matrices then copy by value the whole matrix after adding matrix1 and matrix2. There are tricks around this problem but none are clean.

Uh, no.

[devphil]

Everyone knows the history of C, coming from B, which came from A.

Everyone but you, friend.

The language C was descended from the language B, which was descended from the language BCPL. Dennis Ritchie never decided whether C followed B because it was alphabetical (in which case C++ would have been D), or whether C followed B because it was the next letter in BCPL (in which case C++ would have been P).

As for the C++0x thing, it's quite common to call languages by the year of their standardization, thus "FORTRAN77", "FORTRAN90", "C89", "C99", "C++98". The next cycle for C++ will be completed sometime in the next seven years, but we don't know exactly which year, so "0x".

Either way, it doesn't look too exciting judging from these proposals. It's certainly nothing on the scale of Perl 6 compared to Perl 5, so yeah, maybe I've answered my own question. This is just a routine standards adjustment, rather than a real 'development.'

Again, uh, no. If it doesn't look "exciting," perhaps you're simply looking at the wrong proposals. Or perhaps you simply still think of C++ as "C with more type checking, and those // comments."

The routine standards adjustment came in the form of "TC1", which was just recently published. Basically, "C++98.0.3p4rc2", to put it in Linux terms. Just bugfixes. C++0x is a different story.

(And I don't know that I'd call Perl 6 particularly innovative, either.)

Re:Whatever.

[Austerity Empowers]

I think C++ is quite useful, and I'm not a "2 week IT person", not that I think they are necessarily inferior beings. On another note, most IT people I know tend to make the most use of Perl/Ruby/Python since it solves most of their problems quickest.

Straight C is my favorite tool and what I use for embedded programming, quick hacks and performance constrained work. Every time I try to do a large application with it though, I find myself thinking "you know, they already did this exact thing with C++, and I'm going to spend 2 days re-inventing this and testing it".

I use tidbits of Assembly (80x86, MIPS, Arm, PowerPC, what have you) in embedded systems for device driver or performance critical sections. As a HW engineer I tend to use this a lot in bringup of new designs, especially "very new" designs that don't necessarily work and every instruction is important.

I use C++ when I am building a very large, flexible application where I use many types of data structures and need it to get up and running in a short period of time. I like this language for "serious application" programming.

I use Perl to manage my file system, do text processing and other maintenance hacks.

I use Java for simple GUIs that often work as a front end for serious endeavors.

I use TCL/TK for ASIC/FGPA debugging (simulator interface) and test suites.

I use fortran less and less (often I convert to C) for purely numerical computation. Gems of knowledge exist in fortran code for optimized matrix related algorithms that are highly useful in 3D visualization.

I have not found any practical use for Pascal or Lisp lately (the latter is useful for emacs, but I rarely mess with it).

The point of all this is that much like you wouldn't use a screwdriver to drive a nail through wood (unless that was all that was available), you would tend to use whatever tool is best suited to a task. Us engineer types are supposed to be tool-makers and users of the highest order. It surprises me when I hear one of us suggest we should use our favorite tool to the exclusion of all others.

I do not like C++ in terms of the performance and memory impact it infers, but when building large applications I do not have time to re-invent a linked list for the umpteenth time, nor do I want to debug every different link list in my code, there are much harder problems to solve more critical to the success of my project. That said, C++ (and C for that matter) is lacking in some very important things. Among those I think are critical are: multithreading, network stack framework (platform independent that is) and GUI framework (platform independent!). If you read the article, you'll see mention of at least two of those things (we need a standard platform independent GUI library dammit!)

Noooooooo!

[timeOday]

In practice, C++ is finally getting to the point where various compilers accept the same code. That after 15 years or so. Now they want to shake it up again?

Re:Noooooooo!

[be-fan]

Its only been about 5 years since C++ 98 was standardized. And GCC has been very complient for about a year now, so it took 4 years for complient compilers to come out. That's really not *that* bad, considering that the latest push for complience was driven by the new wave of "Modern C++" techniques, which surfaced relatively recently. Further, a lot of the new proposals use pre-existing solutions (the Boost libraries are a big help here) and all the code that was added for template support seems to have some reusability value. See Vandervoode's comments about his C++ metacode extension, and how relativley easy it was to implement in the EDG C++ front-end, thanks to all the existing infrastructure.

Re:What C++ really needs to do

[slick_rick]

Delphi stomp who what? I think you mean VB an Java, not Delphi. ( I started with Delphi and remember it fondly, but you don't run across it much in the business world and never have). The reason VB succeeded is obvious, however the Java smash is more subtle. The real key in the enterprise is databases. There is no "one true way" of accessing a database through C++ (ALA JDBC or whatever model VB is using these days, it was ADO when I last had a VB contract.)

The IDEs do also cater to the business community, probably why you don't see more Perl. The fact is "business software" is usually just glue, and Perl/Python/Java/VB/tcl will always be better glue then C++, because they were DESIGNED to be glue and C++ was designed to be the bricks and mortar.

What I would really like to see in C++ would be compile-time exception enforcement ALA Java. I mean Jesus, when you are trying to work with a class library they can't even document what functions may throw what, how the hell are you supposed to write robust code? In Java this documentation comes for free when you write the function, and is forced to be correct by the compiler.