Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What will C++17 be?

docs.google.com

Post reply on HN
Print view View original

61–70 of 86 posts

Re: What will C++17 be?

#61

Post by agumonkey »

joliss wrote: post #46

Some of these proposals are really intriguing. More details: Concepts: http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29 Modules: http://clang.llvm.org/docs/Modules.html Coroutines: 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/n417... Uniform call syntax: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n417..…

LtU posts about concepts being rejected for c++0x :

http://lambda-the-ultimate.org/node/3518 (voted off) http://lambda-the-ultimate.org/node/4450 (suggestions for future work)

Re: What will C++17 be?

#62

Post by dfan »

joliss wrote: post #46

Some of these proposals are really intriguing. More details: Concepts: http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29 Modules: http://clang.llvm.org/docs/Modules.html Coroutines: 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/n417... Uniform call syntax: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n417..…

Ranges are the killer feature for me. They'll actively improve my everyday code.

Re: What will C++17 be?

#63

Post by davidgerard »

fishnchips wrote: post #3

How 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.

"Every program will eventually include a sketchy rewrite of apt-get." - me.

Not just languages - WordPress, MediaWiki ...

If you're very lucky it won't clash horribly with apt and yum. So you probably won't be lucky.

Re: What will C++17 be?

#64

Post by StephanTLavavej »

gtani wrote: post #21
zerr wrote: post #6

Earlier quoted context omitted.

When 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.

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.

I'll be publishing an updated feature table soon.

Re: What will C++17 be?

#65

Post by thechao »

agumonkey wrote: post #61
joliss wrote: post #46

Some of these proposals are really intriguing. More details: Concepts: http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29 Modules: http://clang.llvm.org/docs/Modules.html Coroutines: 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/n417... Uniform call syntax: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n417..…

LtU posts about concepts being rejected for c++0x : http://lambda-the-ultimate.org/node/3518 (voted off) http://lambda-the-ultimate.org/node/4450 (suggestions for future work)

There were two fundamentally different proposals for concepts:

Indiana— concepts are records of signatures; checking is done "by signature"; an arbitrary mapping (adapter) can be defined. Notable authors: Doug Gregor, Jeremy Siek, Jaakko Jarvi, a lot of others I'm insulting by forgetting.

Texas— concepts are predicates of "actions" (usage of signatures; expressions). Notable authors: Bjarne Stroustrup, Gaby Dos Reis; later, Andy Sutton.

The crux of the issue is that Doug Gregor actually implemented the Indiana proposal (twice?) and Gaby never implemented the Texas proposal. By 2009, the Indiana proposal was well on track to being accepted; then ... it wasn't.

Fast forward 5 years, and now we've got a re-imagining of the Texas proposal, with no serious dissent, as all the Indiana folks moved on (out of exasperation, frustration; age; interest, whatever).

Re: What will C++17 be?

#66

Post by thechao »

stingraycharles wrote: post #50
humanrebar wrote: post #40

I 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 o…

Correct 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 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).

Concepts 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.

Re: What will C++17 be?

#67

Post by api »

Side 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.

Re: What will C++17 be?

#68

Post by falcolas »

tomp wrote: post #32
ris wrote: post #19

Earlier quoted context omitted.

Ugh. Language-based package managers are one of the biggest misfeatures of the millenium. They're all well and good* until they have to interact with the world outside their language universe. * I'm being very generous here.

Hm... Can you elaborate? I have nothing but good things to say about PIP (the only package manager I've used extensively).

My problem with pip: It requires a gcc compiler to implement most major packages, which is not a tool you want to actually have installed on the target servers.

You can do additional work to pre-build wheels or packages, but then you're stepping outside of the python and pip world and into maintaining your own repos and build servers and...

Re: What will C++17 be?

#69

Post by banachtarski »

dfan wrote: post #62
joliss wrote: post #46

Some of these proposals are really intriguing. More details: Concepts: http://en.wikipedia.org/wiki/Concepts_%28C%2B%2B%29 Modules: http://clang.llvm.org/docs/Modules.html Coroutines: 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/n417... Uniform call syntax: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n417..…

Ranges are the killer feature for me. They'll actively improve my everyday code.

You mean the ranges that already exist?
Post reply on HN