9 ms·
C++17 and its Technical Specifications
- soulbadguy 11y agoWas the coroutine proposal droped from C++17 ? That was one of the most exiting feature
- aninteger 11y agoA Microsoft specific implementation is available in Visual Studio 2015 and possibly earlier.
- meetingcpp 11y agoNo, that is not dropped, but it also is not contained in a TS yet, I'm not sure if it gets added to C++17. There is a wording paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0057r2.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p005... Not sure if Jacksonville will already give green light or if this will be decided later. Would be a good addition though.
- ape4 11y agoRisking downvotes... all this stuff seems a bit boring. For example, since the start C had ways to access the disk, C++ gave us ifstream's and now C++17 has filesystem - yawn.
- azov 11y agoifstream is very, very limited. Shocking as it is, there's still no standard and portable way in C++ to do very basic filesystem operations, like list files in a directory - you have to use platform APIs or third-party portability libraries. Seems like C++17 finally resolves this. We only had to wait 34 years :)
- lettergram 11y agoI've been using Qt for years to do this. I have my fingers crossed I can finally use the standard libraries.
- sbmassey 11y agoWell it is basically an almost-copy of Boost.Filesystem which you can use today, can you not?
- CyberDildonics 11y agoBoost requires compiling libraries ahead of time and linking them in, so to do that on top of Qt would be asking a lot for very little gain. If filesystem was a header only library I don't think it would be as much of an issue.
- pzone 11y agoI assume that in the long run Qt will relinquish this to standard libraries, so QFile will basically be a convenience wrapper around std::file integrated with Qt's concurrency model.
- richard_todd 11y agoThat's because C started as a language rather than a platform. You have always needed to marry it to POSIX or Win32 or whatever to do anything useful. Now with various proposals like 2D graphics, C++11 threads etc. it looks like they are moving in the portable platform direction.
- azov 11y agoYes, I know. We had this "C runs on systems that don't even have disk" excuse for so long it's became a cultural thing. I'm not sure where to draw the distinction between a language and a platform and I don't think I care. Those additions will make C++ way more useful, libraries will become more composable, binaries smaller, and life will be easier for 99.9% of people who use C++. So, I'm glad they finally dropped the lowest common denominator approach - we've been making our own batteries for way too long.
- richard_todd 11y agoI think it's more of a philosophy than an excuse. I'd say it's only in the Java era that people have started expecting their language to have "batteries included." Big ships like C/C++ turn slowly, but it does seem to be turning that direction. Whether that's better than the community defaulting to boost libs, I don't know.
- azov 11y agoYou're right about changing expectations, but it is better. Really. Too many people view boost as a giant cumbersome blob of libraries interconnected in unintuitive ways and refuse to use it, especially if they only need something that they perceive as small and simple. We've been through the same exact arguments years ago, only then it was about things like std::string. Oh, no, it allocates dynamic memory behind the scenes - there are systems that don't even have heap! As a relic from that era some popular libraries still use their own string classes.
- meetingcpp 11y agoWell, boost::filesystem exists for ages...
- vvanders 11y agoBut how many million lines of header files do you need to pull in to use it?
- zanny 11y agoProbably as many millions of lines the C++ standard will use, since its based on boost::filesystem. A lot of these proposals and the changes in C++ this decade have just been standardizing slightly modified versions of Boost libraries.
- sseagull 11y ago>Probably as many millions of lines the C++ standard will use, since its based on boost::filesystem. Not necessarily. A lot of boost contains workarounds for compilers that don't support certain features. Since the standard library will be expected to be used with a known compiler (or at least a new-ish compiler), it doesn't need workarounds for missing C++11 support, etc.
- CountSessine 11y agoThe biggest problem with Boost isn't simply the number of headers - it's maintaining the built libraries against your compiler. "Let's upgrade to MSVC 2015!" "Oh nuts, our code now links against msvcrtp13.dll and our built boost_filesystem.dll still links against msvcrtp12.dll. Time to rebuild all of our libraries!" This is especially bad on Windows where MS's dev tools team just didn't 'get' that developers just don't care about new CRT optimizations if it means rebuilding all of our 3rd party libraries. But even on OSX there's been the whole libstdc++/libc++ pain. Anything that can get folded into the standard library and maintained by the same jokers who rev msvcrt*.dll every couple of years (rub their noses in their own mess) is good.
- tragomaskhalos 11y agostd::optional seems to have been in gestation for ever, and we're crying out for it. Is there some complexity issue here that I'm missing?
- makecheck 11y agoOne reservation I have about “optional” (and for that matter, “shared_ptr” and other objects that directly store their tracking in an object) is that object-oriented storage models do not necessarily make sense for tiny objects. If you have a lot of optional data, or a lot of reference counts, etc. it can make a lot more sense structurally to gather the state of all variables in one place. For instance: if you have 10 optional fields in a structure, create a single set of 10 bit flags to track them all; the result is much smaller than 10 “optional” objects ever could be. The last thing you want is a ton of padding across millions of objects in your program; this starts to affect everything from efficient use of caches to maximum memory capacity. It just seems a bit of a slippery slope; optional<> might start showing up all over the place as the One True Way To Optional things, without regard for the unnecessary padding and/or wrapping of data. The only way to really do this “for free” is to have the compiler keep track of what was ever set, as Swift appears to do, keeping the tracking out of the memory or run-time footprint.
- jzwinck 11y agoPeople often use a vector of vectors as a matrix. It's not as efficient, it usually is a bad idea, yet it doesn't discredit std::vector. I suppose we could create a variadic template std::optional<...> which works like a tuple to solve your padding concerns.
- moomin 11y agoThis will probably be an unpopular position but: I really hope concepts doesn't make it into C++17. Not because I don't want concepts, but because I think definition checking is completely integral to what I want them for.
- Rexxar 11y agoEven if definition checking is very important, why not implement the full specification in two steps if it helps to make it happen ?
- marvy 11y agoBecause once you ship it without definition checking, three years later it's too late to add it. Too many people will have written code that will break. This is one of those unfortunate language features that you only get one chance to get it right. Note: I haven't been following this stuff closely, I could be missing something here, but I trust that someone will correct me if I'm wrong. Or at least down-vote me to oblivion :)
- Rexxar 11y agoThe current specification create a "concept" keyword. Why the fully checked concepts couldn't just use another keyword like "checked_concept" that behave exactly like the "concept" keyword for user of the library ? Library implementers can then migrate progressively their code when they can. edit: or, alternatively, create a "checked_template" keyword when implementing a checked template.
- BinaryIdiot 11y agoI'm very excited for networking to FINALLY be part of the standard. Practically every modern language has networking capability in their standard libraries. The day I can pick up C++ and, without including any third party libraries, write my own web server in a minimal amount of code will be the day I start using it more. Too much of what I do nowadays requires some form of networking.
- rb808 11y agoYeah I was a C++ dev for 12 years before switching out. I miss being able to hit the metal, its depressing to work with Python Pandas that are advertised as "nearly as fast as C". Meanwhile our main Java app has huge GC lockup problems. Hopefully C++ will soon be at a level I can recommend it for business applications again.
- giancarlostoro 11y agoSounds like you could take a look at D as an alternative to Java if you want to hit the bare metal and still have (optional) GC. I like D a little more coming from a C# / Java background but wanting something more natively compiled.
- fancy_pantser 11y agos/D/go/g
- giancarlostoro 11y agoOnly mentioned D for being Object Oriented with classes.
- unabridged 11y agoIt looks like they used most of ASIO except for their SSL support. So it will be up to the SSL library makers to add support for std::experimental::net::basic_socket.
- vardump 11y agoWhen will there be a C++XX that will actually remove bad features? Of course with a migration plan and tools. C++ standard is pretty big, I don't personally know anyone who really knows C++. I write C++ as my day job.
- jzwinck 11y agoThere have been deprecations like auto_ptr and gets(). But I assume you're looking for more. You aren't going to get it. C++ is just not that language. It isn't going to have a Python 3 moment. Nor should it. I for one am glad to be able to upgrade to new versions of the language without having to rewrite much.
- Noughmad 11y agoComplete breaking is never going to happen. What can be done is adding compiler switches which enforce some kind of "strict" or "modern" mode. Something close to "-Wall -Werror", but with errors explicitly for the deprecated/bad features.
- StephanTLavavej 11y agoActually, my proposal to remove auto_ptr etc. from C++17 was accepted: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4190.htm http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n419...
- santaclaus 11y agoScott Meyers (of Effective C++ fame) has a great blog post on breaking backwards compatibility [1]. Unfortunately, he views it as a 10 year process. [1] http://scottmeyers.blogspot.com/2015/11/breaking-all-eggs-in-c.html http://scottmeyers.blogspot.com/2015/11/breaking-all-eggs-in...
- readams 11y agoThe C++ standards committee and community has really been firing on all cylinders lately. C++ has made such enormous strides in the last few years. If you've been away from C++ for a while, check out modern C++ again. You'll be shocked by how good it's become. Just keep away from the Google C++ style guide lines. They'll lead you very far astray. Check out https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md https://github.com/isocpp/CppCoreGuidelines/blob/master/CppC... for a good start on modern C++ style.
- vardump 11y ago> Just keep away from the Google C++ style guide lines. They'll lead you very far astray. Huh. I think Google C++ style guide makes a lot of sense. C++, the good parts. What's wrong with the guide in your opinion? I know a lot of people might disagree, but the common criticism of Google's C++ style, exceptions, tends to be a misfeature when you need to actually handle the errors. It puts error handling code far from where errors occur, and where you often have the best chance to deal with it. It also obscures error sources, it's not immediately obvious in local method context just by looking at the source code which calls can throw and which not. Exceptions also don't undo any I/O that was done, so things might be in pretty bad state -- and it tends to be pretty bad to deal with that a few method calls up. I like errors to be on my face, even if they're "ugly". You tend to forget about hidden things.
- Noughmad 11y agoYou also tend to overlook/ignore the "if err != nil" in every other line, which Google seems to push. There is really no silver bullet for error handling, and sometimes you need more than one approach. However, I think exceptions are usually the best, especially because they work very well with RAII. It would be great to have some function annotations to show which exceptions can be thrown, though. But still, keep in mind tha Google's style is pretty much equivalent to having a catch(...) after every call.
- sseagull 11y ago>It would be great to have some function annotations to show which exceptions can be thrown, though. There was [0]. It is deprecated and generally discouraged, since it quickly becomes a maintenance nightmare (since you have to include unhandled exceptions for all functions called from that function, etc, all the way down). [0] http://en.cppreference.com/w/cpp/language/except_spec http://en.cppreference.com/w/cpp/language/except_spec
- je42 11y agoFinally "then" for futures ! Yay !
- Syntaf 11y agoI've given a number of talks on the parallelism TS at C++ conferences and fully believe it can revolutionize the C++ libraries, I really hope it can make it into C++17. Having such easy parallelism techniques within the language would be huge, I can think of so many scenarios where stupid-parallelism can be applied using the STL. The only set back is the additional room to shoot yourself in the foot, people that don't understand the overhead of parallelism could easily blow up a program in terms of efficiency.
- KKKKkkkk1 11y agoThe guys who've been prodding us to use chevron IO in lieu of printf and to pepper our code with gems like the for_each "algorithm" are back, and they have some new awesome features for us. Thanks, guys.
- jokoon 11y agoOther question: do you think that writing a compiler that only work with C++14 or 17, might compile code faster ? Or will C++ always be slow to compile ? I'm still wondering what makes go so fast to compile.
- looki 11y agoNot currently. I think it can be largely attributed to header files, for which we currently have no solution in modern C++. Think about what your code would look like if you expanded all #includes of a single file, each containing entire class definitions that need to be parsed. One of the proposals for the next C++ standard is for modules, which would allow better symbol importing and would largely boost compilation speeds, among other benefits.