Slashdot Mirror
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."
C++ just keeps on going, eating the brains out of anyone who dares to use it. When template metaprogramming was invented, the language should have been internationally banned by treaty. Now with lambdas, garbage collection, rvalue references, and a host of other features, C++ should be officially classed as a Weapon of Mass Destruction.
As someone who has written software using GObject, FUCK YOU.
There was nothing for RedHat to fix -- you were relying on undefined behavior. list's size() complexity is still undefined in C++0x. You're expected to use iterators and empty() when you want defined complexity.
http://www-users.cs.york.ac.uk/susan/joke/cpp.htm
This one still makes me laugh
moi
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++.
Palm trees and 8
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.
Yes, you hate C++. We get it. Instead of complaining about it so much, just don't use it, stick to your own favorite language, whatever it may be, and leave C++ alone. There are plenty of us who love C++ and wouldn't give it up for anything. We mind our own business, write great code, and try to avoid complaining about whatever it is you are using. Please try to do the same.
std::list::size() is O(N) because making it O(1) makes splice O(N).
Will they resolve the question of std::list::size() function's speed?
Yes. From the most recent C++0x FCD, 23.l2.1[container.requirements.general] table:
Expression: a.size()
Return type: size_type
Operational semantics: distance(a.begin(), a.end())
Assertion/note pre-/post-condition: -
Complexity: constant
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.
Ah, it's articles like this that make me so glad I'm retired!
C++ programmers have it too easy. Why, in C we had to code our own bugs. C++ programmers just inherit them!
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.
You can be an insane coder too, read: Insane Coding
Enough said!
-Chris
Incorrect. The year 2011 A.D. is 7DB Hexadecimal A.D. Ergo, if you're going to abbreviate the numeral using the last two digits you should be heralding C++'DB or simply shorten it to C++'B.
Note: Due to the fact that legacy versions are abbreviated as YEAR mod 100 in radix (base) 10, the new hexadecimal notation should include the a prefix or suffix indicating the radix in use. For quite some time there has existed such a hexadecimal radix prefix in C and C++: 0x
Thus: /* WTF! */ };
Hurray for C++ 0xB;
(Also note the above line does not parse as valid statement in C++, even though the ++ operator actually does take a dummy int parameter as the right-hand-side to differentiate it from the ++C; prefix increment operator.
operator++(int){
For meatball's sake people, even the ++ operator is a kludge in C++? ( "C++" translates to "C (with kludges)" to me.)
Even without any #define macros present, I still can't tell what a single snippet of C++ code is going to do. (Does the simple statement: C++; open a temporary file, and record the number of increments or throw an exception? Should I wrap all such statements in a try / catch block!?) If you haven't studied the entire inheritance graph of the type that the C variable is declared as, there is really no way (beside a debugger) to know what will happen next. (What if a pointer is to a polymorphic class? *my_ptr->operator++(42); Now, it's not supposed to do anything with that "dummy" 42 value, the base type doesn't but a subclass might...)
Don't get me wrong, I code in C++ every day, and prefer it to C, but it surprises me just how messed up things have been allowed to get because we're shoe-horning in features into an existing syntax instead of just creating a new language that has less kludges.
int main() { //Constructed an int "object" by calling it's "constructor" // DOES NOT call the int object's empty constructor. // ERROR, the previous line declares a function. ... }; ARGH.
int my_var_a( 1 );
// ^^^ Uh.. OK ints are object-ified now.
int my_var_b();
my_var_b = 10;
return my_var_a;
}
^^^^^^ Declares a new function in the function/method body WTF? (because C lets you do that, for better or worse... )
use: int myvar; to "instantiate" a new int "object" using the empty constructor instead... So, why can't I subclass an int? class my_number : public int {
Look, it's clearly time to stop hacking extra features into the language, or stop letting it be hindered by legacy C conventions / syntax. I think that C++ could be much better than it is if it weren't pandering to C coders... It's too bad that we started down that path with C++, there's far too much time and energy invested to reboot it now.
I'm glad for some of the new C++ features, but at this point there's not much to celebrate for me -- Doing without for so long has caused us to create our own systems: the C++0x garbage collector is incompatible with my multi-threaded hybrid strategy (pool / slab & heap-like) memory manager (thank Spaghetti Monster, theirs is optional), I already have a ton of code that uses my cross platform multi-threading libraries, we've been using a HashContainer for over 10 years in our company...
C++0x7DB adoption to us means: "Oh great, they finally got around to standardizing all these things we've needed for years and made ourselves -- It's going to be a headache writing new code that conforms to the new standard while remaining compatible with our current code-base."
(And there was much rejoicing: "... yay... ")
Yes, it is competitive with C++, I'm not sure why you felt the need to restate this...
Analogies don't equal equalities, they are merely somewhat analogous.
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.
Did he just go crazy and fall asleep?
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 :)