7 ms·

Current Proposals for C++17

66 points by meetingcpp 11y ago

vmorgulis 11y ago
With Concepts, we will also have "auto" in function arguments. It avoids "template <typename ...>" for simple functions. I already use it as a "catch all" over specialized functions (gcc -std=c++17).
- repsilat 11y ago
  Why prefer int foo(auto a, auto &&b); to int foo(a, &&b); ? Too big a change? Too much magic? Maybe more difficult to read or parse. The argument "It's not clear that the function is a template" isn't there any more, though, so it seems reasonable to me.
  - kevinnk 11y ago
    You actually hit on the exact reason; your change is significantly harder to parse. C++ allows you to alias typenames and variable names, so you wouldn't know if `int foo(T);` was a declaration of a function that take a type `T` or a function that has an implicitly typed parameter called `T` until much later in the parse. Adding auto makes it clear this is a declaration of a variable. That kind of ambiguity already exists in C++[1], but is widely regarded as one of the things that makes parsing C++ extremely hairy. Interestingly, I remember hearing about this exact problem in the context of Swift's closures; if you want type inference, you need to leave off the parens around the parameters. This is mainly done (IIRC) because it's easier for the parser. [1] http://blog.reverberate.org/2013/08/parsing-c-is-literally-undecidable.html http://blog.reverberate.org/2013/08/parsing-c-is-literally-u...
  - vmorgulis 11y ago
    Do you mean? template <typename T1,typename T2> int foo(T1 a, T2 &&b); "auto" is shorter.
perone 11y ago
This is moving fast, a moratorium for some time would be beneficial for community. Like the one that happened in Python sometime ago.
- GFK_of_xmaspast 11y ago
  The last big change was c++11, and that was already five years ago.
  - snuxoll 11y ago
    Forgetting about C++14?
    - msbarnett 11y ago
      C++14 just cleaned up a couple of minor things from C++11. It was essentially intended to be a point release. C++17 is the first "big" standard change since C++11. It will likely be followed by a small bug fix revision, analogous to C++14, a couple of years later.
      - petra 11y ago
        Wasn't a lot of memory safety and thread safety introduced in c++14?
        msbarnett 11y ago
        C++11 introduced threading and a memory model for C++. C++14 had relaxed requirements on constexpr, initializers in lambda captures, using auto for return type deductions, and a few other small tweaks.
        danbolt 11y ago
        C++11 had unique_ptr and shared_ptr, but C++14 helped with adding make_unique. In my opinion, that makes a big difference because now making a special unique pointer is an atomic operation in your program.
maxxxxx 11y ago
I have been away from C++ for a while. Has there been any progress in making it easier to link different libraries together? In C# it's so nice that you can just reference another library and you are all done. When I used C++ last time this was always a huge ordeal.
- kevinnk 11y ago
  Do you mean link as in "linker"? Or are you asking if it's possible to do "using LibX" like in C#? You can already do "using ClassX", but yeah, the package management story in C++ isn't great. There's a proposal for modules in C++[1], which should help, but as far as I know that's not going to be in C++17. Clang already has a (different) version implemented as well[2]. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4465.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n446... [2] http://clang.llvm.org/docs/Modules.html http://clang.llvm.org/docs/Modules.html
  - maxxxxx 11y ago
    I meant compiling C++ code into a shared library like a DLL on Windows and be able to use the classes in that DLL from other code. The same way you can easily call C code in different libraries.
    - meetingcpp 11y ago
      Well, that has been done for decades. You just need to link your code with the correct libraries. Its probably a bit easier with C as it has a common ABI, and C# as it only has one tool chain, and not multiple toolchains from multiple vendors like C++. Modules will help here further.
      - kevinnk 11y ago
        I believe maxxxxx is asking about the ability to import and use classes from a DLL directly, without needing a class definition. As far as I know, in standard C++ this isn't possible.
deleted 11y ago
[deleted]
Razengan 11y ago
I assume performance is one of the main reasons that C/C++ are still relevant today, and the reason why modern languages like Swift and Go can't be as fast is because of their "runtime" software layer which makes their fancy features possible. My honest if somewhat noobish question is: Why isn't support for features like type safety and so on being incorporated into CPUs themselves, like they did with SIMD instruction sets? I mean, if so many languages require "runtimes" now, why haven't the features that are common across those runtimes, been factored out into hardware already?
- dottrap 11y ago
  That's not a fair characterization of Swift's runtime. Swift is similar to C++ in that it compiles down a lot of stuff so it doesn't need to make runtime decisions. Swift could theoretically be as fast or faster than C/C++, but C/C++ have decades compiler optimizations that are going to be hard to beat. I say Swift has the potential to be faster because of the pointer aliasing problems of C/C++, which Swift can potentially optimize (like why Fortran still can beat C). But your question about runtimes and performance are kind of a red herring. High performance means utilizing the underlying hardware well. A lot of the popular modern languages were designed for convenience over speed and were designed in an era of ever-increasing single processor CPU speeds. Very few languages map to how hardware actually works so they give up speed. Few mainstream languages automatically vectorize _well_ and _reliably_ to automatically exploit SIMD (C/C++ don't really do this...we generally have to write the intrinsics ourselves if we care). Few mainstream languages do a good job exploiting the multiple cores/CPUs available to us (don't say threads...they are pretty poor. This is one interesting feature of Go). Cache locality is now extremely important to high performance and most languages don't let us really control this. (C/C++ give us some say on our memory layouts.)

66 points by meetingcpp 11y ago

With Concepts, we will also have "auto" in function arguments. It avoids "template <typename ...>" for simple functions. I already use it as a "catch all" over specialized functions (gcc -std=c++17).

repsilat 11y ago
Why prefer int foo(auto a, auto &&b); to int foo(a, &&b); ? Too big a change? Too much magic? Maybe more difficult to read or parse. The argument "It's not clear that the function is a template" isn't there any more, though, so it seems reasonable to me.
- kevinnk 11y ago
  You actually hit on the exact reason; your change is significantly harder to parse. C++ allows you to alias typenames and variable names, so you wouldn't know if `int foo(T);` was a declaration of a function that take a type `T` or a function that has an implicitly typed parameter called `T` until much later in the parse. Adding auto makes it clear this is a declaration of a variable. That kind of ambiguity already exists in C++[1], but is widely regarded as one of the things that makes parsing C++ extremely hairy. Interestingly, I remember hearing about this exact problem in the context of Swift's closures; if you want type inference, you need to leave off the parens around the parameters. This is mainly done (IIRC) because it's easier for the parser. [1] http://blog.reverberate.org/2013/08/parsing-c-is-literally-undecidable.html http://blog.reverberate.org/2013/08/parsing-c-is-literally-u...
- vmorgulis 11y ago
  Do you mean? template <typename T1,typename T2> int foo(T1 a, T2 &&b); "auto" is shorter.

perone 11y ago

This is moving fast, a moratorium for some time would be beneficial for community. Like the one that happened in Python sometime ago.

GFK_of_xmaspast 11y ago
The last big change was c++11, and that was already five years ago.
- snuxoll 11y ago
  Forgetting about C++14?
  - msbarnett 11y ago
    C++14 just cleaned up a couple of minor things from C++11. It was essentially intended to be a point release. C++17 is the first "big" standard change since C++11. It will likely be followed by a small bug fix revision, analogous to C++14, a couple of years later.
    - petra 11y ago
      Wasn't a lot of memory safety and thread safety introduced in c++14?
      - msbarnett 11y ago
        C++11 introduced threading and a memory model for C++. C++14 had relaxed requirements on constexpr, initializers in lambda captures, using auto for return type deductions, and a few other small tweaks.
      - danbolt 11y ago
        C++11 had unique_ptr and shared_ptr, but C++14 helped with adding make_unique. In my opinion, that makes a big difference because now making a special unique pointer is an atomic operation in your program.

maxxxxx 11y ago

I have been away from C++ for a while. Has there been any progress in making it easier to link different libraries together? In C# it's so nice that you can just reference another library and you are all done. When I used C++ last time this was always a huge ordeal.

kevinnk 11y ago
Do you mean link as in "linker"? Or are you asking if it's possible to do "using LibX" like in C#? You can already do "using ClassX", but yeah, the package management story in C++ isn't great. There's a proposal for modules in C++[1], which should help, but as far as I know that's not going to be in C++17. Clang already has a (different) version implemented as well[2]. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4465.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n446... [2] http://clang.llvm.org/docs/Modules.html http://clang.llvm.org/docs/Modules.html
- maxxxxx 11y ago
  I meant compiling C++ code into a shared library like a DLL on Windows and be able to use the classes in that DLL from other code. The same way you can easily call C code in different libraries.
  - meetingcpp 11y ago
    Well, that has been done for decades. You just need to link your code with the correct libraries. Its probably a bit easier with C as it has a common ABI, and C# as it only has one tool chain, and not multiple toolchains from multiple vendors like C++. Modules will help here further.
    - kevinnk 11y ago
      I believe maxxxxx is asking about the ability to import and use classes from a DLL directly, without needing a class definition. As far as I know, in standard C++ this isn't possible.

deleted 11y ago

[deleted]

Razengan 11y ago

I assume performance is one of the main reasons that C/C++ are still relevant today, and the reason why modern languages like Swift and Go can't be as fast is because of their "runtime" software layer which makes their fancy features possible. My honest if somewhat noobish question is: Why isn't support for features like type safety and so on being incorporated into CPUs themselves, like they did with SIMD instruction sets? I mean, if so many languages require "runtimes" now, why haven't the features that are common across those runtimes, been factored out into hardware already?

dottrap 11y ago
That's not a fair characterization of Swift's runtime. Swift is similar to C++ in that it compiles down a lot of stuff so it doesn't need to make runtime decisions. Swift could theoretically be as fast or faster than C/C++, but C/C++ have decades compiler optimizations that are going to be hard to beat. I say Swift has the potential to be faster because of the pointer aliasing problems of C/C++, which Swift can potentially optimize (like why Fortran still can beat C). But your question about runtimes and performance are kind of a red herring. High performance means utilizing the underlying hardware well. A lot of the popular modern languages were designed for convenience over speed and were designed in an era of ever-increasing single processor CPU speeds. Very few languages map to how hardware actually works so they give up speed. Few mainstream languages automatically vectorize _well_ and _reliably_ to automatically exploit SIMD (C/C++ don't really do this...we generally have to write the intrinsics ourselves if we care). Few mainstream languages do a good job exploiting the multiple cores/CPUs available to us (don't say threads...they are pretty poor. This is one interesting feature of Go). Cache locality is now extremely important to high performance and most languages don't let us really control this. (C/C++ give us some say on our memory layouts.)