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.
Wrong thread dude, think you were looking for:
http://developers.slashdot.org/story/11/07/28/1758221/Oracle-Announces-Java-SE-7
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.
...the 11th plague of Egypt has arrived a little bit late.
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.
Objects
I made an app! Shoutium
Perl 6 should arrive in 2019. p.s., As for lambada functions, I hear the best ones are in Buenos Aires.
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.
Correction:
2) Operator overloading: because
Matrix A, B, C, D;
A = A+B*C + A*D;
is so much more readable than
Matrix A, B, C, D;
A.equals(A.plus(B.mult(C)).plus(A.mult(D)));
.... oh wait, it is! This is why Java sucks and C++ rocks for scientific programming.
First DNF, then a HURD kernel, now C++0x... Remind me to send some parkas to hell.
C Plus PLox
It pays to be obvious, especially if you have a reputation for being subtle.
But the winner is:
(+ A (* B C) (* A D))
Filter error: Don't use so many caps. It's like YELLING.
Encapsulation
Polymorphism
Productivity
To name a few....
Visit the Arcade Restoration Workshop @ http://www.arcaderestoration.com
Wanted: A 'cocks' programmer. With seventy years experience.
Religion is what happens when nature strikes and groupthink goes wrong.
The x is a placeholder. C99 was C9x before it was standardised. The two digits specify the year (See: C89, Fortran77, and so on) in which the standard is finalised. This is the version of the standard that will be finalised some time between '00 and '09. In common with all other C++ projects, this one was completed late.
I am TheRaven on Soylent News
It took about 45 minutes to write and test (and I'm not a Ruby expert by any means) and it's less than 100 lines, compared with the 1000+ line C program. I call it a win for Ruby
Challenge accepted! I bet I could rewrite that program in less than ten lines of Perl code. Any takers?
Seriously now, I've tried nearly every language I can put my hands on. I still use C when the going gets tough. One of the reasons is that C is not likely to change.
I've done a lot of small systems in Python lately and, yes, for a small system I can get it going faster than in C. HOWEVER, now comes Python 3. They tell me now that I should have used "from future import division". Apparently I'm too stupid to read the proper documentation, it was clearly stated in PEP 947, or something like that, that the behavior of the division operator would change. It seems that I should read carefully every single one of those thousands of PEPs to make sure they won't pull the rug from under my feet.
If I ever have to go through every division operation in a program to check which ones can stay as '/' and which ones have to be changed to '//' I will take the opportunity to rewrite that program in C, as, I can see it clearly now, I should have done from the start.
The whole point of classes is that you have create a relatively static interface, and the internals can change around as much as you want. If you change the internals, then all you have to do is recompile that single cpp file and re-link. If you change the interface, then you very likely will need to change many other files to use the new behavior. If you are changing private methods and private variables frequently, perhaps you should instead store them in a private class defined only within the cpp file, so you aren't constantly changing that header.
Someone who actually gets it. Garbage collection is a crappy hack that caters to shitty, incompetent programmers. The kiddies should look up RAII. They might learn something.
> The problem seems to be Java-Programmers who
> don't understand the concept of RAII.
Don't worry, most of them probably don't understand garbage collection, either. They just think it's a magical black box that does magic things... and then look bemused when they have a core leak.
Do daemons dream of electric sleep()?
OK, so you consider concurrency useless? And lambda functions? And type inference? And strongly typed enums? And static assertions? And Unicode support? And variadic templates? And move semantics?
The only pity is that concepts didn't make it in.
The Tao of math: The numbers you can count are not the real numbers.
C++ is a powerful and pragmatic, but ugly and dangerous language. No doubt about it. I'm a game developer, so I'm either working on C++ in engine code (and a subset of C++ at that), or in higher-level languages such as C# or Python for tools.
And of course, C++ is definitely a language that requires a significant amount of programmer discipline - more so than other languages, at least from what I've seen. At a personal and a company level, you need to develop some guidelines that keep you from walking into tar pits. For instance, there's never a good excuse to use multiple inheritance, except if you're using it for interfaces (pure virtual classes). And of course, avoid the diamond of death at all costs. For a C++ programmer with any experience at all, that's just common sense (and any good tutorial will warn newbies well away from that trap as well).
Operator overloads? Don't use them stupidly, to be blunt about it. If I saw anyone using them inappropriately I'd say something during a code review, just like with any other bad coding-related decision.
Virtual destructors? A dangerous corner of the language and a potential source of bugs to be sure. But the option to NOT use a virtual destructor (only pay for what you use) is the reason we use C++ for our low-level engine code.
Nothing else is as fast and as portable, while still maintaining a reasonable level of abstraction for design and maintenance purposes. And frankly, one of the most important things about C++ is the ability to drop down to more functional-style programming when required to for optimization purposes.
I actually began working on a new codebase for a small game I'm writing at home, and I decided to embrace a lot of new C++0x features at a very core level (something you don't see in many game engines). It's pretty interesting when you make heavy use of smart pointers / ref counting to manage your resources. With some programming discipline, it feels quite a bit like writing C#, which to me has always been quite enjoyable as a language.
In the end, C++0x is a pretty big deal to those who use it, because even though boost is extremely portable, it's still not the standard. There's always a bit of a mental jump you have to make to adopt a third-party library as part of your core designs. Personally, I've been pretty impressed by what I've seen so far, and look forward to exploring more of the new features as they are adopted by the major compiler vendors.
Irony: Agile development has too much intertia to be abandoned now.
Not really. The main advantage of objects is the loose coupling.
No, the main advantage of objects is namespace hygiene.
Which is why many of them still write code that leaks memory even with a garbage collector. One of the worst offenders are the .NET programmers who write software that leaks GDI handles like crazy and cause all sorts of crashes and bizarre behavior because they didn't bother to learn anything about managing memory and realizing that *gasp* even in a GC language you still need to make sure to be careful that all your resources are being properly released. This is further compounded because there have been a number of bugs in .NET that have caused even well-written code to leak GDI handles.
I guess I'll put it this way. I've never really seen a compelling reason where it should be necessary to do that where a saner design wouldn't suffice. I haven't had to break this rule during my career (at least, not that I recall - certainly not recently). Anytime I've gone down that path design-wise, a bit of thought usually leads me to a more elegant design anyhow.
My rules may not be the same as other rules - hence, why I would never suggest they be codified into the language rules. To me, that's part of what makes C++ both awesome and dangerous at the same time. Part of the trick of using C++ is, IMO, extracting the subset of rules and idioms you're comfortable with and work well for you, and then using them consistently. No one should be using some language feature just because it's there, or because you can do it.
Anytime I see someone trying to do 'clever' things with the language, I tend to cringe, because even if they save a few lines of code here and there, it often comes at the cost of maintainability down the road. It's taken me a long time to realize this, but boring code is beautiful code.
Irony: Agile development has too much intertia to be abandoned now.
I think you mean
in that first example.
And you're being ridiculous. Anyone who types that is an idiot and deserves everything they get. The actual nice thing about "auto" is that you can type
instead of
without having to faff about with typedefs all over the place.
There are some mature libraries like GObject (and Vala, Genie) that do objects for C.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.