
What will C++17 be? - g1236627
https://docs.google.com/viewer?a=v&pid=forums&srcid=MTc1NDc3NTUyODUyOTc0MTkyOTUBMTExNzY5NTk0OTYwMjgzMDc4NzYBcDJPYmgzMWVENjBKATAuMQEBdjI
======
joliss
Some 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/n370...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2013/n3708.pdf)

operator. (for proxies): [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2014/n417...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2014/n4173.pdf)

Uniform call syntax: [http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2014/n417...](http://www.open-
std.org/jtc1/sc22/wg21/docs/papers/2014/n4174.pdf)

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

~~~
banachtarski
You mean the ranges that already exist?

~~~
dfan
Assuming that the ranges that already exist are the ones that get incorporated
into the C++17 standard, yes.

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

------
jmartinpetersen
The last slide is worth reading (and avoid doing) and most of it applies to
much more than committees for programming languages.

------
humanrebar
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 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
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<, 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
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.

------
bkjelden
I 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
That's part of the reason people want 'concepts'.

------
V-2
"Bad Committee habits to avoid" are perfectly pointed out.

------
davecheney
Bloated.

------
Chinmayh
and when would c++ 17 come?

~~~
mike-cardwell
c++11 came in 2011. c++14 came in 2014. Seeing a pattern yet?

~~~
zerr
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.

~~~
mike-cardwell
FWIW, Clang and GCC support all C++11 features.

~~~
hendzen
Though GCC only gained full C++11 support as of 5.1, which was released this
week.

~~~
detrino
I think you may be thinking of C++14, GCC has had full C++11 support since
4.8.1.

~~~
hendzen
Prior to 5.1 gcc had full C++11 language support, but libstdc++ did not have
full C++11 library support.

~~~
detrino
That's a fair point.

------
krick
Rust, maybe?… Ok, ok, relax, I'm just sayin'.

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

~~~
plq
From 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
Linux 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 )

~~~
Certhas
But Linux is used by a vastly larger percentage of C++ programers.

As an amateur, I've found kdenlive and audacity provide decent video and audio
editing on Linux. Professionals use Mac.

Typically installing Linux from scratch has involved less fiddling with
drivers than installing windows from scratch on an empty laptop for a while
now.

If you want a laptop with Linux support out of the box, you can pay for that
and it will just work (e.g.
[http://www.dell.com/us/business/p/xps-13-linux/pd](http://www.dell.com/us/business/p/xps-13-linux/pd)
or
[http://www.dell.com/us/business/p/laptops.aspx?c=us&cs=04&l=...](http://www.dell.com/us/business/p/laptops.aspx?c=us&cs=04&l=en&s=bsd&~ck=mn#!facets=80770~0~1791343&p=1))

Gaming is a fair point, but even that might be changing with Valves efforts.

I use Windows, Mac and Linux each, they all have their advantages, but for
serious software development Linux is ahead of MacOsX and both are way ahead
of Windows.

~~~
maccard
> Typically installing Linux from scratch has involved less fiddling with
> drivers than installing windows from scratch on an empty laptop for a while
> now.

Windows 8 has worked out of the box on every configuration I've tried, with
the caveat that it installs non up to date drivers (e.g. High end graphics
cards). My experience with Linux (Ubuntu 15.04) is that the little use
peripherals I have don't work at all ( I've a Bluetooth usb adapter and a usb
capture card that both are plug and play on windows vista onwards but I've yet
to find working drivers on Linux for).

