What do you want to be in C++ 17

Pages: 12
I was wondering what you would want to see be added to the C++ 17 standard. I would like to see auto functions/auto parameters I think it would be pretty cool. I know there are templates but I feel like auto could make some things simpler whilst templates could be more specialized/complex.
A lot of people were hoping for Concepts, but they didn't make it for good reason:

I'm personally hoping for modules but I'm not even sure they will make it either.

More info about what has been happening here:
LB wrote:
they didn't make it for good reason:

I disagree with that, and the majority of the committee disagrees too.. unfortunately (or, sometimes, fortunately), passing requires more than majority.

The reason modules were punted to a TS was that Google can't let go of preprocessor macros. It's a strange era these days where Microsoft is coming up with major C++ innovations (modules and coroutines are both in their released compiler) and Google is blocking them in the name of backwards compatibility.
Last edited on
I'm hoping that we don't see a graphics library. Ever, really.
Networking library would be nice to have. Ideally I would like to be able to get data from web and parse json or xml without external libraries.
What would I want in C++17?

A Hot Blonde and the access code to a stuffed full numbered Swiss bank account.

Seriously, putting what people were looking for in C++14 that didn't make it would be a good start.
closed account (1vD3vCM9)
I would like to have an official network library ( NOT BOOST ), and for files, std::exists() that will check if a file exists.
C++17: std::filesystem::exists()
C++14 with Filesystem TS: std::experimental::filesystem::exists()

(Filesystem (currently a TS) would be part of the standard library in C++17)
oren drobitsky wrote:
I would like to have an official network library ( NOT BOOST )

What library do you propose instead? How widely is it used?

to quote the draft of the C++ Networking Library technical specification,

The Boost.Asio library, from which this proposal is derived, has been deployed in numerous systems, from large (including internet-facing HTTP servers, instant messaging gateways and financial markets applications) to small (mobile phones and embedded systems). The Asio library supports, or has been ported to, many operating systems including Linux, Mac OS X, Windows (native), Windows Runtime, Solaris, FreeBSD, NetBSD, OpenBSD, HP-UX, Tru64, AIX, iOS, Android, WinCE, Symbian, vxWorks and QNX Neutrino.

(btw, since it's already part of C++17 working draft, cppreference also documents exists under http://en.cppreference.com/w/cpp/filesystem/exists - not in the index yet, though)
I don't think that I want to see a networking library tacked onto the standard library.
If a networking library gets added to the standard library, I'm probably going to be ignoring it more than half the time. I don't think networking is something where you can just pick one interface and have it cover all bases - nearly every networking library I have seen has been different enough that switching from one to the other is not trivial. Each has their strengths and weaknesses and was designed to suit a particular set of purposes. I can see the appeal of having a standard networking library but I just think it's a bad idea. What's next, a standard graphics library?

I've also heard people say that adding a networking library to the standard would be good for C++ because of the IoT...but aren't IoT devices usually systems where the standard library isn't even available in the first place?
I use ASIO for literally everything. I've yet to run into any issues that it doesn't handle. It also handles multiplexing file IO as well... what kind of issues can you think of that you would run into?

EDIT: That said, I'm actually against adding a networking library since I'd probably end up using ASIO anyways for the next decade until every compiler has a working optimized version of pretty much the exact same thing.
Last edited on
closed account (1vD3vCM9)
I can't stand Boost, and I'll never use it.
It just seems that everyone is giving an Boost solution to EVERYTHING.
Don't get me wrong the library itself is good, but Linus Torvalds said himself, when he spoken about C++, that almost all C++ programmers use Boost and STL and get distracted from doing actual programming.
Torvalds hates C++, and I'm not sure he'd hate it less if there wasn't a Boost. I'm not sure what he considers 'real programming' but if he's wearing an onion belt while saying it I'm going to take it with a grain of salt.
LB wrote:
Torvalds hates C++

Ah, the irony of the sneering at C++ by "real programmers."

C++11 included a single dimension fixed size array container into the STL, why not include a multi-dimension array template in C++17?
Can't you just use std::array<std::array<int,3>,3>?
There is a proposal for multidimensional array views http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0009r1.html
it was reviewed mosty positively, but there is still work to do, so it didn't make the C++17 cutoff: https://issues.isocpp.org/show_bug.cgi?id=80
Nice to see the idea was reviewed, too bad it wasn't ready for prime-time with C++17.

The proposal does look promising.
shadowmouse wrote:
Can't you just use std::array<std::array<int,3>,3>?

I could, but then AFAIK the array's fill() modifier wouldn't work as designed.

The workaround using multiple for statements, as is needed with "raw" multidimensional arrays, would work as expected.

What if you want an array that is [2][4]? The initialization is counter-intuitive:
std::array<std::array<int, 4>, 2> myarray {};

Multidimensional arrays of more than two dimensions gets even more IMO "hackish," [3][2][4]:
std::array<std::array<std::array<int, 4>, 2>, 3>

It would be nice to have multidimensional STL arrays be a part of the standard, a dream would be having dynamic containers be multidimensional as well.
Last edited on
Pages: 12