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.

19 of 398 comments (clear)

  1. Re:Congratulations! by Anonymous Coward · · Score: 5, Funny
  2. Sadly, tragedy struck by AdmiralXyz · · Score: 3, Insightful

    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.
    1. Re:Sadly, tragedy struck by Jeremi · · Score: 4, Insightful

      Smaller and simpler seem to be a better way to go.

      Nobody is stopping anyone from using plain old C, if that's what they want.

      Of course, many people just end up re-inventing portions of C++ when they do that.

      --


      I don't care if it's 90,000 hectares. That lake was not my doing.
  3. Re:Clean cool crisp refreshing by nemasu · · Score: 3, Funny

    Objects

    --
    I made an app! Shoutium
  4. Nice, but maybe irrelevant. by Animats · · Score: 4, Interesting

    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.

    1. Re:Nice, but maybe irrelevant. by rmstar · · Score: 3, Informative

      The loop macro is, in essence, part of the compiler or the standard library. It is code that processes code during compilation. I'm not surprised that it's nontrivial.

      The problem isn't that it's notrivial. The problem is that when something goes wrong, the end user has to debug it by interpreting the mysterious error messages that are emitted by whatever part of its implementation finally ended up failing. That wouldn't be the case if it were part of the compiler. The compiler could detect errors in how it was USED and issue succinct error messages about that, rather than exposing how it is IMPLEMENTED.

      Lisp programmer here.

      The loop macro actually has access to all the innards of the compiler and gives reasonably useful error messages, at least when compared with standard issue C++ error messages. The loop macro is in fact a lisp program with full access to everything. It can and does produce error messages through the same mechanism than the compiler. C++ templates is a horrendously perverted shadow of what lisp macros are.

      Try Common Lisp some day. It so superior to C++ - it is amazing.

      (...and there goes my karma)

    2. Re:Nice, but maybe irrelevant. by TheRaven64 · · Score: 4, Informative

      While they were sitting around arguing over concepts, they could have been including support for multithreading

      Actually, they did add some support for threading. C++11 has support for a thread-local storage qualifier and a rich set of atomic operations. These are both also in C1x. There is also now a std::thread class, and various synchronisation primitives, and even support for futures / promises.

      Much as I dislike C++, the latest version does have a subset that is much nicer than any subset of previous versions.

      --
      I am TheRaven on Soylent News
  5. Re:Clean cool crisp refreshing by Brannoncyll · · Score: 3, Insightful

    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.

  6. Re:nice, but still missing... by elrous0 · · Score: 3, Insightful

    You lazy, spoiled punks with your Java and C# garbage collection. Back in my day, we collected our OWN garbage. It was a miserable task, but we were ignorant and didn't know any better. AND WE LIKED IT!

    --
    SJW: Someone who has run out of real oppression, and has to fake it.
  7. Hell continues to get colder by Anonymous Coward · · Score: 5, Funny

    First DNF, then a HURD kernel, now C++0x... Remind me to send some parkas to hell.

  8. Re:C++0x by Canazza · · Score: 3, Informative

    C Plus PLox

    --
    It pays to be obvious, especially if you have a reputation for being subtle.
  9. Re:Clean cool crisp refreshing by wsxyz · · Score: 3, Interesting

    But the winner is:

    (+ A (* B C) (* A D))

    Filter error: Don't use so many caps. It's like YELLING.

  10. Re:Clean cool crisp refreshing by ArcadeNut · · Score: 3, Insightful

    Encapsulation
    Polymorphism
    Productivity

    To name a few....

    --
    Visit the Arcade Restoration Workshop @ http://www.arcaderestoration.com
  11. Re:C++0x by bytesex · · Score: 3, Funny

    Wanted: A 'cocks' programmer. With seventy years experience.

    --
    Religion is what happens when nature strikes and groupthink goes wrong.
  12. Re:nice, but still missing... by NumLuck · · Score: 4, Informative

    - precise garbage collection (not that I'm missing it)

    What is the matter with everyone wanting a garbage collector? Personally, I find smart pointers to be far superior to garbage collection and the new standard now incorporates them in the STL (strongly influenced by BOOST)! With them, the sole idea of garbage collection in C++ is somewhat useless and obsolete.

  13. Re:Speaking of obnoxious by TheRaven64 · · Score: 4, Informative

    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
  14. Re:Clean cool crisp refreshing by mangu · · Score: 3, Insightful

    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.

  15. Re:nice, but still missing... by lgw · · Score: 3, Interesting

    Early on, the C++0x spec had "opt-in" garbage collection, which was perfect! You'd declare a pointer as a garbage collected pointer if you wanted that, but otehrwise no GC. That was useful for cyclic data structures, and otherwise you could ignore it.

    Sadly, missing from the final spec.

    --
    Socialism: a lie told by totalitarians and believed by fools.
  16. Re:nice, but still missing... by Jeremi · · Score: 3, Interesting

    After a month of coding Java and never having to worry every time I typed "new" I never looked back.

    Modern C++ programmers don't need worry about typing "new" either; they use smart pointers to handle the "garbage collection" for them. Works great, and avoids the unpredictability, overhead, and performance problems of a garbage collection thread.

    (yes, I know it's possible for reference-counting to leak if you introduce a cycle into the graph. That said, in the last ten years of C++ program, that problem has bit me exactly zero times)

    --


    I don't care if it's 90,000 hectares. That lake was not my doing.