Slashdot Mirror
C++0x Finally Becomes a Standard
Samfer writes "On Friday August 12th 2011, the results for the final ISO ballot on C++0x came in, and the ISO C++ Standards Committee were unanimous in favor of approving the new C++0x (for now unofficially known as C++11) object-oriented programming language standard which is intended to replace the existing C++ standard. The new standard is to offer new and improved features such as lambda functions, concurrent programming functionality, direct data field initialization, and an improved standard library to name but a few."
Although I haven't heavily used C++ in years, it is nice to see a decade long effort finally come to fruition. Especially nice is the support for type inference which should save quite a few people from RSI and make refactoring code a bit less obnoxious.
After the standard is before the standard...
They said it couldn't be done!
They doubted us!
But we did it!
The ugliest, most fragile, hackiest, most garbled, incoherent, biggest mess of a programming language is now even more so!
Unofficially, ours increments up to eleven!
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
List of missing features:
- coroutines
- multi-stage/active library programming (i.e., something that fixes the syntactical mess of most template libraries)
- precise garbage collection (not that I'm missing it)
- fully opening up of the memory model (allowing libraries to implement complex memory handling such as garbage collection or persistence)
If Pandora's box is destined to be opened, *I* want to be the one to open it.
They didn't call it C++0b
Oh and didn't include garbage-collection outright ( though they did design it with gc in mind ).
...the 11th plague of Egypt has arrived a little bit late.
How do you pronounce that? It's like they want to advertise that this is a baroque language.
As the inaugural copy of the reference manual for the new standard was being printed and bound, it underwent gravitational collapse due to its enormous mass and became a black hole, killing all the committee members. Stroustrup was quoted as saying that despite the misfortune, he still has confidence that the C++0x standard will help programmers be more productive and efficient.
and WOOSH there goes my karma...
Dislike the Electoral College? Lobby your state to join the National Popular Vote Interstate Compact.
...before compilers support it :( It would have been nice to see even a rudimentary garbage collection included but alas... C++ programmers are the most stubborn...
What's with the random links in TFS? Specifically, why link to c2.com for "type inference" and intel.com for "lambda functions"? Wikipedia wasn't good enough for those?
I've been looking at 'C' code lately. Clean, cool, crisp and refreshing Standard K&R 'C'.
I see the small tight executables.
The fast load times,
The tiny memory footprint.
And I ask myself, "What have we really gained with C++?" or any OOP language, for that matter.
The blog title "C++11 considered harmful" is still up for grabs.
Perl 6 should arrive in 2019. p.s., As for lambada functions, I hear the best ones are in Buenos Aires.
RAII and reference-counting.
I prefer using a program that doesn't periodically stop responding for several seconds, and shove all my other programs into swap, while it re-builds its heap.
Go do php work dimwit.
make refactoring code a bit less obnoxious.
Speaking of obnoxious, what's with the 'C++0x' name?
It's nice that they finally got the standard done. But there's so much junk in there. The C++ committee was dominated by people who wanted to do cool things with templates.
Some years ago, someone figured out that it was possible to abuse the C++ template system into doing arbitrary computations at compile time. This developed a fan club. That fan club has dominated the C++ standards committee, because nobody else cared. So now we have a standard for C++ which supports template-based programming a little better.
Current thinking seems to be that,while template programming is too hard for ordinary programmers, the templates will be written by l33t programmers and then be used by the lower classes. Unfortunately, if anything goes wrong, the end user has to look at the innards of the template to find the problem. We went through this with LISP decades ago. Check out the MIT Loop Macro, That finally became stable about the time LISP died out.
Note what isn't in the new C++. There's no more memory safety than in the old one. (Fans will say that it's safer if you only use the new features. Now try to call some library that doesn't use them.) So the buffer overflow attacks and crashes will continue.
C++ is the only language to offer hiding without memory safety. Hard-compiled languages from Pascal through Go have hiding with safety, as do all the major scripting languages. C has neither hiding nor safety; the pointer manipulations are right there in the source. There have been safe, hard-compiled languages without garbage collection, most notably Ada and the Modula family. Safety and speed are not incompatible.
It took that long for a standard update.
Having a nee standard every few years is not good, that's clear.
But spending 8 years to refine/define one sounds quite a lot in the 21st century.
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Sadly no one thought to throw an exception when it did.
...unlike C# which Microsoft seems to enjoy having confusion surround (see the HTML/JavaScript fiasco) or Java, which Oracle seems intent on bringing confusion, branding, and licensing to, C++ has managed to evolve for how many years now? Under a committee of people no less?
Say what you will but I've recently decided to go back to my roots and work in C and C++ just for that reason -- there's never a loud outcry that the languages will die a horrible death or go anywhere. In a world of uncertainties I'm tired of having to wonder what language I'll need to master next.
My reality check bounced.
...for the nect version called C++0xck!!!!
Anyone know if they added nested functions? It's the thing I miss the most when I'm using C or C++ on multiple platforms.
First DNF, then a HURD kernel, now C++0x... Remind me to send some parkas to hell.
Great job, folks!!!!! :-)
Although everyone didn't get what they wanted, overall the new standard is very, very impressive! The new features open up
whole ecosystems of ideas and will allow for amazing engineering of elegant next-generation software in the real world!
1) Multiple inheritance "it's a floor wax! it's a desert topping! it's both!"
BFD. All it does is obfuscate code. There are so many times when an inherited class doesn't do what it should or acts wacky because of something in the inheritance chain.
2) Operator overloading: because TimeCard + MoveTicket + WorkOrder is so much more readable
Really? Ever come across something like this:
'TimeCard >> MoveTicket' or 'TimeCard | MoveTicket' or some weird thing that does nothing like what you'd expect?
I've seen really crazy operator overloading in my time and many times completely unnecessary and hides so much functionality that without stepping into source, you'd never figure it out.
3) Virtual destructors: because the concept is so easy to explain.
pffft.
Errrr. Give me a minute. I'm sure I'll think of something.
All those reasons are fluff. None of them are really that compelling.
Now, if you mentioned something that actually makes C++ shine, like the STL where it saves work with a tried and true implementation, then you may have had something. That and and GUI frameworks are the only things I'd miss if I just programmed Standard C.
Back when C++ first came out to the general public (1990 IIRC), it was nice. It just enough nice features that increased programmer productivity - that's the only benefit of OOP, btw. And the sucky part is with all these features, programmer want to use them. One of my biggest pet peeves is programmers who use a language feature because it's there; not because it adds to ease of development - like creating a template for a class that will never, ever use anything other than a LONG. Why create a template with all of that compiler baggage and subsequent bloat?!?
I blame OOP as one of the reasons for the increasing bloat of software.
You probably posted that comment using software written in C++.
And you probably posted the comment using software written in C.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Necessity may be the mother of invention, but laziness is the lil' bastard's father.
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Let's not confuse interpretted and compiled languages. They are for different things and both have their own merits.
Also, lets get this garbage collection talk out of here, if you call new, call delete. It's simple. Get used to it.
(+ x y z) is perfectly valid in Lisp
So (+ A (* B C) ( * A D))
is better style.
Bad analogies are like waxing a monkey with a rainbow.
So C++ takes another step closer to Lisp (lambda functions) whilst completely missing the most important part (closures and higher order programming).
I look forward to C++ 2031 when they implement garbage collection but still require you to place and remove locks on memory ;)
*Ducks and runs for cover*
Bad analogies are like waxing a monkey with a rainbow.
type inference which should save quite a few people from RSI
... and never coded anything beyond a two-dice simulation.
Because surely, the hard work of writing code is in all that typing.
and make refactoring code a bit less obnoxious
Because yeah, refactoring is all about continuously retyping your variables.
I haven't heavily used C++ in years
My karma ran over your dogma
It's as if you're basing your comments on the GC technology of the early 90's...
Besides, RAII doesn't work unless you have lifetimes that are scoped in some reasonably predicable way. Reference counting doesn't work if you have cycles. Yeah, sure, you can try to use weak pointers to break the cycles, but then you end up introducing additional logic/complexity by having to react to pointers disappearing on you.
There are also various dynamic programming algorithms which simply have runtime memory behavior which is too complex for manual memory management.
That's because in C++, overflow is simply undefined behaviour.
The Tao of math: The numbers you can count are not the real numbers.
Not really. The main advantage of objects is the loose coupling.
I always thought that well-executed structured and modular programming exhibited loose coupling all along, and that poorly executed OO programming would not (and currently does not just by taking a whiff at the majority of the code base out there written in a OOP language.)
But I guess I was dreaming or I was smoking some serious weed, and the reality is that objects are a necessary condition for loose coupling. Silly me.
*facepalm* Only if you, as the article you link to does, redefine the term closure.
Show me the equivalent to:
(let ((foo 1))
(lambda ((+ foo bar))))
And
(let ((foo 1)
(bar 2))
(lambda ((+ foo bar))))
I let you infer the point I'm making ;)
I feel the urge to post a comment, because just too many are criticizing C++0x, where I really like it!
For a couple of months I am following the GCC updates for an increasing portion of C++0x features and familiarizing myself with the implemented ones.
Stroustrup mentioned that C++0x feels like a new language, and I think he's right: the combination of lambda expressions and automatic type deduction (using auto) makes working with data remarkably fluid, without much work (that is: without templating/typedef-ing each data type).
And the new algorithms (did I miss std::copy_if!) and the new data types (e.g. std::thread) are great to have in an STL toolbox, ditching my own handcrafted and now obsolete code. Sure, most of them was/is in Boost, but it feels good that these are standarized to C++ its high standards.
I look forward to the upcoming books of the experts (Stroustrup, Sutter, Meyers, Alexandrescu, ...) for increasing my, yes really, increased productivity even more!
*facepalm* indeed.
The argument the article makes is the same as a C programmer claiming he can implement classes and instances in C using structs and pointers.
True, of course, but a real pain in the arse.
A class instance can be used to simulate *some* of the most basic features of a closure but none of the really useful stuff- and it's a pain.
If C++ supported closures you could replace the ~10 lines of C++ code in the example you linked to with 3- and you wouldn't need to create the clutter of a new class to just to create a closure.
Bad analogies are like waxing a monkey with a rainbow.
If I add a new public function to a class why should have to re-compile all the old code that doesn't use that function?
Other languages can manage not to require that so why can't C++?
Bad analogies are like waxing a monkey with a rainbow.
After all, C++0x has only taken, what, 4 years? Perl 6 has been brewing since July, 2000. (Maybe by Christmas?)
Lisp, the oldest language with GC, solved that problem a long time ago. Here's a simple example for opening a file and writing to it and ensuring all resources are released no matter what happens.
(with-open-file (s p :direction :output :if-exists :supersede)
(format s "Here are a couple~%of test data lines~%"))
Just because C++ can't/doesn't do it/makes it a pain doesn't make it universally true.
Bad analogies are like waxing a monkey with a rainbow.
Not for unsigned numbers it isn't.
I personally like C!!
And then next year we can be more excited and call it C!1!
When we remember we are all mad, the mysteries disappear and life stands explained.
A quick perusal on Amazon didn't find anything called the C++11 Programming Language, which is what I would have expected.
I know I can read all about it online, but I like having real books... okay?
File under 'M' for 'Manic ranting'
Actually, I'd argue that with unsigned numbers, overflow does not exist because unsigned arithmetic is defined modulo 2^N. But anyway, for unsigned overflow throwing an exception would not even be allowed.
The Tao of math: The numbers you can count are not the real numbers.
This standard is late and is full of little quirks.
It has some pretty nice stuff, but some areas still leave to be desired.
Hopefully evolution will resume now, and the upcoming work and standardizing meta-programming, domain-specific embedded languages, AST manipulation, polymorphic lambdas, constrained templates, concepts, axioms and modules will be able to take form.
Anybody got a link to working draft n3290 or n3291? It was removed from the website after they said it was finished.
The C++ standard continues to go down the crazy road.
C++ is a bunch of hacks on top of C.
To keep those hacks working when adding new features to the language, they have to invent even more hacks.
I'll just take the C language as it is.
It's true that c99 and C1x also have some crazy in it, but there's also genuinely good stuff, some of that ported from some of the less crazy C++ ideas.
But for most purposes, C89 is fine.
Keeps reading like "cox"
Has Intel, PGI, Microsoft or IBM committed to producing a commercial quality C++0x compiler?
get a C++0x compiler that supports PIC12F508 microcontrollers?
I thought we had all the programming languages we need. After Java, we shouldn't have needed anything more. But if we were to have a step higher than C++, why this bizarre name? Why not D, or P (after BCPL)? And what does this language do that no other does well? (No, I don't know what lambda functions are - will look it up in Wiki)
There's a clue in this phrase. If a compiler can do it (infallibly), why should you have to?
Um, no. You have to be a robot to be a C++ programmer. Writing C++ is absurdly cumbersome and error-prone (what's the standard up to now, 1500 pages?) for some theoretical "efficiency" gain.
The smart way would be to choose a language which helps you get the job done with the minimum amount of fuss. If that entails extreme efficiency, then maybe you'll want to use C++ (or more likely C), but there are very few places these days where has any place.
HAND.
C++0xB is a cleverer name since it can be interpreted in two ways:
1) Since C++0x wasn't completed in 200x as expected, it's time for plan B, namely C++0xB.
2) 0xB represents 11, since 0x is the prefix for hexadecimal in C++. And so C++0xB still literally means the version finalised in 2011.
Ditto, and more importantly, if I add a private data member why should I have to re-compile anything other than the class?
Private members are not even a part of the public interface!
When you add a data member (private or otherwise) it changes the memory foot print of an object. If the compiler forced everything to have an implied pImpl (allocating everything on the heap) then it could probably get away with out a recompile but at the cost of performance. Since you can allocate objects on the stack (or possibly even simple ones in registers), the memory foot print of the object needs to be known by the user of the class.
In Soviet Russia Rccp compiles you. Obviously my first attempt was a typo. Also slashdot borked my R operators which were supposed to be [<-, [[<- etc.
Now I see Slashdot also borked some words nearby while entirely failing to notify me of its textual appetites. Lazarus to the rescue, which by some miracle of resurrection has translated < to < for me.
==Restoration of slashdot borkage==
R operators [], []<-, [[]], [[]]<- do the same kind of type polymorphism at runtime that generic programming in C++ does at compile time, only with an even poorer sense of what the interface is required to document. Because of stupid semantics to automatically drop rank to eliminate dimensions of length 1, you can't even get your rank analysis correct half the time. APL had this nailed in 1965. (The stupid drop semantics can be disabled if you subscribe to the long list of "things to remember" so often used to flail C++.) To get rank analysis right, you have to distinguish scalar values from vectors of length 1, which R does not do on your behalf. In the context of a list, operator [[]] behaves like a scalar subscript, shedding a subscript dimension, while [] behaves like a vector subscript, slicing the object into a subset, by not changing rank or type. In other words, even in cases where STL would tell you that your algorithm is generic, in R you have to dispatch on type to get your subscript syntax right.
Both these languages suck a dozen ways from Sunday, but in the union of the two I'm happy as a pig in mud. Deep down I'm fairly certain that if any of 90% of the sentiment about C++ expressed on this thread had taken root in the C++ standards committee, I wouldn't now be enjoying the goodness and broad shoulders of Rcpp.
Straw men, hurling insults, moving the goal posts, etc. etc.
You still didn't answer my point: Why should I (as a programmer) be bothered by things that the computer can do for me? (And if your accusation that we are all 'idiots' is to be taken seriously, the computer would do it better.)
C++ has advantages. Not just ones that matter in this day and age where programmer time is more expensive than computer time. The disadvantages far outweigh its advantages.
HAND.