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.
Nothing comes close to C++ in terms of versatility, features, speed and overall professional appeal.
http://www-users.cs.york.ac.uk/susan/joke/cpp.htm
This one still makes me laugh
moi
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.
As someone who spends all day developing a C++ library for massively parallel engineering simulation.... I'm really excited about this announcement. My team has played with some of the early C++0x features in Intel's compiler and GCC and we're definitely going to be adopting a few of them, but can't commit ourselves until they are a bit more universally available.... which now, they hopefully will be.
C++ certainly still has it's strong points over many other languages... especially when you need that cross section of good OO design and performance (like we do). There are many things I love using Python for but there a also a TON of times I need complete control over everything in order to get the most out of the machine I'm using.
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
Seems to be N2909, revised as N2923, and voted into the draft in July 2009.
On a side note, the new std::forward_list does not have size() at all, so for those scenarios where having size is superfluous (either because you don't want to pay the overhead of an extra size_t for an empty list, or because you want to splice ranges), you can use forward_list for best performance.
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... ")
Actually, the two most popular Unix variants -- OS X 10.5 and 10.6 -- are officially Unix.
Do you even lift?
These aren't the 'roids you're looking for.
Because undefined (as in changing depending on the circumstances) complexity is worse than "always the same but depending on the implementation".
I'm sorry, but I reject that outright. Optimizing compilers have been surprising us with unexpected gains for years, but as long as they don't worsen the situation, no one minds. I can't think of a situation where an optimization that falls back to the default behavior in the absolute worst case but offers a nice speedup in others is a bad thing.
I don't claim that I'm a supergenius and that I spent 30 seconds solving a problem that the libstdc++ guys have been working on for years, but I don't accept that the flaw in my idea is that it only gives an improvement 99.9% of the time and falls back to the old behavior in the other 0.1% of cases. In every other software realm, you'd call that a successful optimization.
Unless you depend on size() being slow for some reason, in which case you're using the wrong language. But that's a different discussion.
Dewey, what part of this looks like authorities should be involved?
Plus like it is now allows the spec to make simple and clear complexity promises (list::size() is O(n), splice is O(1)) without having to specify how the implementation should work in too much detail.
If you still document it as being O(n), but it's actually O(1) most of the time, I promise you no one will mind.
Dewey, what part of this looks like authorities should be involved?
Just as a side note, regarding "objectified int" - the term "object" in C++ standard actually comes from plain C, and doesn't have much to do with objects in OO sense. I'll just quote the C99 spec:
3. Terms, definitions, and symbols ...
For the purposes of this International Standard, the following definitions apply.
3.14 object
region of data storage in the execution environment, the contents of which can represent values
No, that's not reasonable. If std::list doesn't track size internally, it is still possible to have an O(1) size() equivalent by tracking it yourself. If it does track size internally, it becomes impossible to have an O(1) splice() equivalent. That's very important for moving sections of memory around in a resource-constrained environment.
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?
One of the main reasons why C/C++ are so popular is precisely the reason why there are so many complications with it. It's fast; it deals at a low level and gives you full control over what you're doing. Want something bounds-checked? Bounds check it. Don't want it bounds-checked? Don't bounds-check it. This sort of stuff falls over to assignment operators. A higher-level language, when you assign from rhs, will generally just automagically duplicate all member arrays and objects, even strings. Do you really want that? Well, it really depends on the situation. Sometimes you want it duplicated. Sometimes you want to point to it. And sometimes you'd rather seize it (thank you, C++0x move operators!). So by default, the programmer has to have flexibility in assignment. Which means that you can't count on simple assignment from any of your children if they can be arbitrary datatypes (such as from a template).
It's a feature, not a bug; it's an inherent complication from giving the programmer power to control how things happen. But, you know what? Give me that power. Contrary to what some would assert, performance *does* matter. I'm sick and tired of lazy programmers assuming that *their* app can afford to waste CPU and memory like there's no tomorrow and yielding up the gains of Moore's law to bloat.
C++ had a lot to criticize before. C++0x gets rid of most of it. You know, we no longer have other languages laughing their arses off at what passed for a foreach loop before with iterators over stl object making the for loop take 150 characters to write. C++ now has coding simplicity in many cases over a lot of languages that run at 1/10th its speed. It's still not perfect (the whole stl library needs an object-oriented makeover -- and can we finally instantiate main as "int main(std::<vector> args)"?). However, it is a big step forward.
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 :)