Stories
Slash Boxes
Comments

SoylentNews is people

posted by LaminatorX on Tuesday August 19 2014, @04:30AM   Printer-friendly
from the (C++)++ dept.

Herb Sutter reports that the ballot closed on Friday.

From the announcement:

We will perform some final editorial tweaks, on the order of fixing a few spelling typos and accidentally dropped words, and then transmit the document to ISO for publication this year as the brand new International Standard ISO/IEC 14882:2014(E) Programming Language C++, a.k.a. C++14."

https://isocpp.org/blog/2014/08/we-have-cpp14

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Informative) by N3Roaster on Tuesday August 19 2014, @05:08AM

    by N3Roaster (3860) <roaster@wilsonscoffee.com> on Tuesday August 19 2014, @05:08AM (#82923) Homepage Journal
  • (Score: 3, Interesting) by nukkel on Tuesday August 19 2014, @05:28AM

    by nukkel (168) on Tuesday August 19 2014, @05:28AM (#82927)

    C++, now with even more paradigms piled half-baked on top!

    Is it procedural? Yes, but you really shouldn't.
    Is it object-oriented? Only at compile time.
    Is it a functional language? The preprocessor is.

    What was missing? Oh, I know! Let's add an awkward closure syntax! Let's try to simulate weakly typed languages using the auto keyword!

    • (Score: 2, Informative) by Refugee from beyond on Tuesday August 19 2014, @07:00AM

      by Refugee from beyond (2699) on Tuesday August 19 2014, @07:00AM (#82943)

      What auto keyword has to do with weak typing? Auto variable doesn't change type in runtime.

      --
      Instantly better soylentnews: replace background on article and comment titles with #973131.
      • (Score: 0) by Anonymous Coward on Tuesday August 19 2014, @09:39AM

        by Anonymous Coward on Tuesday August 19 2014, @09:39AM (#82980)

        Well, some people obviously think just because they don't write down the type themselves, it isn't there.

        BTW, I wonder if with the return type inference for lambdas with several returns, they allow for the same type inference as they allow for ?: since I think it would be frustrating if you'd do

        [](long x)
        {
          if (x>0)
            return x;
          else
            return 0;
        }

        and the compiler complains, while

        [](long x)
        {
          return (x>0)? x : 0;
        }

        compiles fine. Note that while in this specific case, the ?: is just as readable, in more complex situations it may not be.

    • (Score: 1) by tkd-physics on Wednesday August 20 2014, @03:10PM

      by tkd-physics (1306) on Wednesday August 20 2014, @03:10PM (#83555)

      Sarcasm fail.

      Procedural? Yes, and you really should. Only the undereducated think OO is the only right way. Actually, only the undereducated think *any specific technique* is the only right way.

      Object oriented only at compile time? Incorrect, OO is just about the only thing C++ can't do at compile time.

      Functional? The preprocessor should be used as little as possible, but most compile time programming is functional. (Well, *all* of it with template metaprogramming, I'm not yet sure how the new constexpr stuff will work out.)

      Awkward closure syntax? Weird, not awkward, a year from now nobody will notice. (The variable declaration syntax is awkward, but that was inherited from C, and everybody is used to that by now.) As I understand it, C++ lambda syntax is just about the only way they could make it work without breaking backwards compatibility. Or do you have a better way they could have done it?

  • (Score: 1) by c0lo on Tuesday August 19 2014, @05:28AM

    by c0lo (156) on Tuesday August 19 2014, @05:28AM (#82928) Journal
    After "Duke Nukem forever", here goes another metaphor for "forever and a day".
    Somehow, I don't feel sad.
    --
    https://www.youtube.com/watch?v=aoFiw2jMy-0
    • (Score: 2) by maxwell demon on Tuesday August 19 2014, @06:22AM

      by maxwell demon (1608) Subscriber Badge on Tuesday August 19 2014, @06:22AM (#82940) Journal

      "C++0x forever" already ended when C++11 was finished (the version which was codenamed C++0x before).

      --
      The Tao of math: The numbers you can count are not the real numbers.
  • (Score: 3, Funny) by Tork on Tuesday August 19 2014, @05:28AM

    by Tork (3914) on Tuesday August 19 2014, @05:28AM (#82929)
    Umm please don't fix the typos! My old code won't work!!!

    Okay I kid, I know they're talking about documentation. But I did run across a class in the scripting API for an application my company uses where there are two members, one is spelled right, the other is spelled the way you'd spell it if a little squiggly line didn't appear under it.

    MyClass.Aperature
    MyClass.Aperture

    I really don't know whether to applaud them for maintaining compatibility or for cementing both variables in. Heh.
    --
    Slashdolt Logic: "24 year old jokes about sharks and lasers are +5, Funny." 💩
  • (Score: 1) by rfree on Tuesday August 19 2014, @07:37AM

    by rfree (4618) on Tuesday August 19 2014, @07:37AM (#82954)

    This is cool news :)

    C++14 changes are rather fixes, not a revolution like C++11, but it's nice they are here to be implemented.

    The glorious C++ master race will be even better then all the C, Java, PHP peasants, wooo.

  • (Score: 3, Funny) by aristarchus on Tuesday August 19 2014, @09:14AM

    by aristarchus (2645) on Tuesday August 19 2014, @09:14AM (#82971) Journal

    Isn't it the C-14 isotope that allows for carbon dating of really old stuff? Oh, C++? Wait, isn't that like C, and isn't that just glorified Pascal? Wait again, it is really old!

  • (Score: 3, Insightful) by kaszz on Tuesday August 19 2014, @09:35AM

    by kaszz (4211) on Tuesday August 19 2014, @09:35AM (#82977) Journal

    So did Apple objective and Microsoft sharp get their peeve and others their pile-upon-the-old stuff included? Must be a dream to use.. (while your MBA boss wonders why things break)

    Seems they did C right and then it got serious warts but warts was a feature.. a wart++ feat! ;)

    Languages need to be stringent and efficient. Refactoring the design is sometimes a necessary evil.

  • (Score: 4, Insightful) by PizzaRollPlinkett on Tuesday August 19 2014, @11:38AM

    by PizzaRollPlinkett (4512) on Tuesday August 19 2014, @11:38AM (#83007)

    I'm so old I can remember when C++ was a nice little OO language with a lot of promise, poised to replace C as a systems programming and general purpose language. Sure, it had its quirks, but all languages do. The word "virtual" was overloaded too much, and the allergic reaction to using new keywords caused bizarro syntax like using "= 0" for abstract methods. Such syntactic oddities made the language much harder to read than necessary, since you had to mentally de-obfuscate C++ code as you read it. But multiple inheritance was not a requirement, and you could ignore it. So the potential was there.

    Then the bottom fell out. C++ got bizarre and weird during the standards process, with such misfeatures as the template syntax which was difficult to read. The language became inscrutable, and hard to compile. The language became inbred, with C++ experts working on adding features to the language that only C++ gurus could understand, locking out the very programmers who were ready to make C++ the next Language Of Choice but who were turned away by C++'s inscrutable syntax and mind-bending complexity.

    The C++ world retreated into a hard shell, being ignored by programmers who moved on to more sane languages. Finally, the C++ 11 standard came along, reminding programmers both that C++ had once been relevant, and also why they ignored it in the first place. The bizarro lambda syntax was so strange that only inbred C++ programmers could have come up with it. The hyper-allergy to adding new keywords forced C++ gurus to basically create gibberish out of square brackets.

    Everything you need to know about C++'s demise is in the "move" constructor. I'm still not completely sure what it does, but someone did a test and the g++ compiler already optimized object moves. If compilers are already so smart that they can do this, why does the language need to add a complex and inscrutable feature that's hard to even explain?

    I can remember being excited about C++ at one time, around 1993 or so. Since then I've only done one project in it.

    --
    (E-mail me if you want a pizza roll!)
    • (Score: 0) by Anonymous Coward on Tuesday August 19 2014, @03:56PM

      by Anonymous Coward on Tuesday August 19 2014, @03:56PM (#83134)

      There are situations where the copy constructor can not be elided. Also note that you'll have to make your test with a C++89/C++03 compiler, since a C++11 compiler will automatically call the move constructor if available and applicable, without you needing to explicitly request it. Also note that a move constructor is only useful for classes which hold resources (like containers which manage collections of objects on the heap).

      The move constructor basically makes a shallow copy, followed by changing the original so it can be destructed/reassigned without deallocating the resource (which now belongs to the newly constructed object).

      That the move constructor was needed can also be seen from the auto_ptr fiasco. Without move construction, the standard committee, who are, after all, the ones who know C++ best, did three iterations of auto_ptr, and each of the three turned out to be defective, and finally they found out that you simply could not write a non-defective auto_ptr in the old language. In C++11, a beginner could design a functional auto_ptr replacement (not that he would need to, since the standard provides the new unique_ptr which does that).

      And the nice thing about the move constructor is: In 99% of all cases you don't even need to think about it, provided you've used best practices already from C++98. The compiler will do just the right thing for you. And if you completely ignore it, the worst thing that happens is that your code will have the same performance as it would have in C++98.

      Unless, of course, you're trying to implement something with auto_ptr like semantics. Then the worst thing that can (and will) happen if you ignore move construction is that you'll fail to provide a correct solution, because without move construction and move assignment, there simply isn't one. But then, your cdoe would have been just as broken when compiled by C++98. You just lost the justification that there's no way to do it correctly, because now there is.

      You have a very good point about syntax. However, while C++ certainly produced its own problems (you've already mentioned the ugly template syntax), part of the problems is already in the C language, which simply wasn't designed for the type of extensions C++ did. Indeed, C stopped being context free when introducing typedefs; in the context of C that was not a big problem because it was always clear whether something is a type or not, but in C++ templates that is no longer the case, which leads to the typename complexities). Indeed, the biggest mistake of C++ in my opinion is C compatibility. Had they made a clean break, like Java, C# or D, this would have enabled a much improved syntax. The only worse thing is that in C++11, they disallow narrowing conversions, but only in new initializer syntax. While the goal is laudable (decrease the chance of errors through a misfeature inherited from C), the implementation is despicable (by only disallowing those conversions in some contexts, the complexity of the language is unnecessarily increased; not adding those restrictions would have been preferable to partially applying them; applying them everywhere would have been even better, but would have broken old code relying on them).

  • (Score: 0) by Anonymous Coward on Tuesday August 19 2014, @11:42AM

    by Anonymous Coward on Tuesday August 19 2014, @11:42AM (#83008)

    C++ never sat right with me. As someone who literally grew up writing assembler, I have difficulty seeing how the C++ way of doing things is much better than C. It seems like all of C's pitfalls are hidden behind a Wizard of Oz curtain until you abstract your way into a brick wall and have to face them. I don't like a language where the subroutines you tend to write don't work very well as boxes in a flowchart, either.

    Here's a fun question: what makes C++ any better than some sort of compiled BASIC? What does C++ do that C doesn't do, besides give you the ability to dig yourself into a hole much faster?

    GET OFF MY LAWN!

    • (Score: 3) by HiThere on Tuesday August 19 2014, @01:01PM

      by HiThere (866) on Tuesday August 19 2014, @01:01PM (#83038) Journal

      Well, the ability to have variables contained within object instances is nicer than needing to stick them on the heap yourself. I really miss that whenever I use C. OTOH, C++ comes with some much stuff done as templates that I generally use something else. I understand that doing it as templates means that it can be done at compile time rather than at run time, and for some purposes that's optimal, but sheesh! I just don't think that way. Scheme is easier to wrap my mind around.

      The language I actually prefer is D (Digital Mars D) when I'm not using Python or Ruby. D has all the nice features I like from C and doesn't yet require that you pay much attention to templates. Unfortunately, there are signs that its developing into the same mess. Apparently once you allow templates into a language, the developers get all caught up in it, and think it's so nice that everyone must want to use it.

      --
      Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
      • (Score: 0) by Anonymous Coward on Tuesday August 19 2014, @04:04PM

        by Anonymous Coward on Tuesday August 19 2014, @04:04PM (#83140)

        Actually I don't understand why so many people have an aversion to templates. I mean, the template syntax in C++ is ugly, yes, but that's just a cosmetic problem. And from the little I've seen from D, its template syntax seems not to be bad.

        Especially if you only use templates, rather than writing them, most of the time the only thing you notice is those angle brackets in the type name. For functions, you normally don't even have that; you just write min(a,b) and don't care whether min is a template or not. Except that as template, it automagically works with your own classes as long as they define a less-than operator.

        Yes, you can also do mighty complicated stuff with templates. But nobody forces you to do it. Just like nobody forces you to do mighty complicated stuff with functions.

    • (Score: 2) by PizzaRollPlinkett on Tuesday August 19 2014, @02:17PM

      by PizzaRollPlinkett (4512) on Tuesday August 19 2014, @02:17PM (#83082)

      A big win: You don't have to start from scratch writing linked list and dictionary code for your structs. I used C++ on a project that would have used C otherwise, just to get the standard containers - after a decade and a half of using Java, I wasn't about to start writing data structures from scratch. C++ saves a ton of programmer time with containers, iterators, etc.

      --
      (E-mail me if you want a pizza roll!)
    • (Score: 2) by forsythe on Tuesday August 19 2014, @04:09PM

      by forsythe (831) on Tuesday August 19 2014, @04:09PM (#83144)

      The obligatory ``interview'' should be posted about now. [cat-v.org] As someone who has to read code written by others, C++ (compared to C) offers a myriad of ways to obfuscate errors behind layers and layers of design patterns, while offering nothing really more significant than pre-written linked lists.