C++17 is feature complete.

This news is a week old, but meh. As far as I can tell, there hasn't been a thread about it here, so here goes.

These are the features that got added a few days ago:
https://herbsutter.com/2016/06/30/trip-report-summer-iso-c-standards-meeting-oulu/

As expected, many of the high-hype features (including concepts, ranges, and a standard networking library to name a few) didn't make it. However, there's also some really exciting stuff in there that I'm rather psyched about.

In my opinion, the end result isn't bad, it was just overhyped.

Thoughts?

-Albatross
I don't understand how the "Order of expression evaluation guarantees" solves the f(new T, new T) problem.

http://wg21.link/P0145R2
any pair of arguments (from the argument list) is indeterminately sequenced; meaning that one is evaluated before the other but the order is not specified

So we end with this scenario (1-2 may swap with 3-4)
http://gotw.ca/gotw/056.htm
1: allocate memory for T1 (first argument)
2: construct T1
3: allocate memory for T2 (second argument)
4: construct T2
5: call f()

The problem is this: If either step 3 or step 4 fails because of an exception, the C++ standard does not require that the T1 object be destroyed and its memory deallocated. This is a classic memory leak, and clearly not a Good Thing.
closed account (E0p9LyTq)
In my opinion, the end result isn't bad, it was just overhyped.

C++11 really did make major changes to how programs could be written, C++17 tried to be as much of a change and didn't quite make as such a significant change.

I do miss seeing a multi-dimensional STL array container added.

Now we will have to see how long the compiler creators take to add the C++17 features.
Oh man I've been getting a lot better in C++ 11 and 14 but I still got a lot to learn. How long will it take for most of the IDE's and compilers to get C++ 17 fully working? Also what exactly are concepts and ranges and why would they be useful?
Last edited on
How long will it take for most of the IDE's and compilers to get C++ 17 fully working?

I would imagine that it won't be until some time after C++17 is actually accepted, which will be sometime next year at the earliest.

From the link in the first post:
Between now and our November meeting, national bodies around the world will be reviewing the draft and reporting any concerns about feature design details and wording correctness or consistency. Then for probably the next two meetings we’ll be addressing every national body comment and recording its resolution, as well as continuing to process our own known issues lists to fine-tune the text of the standard. That usually takes two meetings, and if that’s the case again this time then we’ll be putting the finishing touches on C++17 in our November and March meetings and then, we hope, sending C++17 out for its possibly-final ballot in the spring. If we need an extra meeting, then that would extend to the July meeting next year and the possibly-final ballot in late summer.


Also note that it looks like concepts will not make it into C++17.
Despite its relative newness and lack of field experience, the committee seriously considered adopting it already for C++17 at this meeting. It was right on the edge: There was already a strong minority who felt it was ready to add to C++17, and a modest majority preferred to wait another year or two and get more experience with shipping implementations and field use of the feature.

Last edited on
Major compilers already have some support for certain C++17 features, mainly the ones that are simple to implement.
Michael Wong's report (specifically Bjarne's concerns quoted in it that came true) is closer to what I feel about it: https://codeplay.com/public/uploaded/filehost/0cbdaf_c++17post-oulu2016.pdf

(btw, he got one thing wrong: polymorphic allocators are part of C++17 draft, and have been since march, as can be seen in n4394, the pre-Oulu draft)
Last edited on
I guess this may be the first meaningful update for me. I got into programming last year so everything was already C++11 compliant, so I don't know the struggles you guys dealt with previously. Of course, things like lambdas and type aliases and auto I rarely use anyway, but they are convenient when I do.

I guess I have a question that has always bothered me as I read through textbooks and play with code: at what point after a standard has been reviewed, published, and implemented can it be considered that the new features are completely portable? I mean, surely C++11 features are now standard for every (major) compiler, but is there a point after release when new features should be considered, "standard, but not (yet) widely accepted?"
Yawzheek wrote:
at what point after a standard has been reviewed, published, and implemented can it be considered that the new features are completely portable?


"implemented" is the key word here. As soon as it is implemented by two compilers, the new features are portable between those two compilers.

I'll try to recover the recent timeline:

2011:
C++11 published
2012:
clang completes C++11 standard library (written from scratch)
2013:
gcc 4.8.1 completes C++11 core language
clang 3.3 completes C++11 core language
Visual Studio completes C++11 standard library (not core language)
intel 14.0 completes C++11 core language
EDG 4.8 completes C++11 core language

2014:
C++14 published
clang 3.4 completes C++14 core language (ahead of publication)
clang 3.5 completes C++14 standard library
2015:
gcc 5.1 completes C++11 standard library (finally)
gcc 5.1 completes C++14 core language
gcc 5.1 completes C++14 standard library
Visual Studio completes C++14 standard library (not core language)
Visual Studio is *almost* done with C++11 and C++14 core language
2016:
Oracle Studio completes C++11 core language

Since C++17 was a fairly minor update to core language, but major update to the library, I would expect gcc and clang will claim full core language in the same year, and finish up their libraries in 2018 (gcc learned from their 2011 mess and already has a lead there, but clang is very aggressively competitive), and Microsoft will likely do both core language and library in 2018 as well (their library was fully up to date with C++17-so-far at the beginning of 2016)
Last edited on
So will I be able to write :
1
2
3
4
int foo[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }; 

for(int i = 0; i < capacityof(foo); i++)
std:: cout << foo[i]; 


Instead of having to write :
1
2
3
4
int foo[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }; 

for(int i = 0; i < sizeof(foo) / sizeof(int); i++)
std:: cout << foo[i]; 


Maybe this is also nice too :
1
2
3
4
int foo[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }; 

for(int &x : foo)
std:: cout << x; 


Note : I want this "capacityof" to become an offical keyword. I don't want it to be done by some magical template.
@closed account 5a8Ym39o6 (531)

What is special about the last one? That is a range based based for loop, and been around since C++11.

The trouble is that an array doesn't have begin and end iterators, but one can easily define them.

Further, the idea is to avoid using ordinary arrays, use an STL container instead.
Last edited on
will I be able to write :
int foo[] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
for(int i = 0; i < capacityof(foo); i++)


yes, only that C++17 function is called std::size http://en.cppreference.com/w/cpp/iterator/size

(but range-for from C++11 is generally seen as better)
Last edited on
Note : I want this "capacityof" to become an offical keyword. I don't want it to be done by some magical template.


Why not?
@TheIdeasMan
> Why not?
What do you mean?
What do you mean?


Why don't you want to be a template?
> Why don't you want to be a template?
Its role is too basic. No need to be done by template.

I simply want this "capacityof" to have a special blue color like that of a keyword.
No need to be done by template.


I am sure there are very good reasons why it probably (implementation is not specified in the standard) is a template. Adding new keywords doesn't seem to happen very often in C++, probably lots of good reasons for that too.

closed account 5a8Ym39o6 wrote:
Its role is too basic. No need to be done by template.

I simply want this "capacityof" to have a special blue color like that of a keyword
So just tell your IDE to color things in the std namespace that way? That's a pretty silly reason to add a new keyword to the language.
Topic archived. No new replies allowed.