8 ms·
What will C++17 be?
- Chinmayh 11y agoand when would c++ 17 come?
- mike-cardwell 11y agoc++11 came in 2011. c++14 came in 2014. Seeing a pattern yet?
- zerr 11y agoWhen we'll have a compiler support - this is what really matters, especially for those who use MSVC... It is 2015 and we still don't have a full C++11 support.
- mike-cardwell 11y agoFWIW, Clang and GCC support all C++11 features.
- hendzen 11y agoThough GCC only gained full C++11 support as of 5.1, which was released this week.
- Someone 11y agohttp://cpprocks.com/c1114-compiler-and-library-shootout/ http://cpprocks.com/c1114-compiler-and-library-shootout/ disagrees: "First, let’s look at the C++11 language features. Clang 3.3 and above, and GCC 4.8 and later have complete support, so there was no point including them in the table." Also note that, on the C++14 front, clang supported all language features and most library features. And that is a year ago.
- zerr 11y agoYes, but I was talking about MSVC - MicroSoft Visual C++ compiler.
- slowmovintarget 11y agoThat's kind of like saying "You haven't read Shakespeare until you read him in the original Klingon." Waiting for Microsoft to make a compiler seems like it ought to be orthogonal to moving the language forward, especially when non-Microsoft tool chains are already doing better with that particular language. Microsoft has enough on their plate bringing C# and .Net to Linux and Unix, and I'd much rather they get that right than compete with GCC and CLANG. (That and Docker for HyperV and Windows Server.)
- Dylan16807 11y ago>That's kind of like saying "You haven't read Shakespeare until you read him in the original Klingon." Not really. It's one of the top handful of compilers and none of them are "original" wrt the language standard.
- GFK_of_xmaspast 11y agoI'm obliged to make my c++ code work on a variety of platforms, and on windows this means visual studio.
- Someone 11y agoBut Visual studio doesn't imply Microsoft's C++. There's clang-cl (http://clang.llvm.org/docs/UsersManual.html#clang-cl http://clang.llvm.org/docs/UsersManual.html#clang-cl), which aims to be a drop-in replacement for Microsoft's compiler (haven't used it, so I don't know its quality) Also, Visual Studio 2015 will ship with clang (http://blogs.msdn.com/b/vcblog/archive/2014/11/12/visual-studio-2015-preview-now-available.aspx http://blogs.msdn.com/b/vcblog/archive/2014/11/12/visual-stu...). Yes, that's for Android (and, in the future, iOS) only, but it would not surprise me if that it is a sign of things to come: either Microsoft starts following developments faster, or people will move to clang for development. And I doubt the current Microsoft would be bothered if their customers moved to use clang, as long as they kept using Microsoft technologies (even if that's limited to running on Azure)
- gtani 11y agohttp://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17-features-in-vs-2015-preview.aspx http://blogs.msdn.com/b/vcblog/archive/2014/11/17/c-11-14-17... this is the latest i could find, maybe time for an update if so.
- StephanTLavavej 11y agoI'll be publishing an updated feature table soon.
- lambda 11y agoThe pattern is generally that Clang and GCC will have partial support when the standard is release, and full support a couple of years later. Intel will lag behind a year or two after that. Microsoft will be behind another year or two. So, let's say that C++17 does come out in 2017. It will probably be the case that some of the features will be ready to use in GCC and Clang right away, and around 2019 or so they should have full or nearly full support. 2021 for Intel. 2023 for Microsoft. So that gives you a range of answers. Depending on which features and which compiler, you could start using some of them immediately (or even before 2017, many of the features are implemented experimentally in advance), but if you want full support across the range of commonly used compilers, you're probably going to be waiting until the early to mid 2020s.
- plq 11y agoIt's actually C++0B! :)
- detrino 11y agoLet's not that forget c++11's codename was c++0x ;)
- a13xb 11y agoC++11 was originally known as C++0x, so C++17 may yet become C++19.
- cremno 11y agoSomewhere in 2017.
- fishnchips 11y agoHow about making the language more accessible to newcomers by providing a sane default way of doing package management and builds. Go is a great example of both things done reasonably well out of the box.
- plq 11y agoFrom where I'm standing, C++ package management is already quite nicely solved by what we call package managers in the linux world. You know, portage, aptitude, etc.
- 1971genocide 11y agoLinux is used by 1% of all computer users on the planet. Trying to program C++ in windows is an horrible experience that I wont wish on my worst enemy. Linux is nice, but it doesn't have after effects, support for the latest ultrabooks, photoshop ( sorry GIMP is a joke ). Linux also contantly breaks whenever I tried using it, sound, video ? Also gaming. Anyway the browser environment is cool because it forced everyone to stick to a single standard. ( Also corporate uses windows, sadly. Working with tools created by major corporations in my industry is on windows )
- w0rm 11y agoYou can use something like vagrant for you dev environment.
- 1971genocide 11y agoI tried using VM Ware, it comes with its own set of problems. It constantly gets stuck. I will give vagrant a try though.
- coldtea 11y agoPerhaps you're doing it wrong? Your cross-platform OS skills doesn't sound very strong. Maybe should practice some more in the different ways various OS work.
- jmartinpetersen 11y agoThe last slide is worth reading (and avoid doing) and most of it applies to much more than committees for programming languages.
- humanrebar 11y agoI like that feature list a lot. It's going to be very hard to get those features ready, implemented, and stable by the end of 2017, though. Even assuming no issues with politics or the rest of the standardization process. Concepts alone is looking like a very complex feature. And I was and under the impression that modules were even less ready. But both are very much needed. I do know that the committee is planning on putting more experimental library features in the experimental namespace, which should provide a nice middle ground between "not ready for standardization" and "standardized and set in stone". I believe all of the library work for concepts will be released such a namespace in C++17.
- stingraycharles 11y agoCorrect me if I'm wrong, but isn't the whole infrastructure for concepts already there using TMP? The c++ std library even uses some of them already (for example, when using a set it requires an type with operator<, in other words, similar to Haskell's Ord type). To me it feels as if c++17 is just making the compiler more aware of them, and as a result likely produce better error messages (and the code to write them to be more pleasant).
- thechao 11y agoConcepts are significantly simpler to implement & check. I did a non-trivial amount of coding both with TMP-concepts, and with ConceptGCC. ConceptGCC produced better error messages earlier, was easier to symbolically debug, and produced better text, all with less & easier to read & understand code.
- V-2 11y ago"Bad Committee habits to avoid" are perfectly pointed out.
- joliss 11y agoSome of these proposals are really intriguing. More details: Concepts: http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29 http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29 Modules: http://clang.llvm.org/docs/Modules.html http://clang.llvm.org/docs/Modules.html Coroutines: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3708.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n370... operator. (for proxies): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4173.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n417... Uniform call syntax: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4174.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n417...
- apardoe-MSFT 11y agoI'd suggest looking at the papers that were submitted for discussion at the upcoming Lenexa Standardization meeting for references. They're located here: https://isocpp.org/blog/category/standardization https://isocpp.org/blog/category/standardization Here's numbers for the ones you listed: Concepts: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4361.pdf http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n436... Modules: 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... Coroutines: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4397.pdf http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n439... & http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4398.pdf http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n439.... Also http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4134.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n413... operator dot: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4477.pdf http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n447... Uniform call syntax: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4474.pdf http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n447... Here are some others that Stroustrup listed. I think they're probably important proposals. I imagine Stroustrup has at least some priority order in his list. Ranges: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4382.pdf http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n438... Comparisons: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4475.pdf http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n447... & http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4476.pdf http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n447... array_view: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4346.html http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n434...
- api 11y agoSide note: C++ should do something to address binary interoperability and ABI issues. This would be hard, as some of this lies outside the scope of language designers and specifications. The ball largely rests with compiler and platform developers. But there are things that could be done. A common pattern to make C++ libraries usable from languages like Java, Swift, Ruby, Python, etc. without encountering DLL hell issues or language impedance mismatch is to "downgrade" the C++ API into a "--" plain C API. This is done by providing plain C wrappers. Perhaps something could be done to either ease this process or make it unnecessary. Another possibility would be to do something to lean on platforms to address the issues around this. Sometimes languages with as much center of gravity as C++ can do this.
- krick 11y agoRust, maybe?… Ok, ok, relax, I'm just sayin'.
- bkjelden 11y agoI wish 'better compiler messages' could be a language feature. I understand that that's pretty much outside of the scope of the language designers, but I've been playing with rust lately and it's so refreshing to actually get help from the compiler, rather than just looking for the line where it failed and trying to figure out what's wrong on my own.
- SamReidHughes 11y agoThat's part of the reason people want 'concepts'.
- deleted 11y ago[deleted]
- davecheney 11y agoBloated.