Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming Upgrades

New C++ Features Voted In By C++17 Standards Committee (reddit.com) 286

New submitter lefticus writes: The upcoming C++17 standard has reached Committee Draft stage, having been voted on in the standards committee meeting in Oulu, Finland this Saturday. This makes C++17 now feature complete, with many new interesting features such as if initializers and structured bindings having been voted in at this meeting.

An [audio] interview with the C++ committee chair, Herb Sutter, about the status of C++17 has also been posted.

This discussion has been archived. No new comments can be posted.

New C++ Features Voted In By C++17 Standards Committee

Comments Filter:
  • Sweet (Score:5, Insightful)

    by Kohath ( 38547 ) on Sunday June 26, 2016 @02:38PM (#52394309)

    C++ needed more features. Some C++ books aren't even 1000 pages long.

    • Re:Sweet (Score:5, Funny)

      by Longjmp ( 632577 ) on Sunday June 26, 2016 @03:09PM (#52394433)

      C++ needed more features. Some C++ books aren't even 1000 pages long.

      I agree! And more use of the "const" keyword.
      I want to write something like
      const int const foo(const*(const) int const a) const: const {}
      and
      for (const i = 0;const i(const)++; i and finally:
      const return const 1 (const const const)

      • Sane languages have their stuff const by default, and you write mut if you want something changeable.

        • Re: (Score:3, Informative)

          You mean Rust. Rust is a terrible hipster language that won't last 5 years. C++ is going on 40.
        • by gweihir ( 88907 )

          For pretty insane values of "sane". Actually nobody sane does it that way. Breaking convention has no place in solid engineering, and only communities that misidentify "different" as "better" will ever accept such a moronic design.

      • Re:Sweet (Score:4, Funny)

        by pedz ( 4127433 ) on Sunday June 26, 2016 @03:31PM (#52394525)

        C++ needed more features. Some C++ books aren't even 1000 pages long.

        I agree! And more use of the "const" keyword. I want to write something like const int const foo(const*(const) int const a) const: const {} and for (const i = 0;const i(const)++; i and finally: const return const 1 (const const const)

        Replace const with spam and you would have yourself a Monty Python skit.

      • by murdocj ( 543661 )

        The problem is that some C++ still rely on runtime. The ideal C++ program only relies on compile-time templating.

      • trump int trump foo(trump*(trump) int trump a) trump: trump {}
        and
        for (trump i = 0;trump i(trump)++; i and finally:
        trump return trump 1 (trump trump trump)

        FTFY

      • Oh do keep up. This is Slashdot. It's..

        APP int APP foo(APP*(APP) int APP a) APP: APP {}
        and
        for (APP i = 0;APP i(APP)++; i and finally:
        APP return APP 1 (APP APP APP)

        Apps!

    • Re:Sweet (Score:5, Informative)

      by ffkom ( 3519199 ) on Sunday June 26, 2016 @03:34PM (#52394535)

      Just because you are unable to cope with C++'s richness of features does not mean it is a bad thing.

      After all, C++ is the one language that

      • supports a large selection of programming paradigms, and does not declare just a single one to be "the only one you need".
      • does not depend on one company or organization, but is truly a federated effort, with many compilers to choose from.
      • allows you both low-level / hardware-level programming as well as very-high-level programming just using some ready made class library / run time environment (like Qt).
      • has a responsibly acting committee doing a good job overlooking the long-term language evolution. So much unlike many other programming languages, were inexperienced people have introduced the same mistakes over and over again, because nobody was there to question them.
      • has a responsibly acting committee doing a good job overlooking the long-term language evolution. So much unlike many other programming languages, were inexperienced people have introduced the same mistakes over and over again, because nobody was there to question them.

        To be pedantic here, I'd prefer if they were overseeing it.

    • I haven't bought a door stopper (technical book) in over ten years. Mostly because up-to-date information can be found on the internet. If I buy a technical book these days, it's a used copy of an older book that is out of print, unavailable as an ebook, or cheaper than the current edition.

      I recently picked up "Writing Compilers and Interpreters: An Applied Approach" by Ronald Mak (1991 edition), which uses an ancient dialect of C and Pascal as the target language. I know a smattering of C and nothing about

    • Re:Sweet (Score:5, Interesting)

      by Dutch Gun ( 899105 ) on Sunday June 26, 2016 @04:17PM (#52394819)

      You need to divide C++ into two sections: Stuff that's useful for applications, and stuff that's mostly relevant to library writers. A lot of the really hairy stuff is mostly for the library writers. Moreover, a lot of the complexity of C++ (and corresponding slowness of its compilers) comes from compatibility with C and with older versions of itself. If you strip away all that, the core language that most people deal with isn't quite as daunting.

      That being said, nobody is claiming that C++ isn't a difficult language to master. Scott Myers has made a career of pointing people away from it's darkest corners, after all.

      But really, C++ programming took a quantum leap forward with C++11, and C++14 just filed away some of the rough edges. It's hard to explain to non-C++ programmers what a transformation it was. I'm not expecting nearly as much with C++ 17, but I look forward to seeing if any of the proposed features will be useful in my day-to-day work.

    • C++ needed more features.

      C++ needs more features to fix all the problems with the previous round of features.

  • by Anonymous Coward on Sunday June 26, 2016 @02:40PM (#52394321)

    I look back fondly at "c with objects". At least I could decipher the error messages.

  • Sigh (Score:5, Funny)

    by Man On Pink Corner ( 1089867 ) on Sunday June 26, 2016 @02:56PM (#52394387)

    Still no functional gonkulators. Still no encabulation templates. Still no dichroic monads or parameterized gussets. When will the C++ committee ever get around to adding modern language features that users actually want?

  • If initializer (Score:5, Insightful)

    by Carewolf ( 581105 ) on Sunday June 26, 2016 @03:03PM (#52394407) Homepage

    I appreciate the idea behind if initializer. This is actually a somewhat common pattern.

    if (MyClass *p = getMyClassOrNull() {
        p->doYourThing();
    }

    But I fear using initializer statements easily gets too long for a line, and couldn't it already be done with the comma operator?

    • No because you can't put a declaration inside the if statement right now. You could use the comma operator to give an already declared variable a value before the boolean expression, but the variable would have scope outside of the if statement.
      • No because you can't put a declaration inside the if statement right now. You could use the comma operator to give an already declared variable a value before the boolean expression, but the variable would have scope outside of the if statement.

        Yes, you can. The example I showed above works right now, and always have. The problem is that it declarations evaluate to their values, so you can only do it if the value is something that has a useful boolean conversion (like not-null of pointers). The standard would expand the same to more types of expressions. But I can't see why this wouldn't already work:

        if (MyClass *p = getMyClass, p && p->ofTheRightType())
        p->doTheRightThing()

        • Re:If initializer (Score:4, Interesting)

          by Carewolf ( 581105 ) on Sunday June 26, 2016 @03:52PM (#52394669) Homepage

          No because you can't put a declaration inside the if statement right now. You could use the comma operator to give an already declared variable a value before the boolean expression, but the variable would have scope outside of the if statement.

          Yes, you can. The example I showed above works right now, and always have. The problem is that it declarations evaluate to their values, so you can only do it if the value is something that has a useful boolean conversion (like not-null of pointers). The standard would expand the same to more types of expressions. But I can't see why this wouldn't already work:

          if (MyClass *p = getMyClass, p && p->ofTheRightType())

                  p->doTheRightThing()

          Wait, I think I figured it out. The comma operator doesn't work after declarations. In a declaration a comma signifies a declaration of another variable of the same type.

  • Missing features (Score:4, Interesting)

    by rroman ( 2627559 ) on Sunday June 26, 2016 @03:06PM (#52394417)
    Unfortunately the most important features weren't added. Concepts, modules, reflection and concurrency ... those would actually fixed almost all the things, where c++ is lacking now. Hope those will get into the next standard at least.
    • Unfortunately the most important features weren't added. Concepts, modules, reflection and concurrency ... those would actually fixed almost all the things, where c++ is lacking now. Hope those will get into the next standard at least.

      Well someone other than gcc has to implement a working version of concepts. As long as only gcc supports them they will keep getting postponed.

    • Re:Missing features (Score:4, Informative)

      by istartedi ( 132515 ) on Sunday June 26, 2016 @03:12PM (#52394445) Journal

      I'm still waiting for it to have a poorly specified implementation of *all* of common Lisp.

      • I'm still waiting for it to have a poorly specified implementation of *all* of common Lisp.

        A poorly specified one? That is literally JavaScript.

        • A poorly specified one? That is literally JavaScript.

          No, it isn't! JavaScript is a very well-specified implementation of all of Scheme, conveniently wrapped in a syntax which makes it as difficult as possible to actually use that Scheme implementation.

      • At this point, what's missing?
        • I recall somebody with knowledge of both saying that C++ definitely lacks full macros, even though templates come close.

          • It's true macros are a lousy replication of Lisp macros, but they are turing complete, so you should be able to say they are a poorly specified implementation at least.
    • by Anonymous Coward on Sunday June 26, 2016 @03:36PM (#52394555)

      What are you trying to say? That they should rush in features that haven't been thought through? That they should put half-arsed or broken features in place just to say that they have? That they should then support these broken features for decades, since that's how long C++ projects tend to live?

      Look, if you want a language with buzzword features thrown in left and right, with changes to these features happening just about every release, then maybe a programming language like Rust is what you're looking for. C++, on the other hand, is a language meant for professionals to use when developing complex systems that won't just be used next week, but will be used 15 or 20 years from now, assuming they aren't still being used long after that. Those standardizing C++ have a huge responsibility on their shoulders. They can't goof around with C++. If a change is made to the language, it has to be thought out thoroughly and it has to be the right thing to do.

      • by ffkom ( 3519199 )

        If I hadn't commented already, I would mod the parent post up.

        This really is the point, which seems to be far beyond the comprehension of JavaScript greenhorns and the like: I wrote C++ library code > 20 years ago which is still actively maintained as part of complex, commercial server software.

        Sure, some minor adjustments had to be made of the decades, as we want our source code to be compatible with at least the penultimate C++ ISO standard. But other than this, the software still runs fine on differen

        • I wrote C++ library code > 20 years ago which is still actively maintained as part of complex, commercial server software.

          This feature is drastically undervalued.

      • That they should rush in features that haven't been thought through? That they should put half-arsed or broken features in place just to say that they have?

        You mean like export? Or auto_ptr?

  • by fozzy1015 ( 264592 ) on Sunday June 26, 2016 @03:24PM (#52394499)

    There's still no std::string split() method.

    • by m00sh ( 2538182 )

      There's still no std::string split() method.

      It's in boost. http://www.boost.org/doc/libs/... [boost.org]

  • by fahrbot-bot ( 874524 ) on Sunday June 26, 2016 @03:54PM (#52394685)

    I'm not that impressed with the "if statement with initializer" addition and especially not impressed with one of their examples that use it to make things more compact. I don't like declaring the same variable twice and think more traditional coding would actually be cleaner.

    status_code foo() {
    int n = get_value();
    if (status_code c = bar(n); c != status_code::SUCCESS) { return c; }
    if (status_code c = do_more_stuff(); c != status_code::SUCCESS) { return c; }
    return status_code::SUCCESS;
    }

    Seems like a pretty pointless addition.

  • C++ aficionados, your vexing problem has been solved! That is to say, your complex language has added a new "if" structure with more side-effects to enhance the impenetrability and opportunity for obscurantism that we all value so much.

    • by m00sh ( 2538182 )

      C++ aficionados, your vexing problem has been solved! That is to say, your complex language has added a new "if" structure with more side-effects to enhance the impenetrability and opportunity for obscurantism that we all value so much.

      Not a big deal. A simple code analysis tool should easily identify the problem.

  • Our IT and Build team still don't permit us to use C11 features because some ancient archiac module originally used mainwin to port from windows to linux.
  • And ironically, one of its most severe shortcomings is that it is far too complicated. Seems they are hard at work on making things worse.

    Personally, I have moved back to C for anything that needs efficiency and use Python for anything that does not. The two also combine well.

  • by apilosov ( 1810 ) on Sunday June 26, 2016 @07:37PM (#52395645) Homepage

    All you need to know about C++17 is here: https://www.youtube.com/watch?... [youtube.com]

  • Did they finally fix calling a virtual function of a containing class during the constructor or destructor (or other initialization) of a member object of a derived class that provides a new overriding for the virtual function?

    It should be strongly defined to get the base class version of the virtual function until the first line of the derived class constructor is executing until the last line of the derived class destructor has executed.

    I have been asking for this since the first round of standardization.

    • It should be strongly defined to get the base class version of the virtual function until the first line of the derived class constructor is executing

      then the derived class version

      until the last line of the derived class destructor has executed

      (except when further overridden by additional layers of derived classes, of course).

  • Goshdiggettydarn! I haven't got round to learning C++11 yet.

Never test for an error condition you don't know how to handle. -- Steinbach

Working...