ISO C++ Committee Approves C++0x Final Draft

Randyll writes "On the 25th, in Madrid, Spain, the ISO C++ committee approved a Final Draft International Standard (FDIS) for the C++ programming language. This means that the proposed changes to the new standard so far known as C++0x are now final. The finalization of the standard itself, i.e. updating the working draft and transmitting the final draft to ITTF, is due to be completed during the summer, after which the standard is going to be published, to be known as C++ 2011. With the previous ISO C++ standard dating back to 2003 and C++0x having been for over eight years in development, the implementation of the standard is already well underway in the GCC and Visual C++ compilers. Bjarne Stroustrup, the creator of C++, maintains a handy FAQ of the new standard."

Comments

My first question.

[140Mandak262Jamuna]

Will they resolve the question of std::list::size() function's speed? It is constant O(1) in Visual C++ implementation. In gcc people are arguing over fine distinctions between "shall" and "will" or something equally esoteric. As it stands in Linux it is Order(N). I am not kidding. My code was scaling fine in Visual C++ going form 10 elements to 10 million elements in a nice predictable N*Log(N) curve. It was frustrating to debug the scaling loss in Linux and to finally realize, the root cause of the trouble was the break conditional evaluation in the for loop. And everyone is refusing to fix the damn thing for six years. We were paying maintenance to RedHat. And they were also giving us the lawyer talk instead a fix.

Ref: http://gcc.gnu.org/ml/libstdc++/2005-11/msg00219.html

Re:My first question.

[russotto]

std::list::size() is O(N) because making it O(1) makes splice O(N).

Re:My first question.

[insane_coder]

See Effective STL Item 5. If size() is constant, then splice() must be implemented in a slower manner. Therefore, whether size() for std::list is constant or not depends on whether you want a fast or slow splice(), and that's up to the implementation. So conversely, you'll see that splice() in Visual C++ is quite slow.

Re:My first question.

[Pontobart]

I hope the GCC guys will not follow this change. This would mean that lots of programs will break at runtime. I use splice() extensively and rely on the constant behaviour given by stdlibc++. Without this std::list is a completely useless class :)

Re:Thank you Bjarne

[betterunixthanunix]

I would say that Common Lisp, with a decent compiler and some attention paid to code efficiency, is most certainly a contender on all of the above. The main selling point of C++ now is habit -- large amounts of existing C++ code and lots of programmers who were trained to use C++.

D is C++ redesigned

[peterhil]

Given all the negative comments about the complexity and misfeatures of C++, I one day decided to take a good look at D programming language.

I know Ruby, Python and Common Lisp, and as I have used Ruby's NArray and NumPy quite much, I appreciate that D language has first class Array objects and vector operations for arrays built into the language. D is also compatible with C and has two-way bridge for Objective-C. The version 2 also supports functional programming.

Overall, D seems to have taken good influences from dynamic programming languages like Ruby and Python.
I wonder why D isn't more popular? Maybe the division of the standard libraries is a big factor?

PS. I have been looking a similar library to NumPy for Common Lisp, but GSLL just doesn't cut it and Matlisp only handles two-dimensional matrices. Of course you can use map, but iterating even slices of two-dimensional matrices with map can be a hassle and is much more verbose than having a good iterator abstraction.

Re:D is C++ redesigned

[Anonymous Coward]

I like D as well. The elimination of many screwy cases from C++ and ability to just link up with C or ASM object files for speed is very nice.

It takes time for languages to gain followers, tools, maturity and stability. Python was started in the early 90s. Ruby was in 1995. I hope D and Perl 6 both become at least semi-mainstream programming languages.

Re:D is C++ redesigned

[man_of_mr_e]

D is not as popular because it largely only appeals to C++ developers who want a better C++. However, unlike C++, D is not standardized by any standards body, so the language can change on a whim by the author. There is also only one real implementation of D, as opposed by having support by multiple vendors (most likely, this is a function of its lack of standardization. Corporations don't want to take on writing compilers for non-standard languages).

Certainly, lack of standardization hasn't prevented other languages, such as Java in the past, but look what happened there. Microsoft was litigated out of the market, and now Oracle is sueing Google and possibly others. This is not very commercial compiler friendly.

There would likely be questions of intellectual property that need to be answered, and grants or licenses of such IP to ensure that third party vendors won't get sued. Yes, I know they say it's open source, but i doubt it has had a full audit and due dilligence done on whether or not it violates any IP.

Don't get me wrong, what they've done with D has been fantastic. I think Walter needs to seriously consider submitting it to a standards body if he wants to go anywhere with it.

Re:Question

[Anonymous Coward]

I think you can easily determine the competence of any programmer by how much they hate their primary language. I've never seen this rule fail when it comes to C++. Almost every expert modern C++ programmer I've met thinks C++ is unsurpassed in a few important areas - yet they can bitch about the language for as long as you keep them talking.

Re:sigh

[Rei]

Thanks to g++, I've been coding in C++0x for months. Programming without it has now become painful. 0x is such a huge leap. I love, love things like:

while (true) thread( [](shared_ptr p){ p->process(); }, Packet::read()).detach();

That's a one-line network subsystem ;) In a loop, hang until you can read a packet, then process it in its own thread, continue reading new packets while it processes, and when a given packet finishes processing, delete it. Your "Packet" base class simply requires a factory read() method and a virtual process() function.

The only "gotcha" for me was that you still have to link in pthread.

Thread pairs very nicely with lambdas. Shared pointers were already fine in Boost, but it's nice to be able to ditch boost where possible. I can't wait for futures to make it into g++ as part of the c++0x standard. Futures + lambdas = trivial inline threading of arbitrary statements.