What to expect with C++20
Contracts getting yanked out at the last second was really disappointing. I also wish executors (and therefore networking) could have made it, more so than coroutines to be honest.
Still, I'm hyped! Hopefully the toolchain vendors won't take too long to get everything implemented this time.
-Albatross
EDIT: Typos.
I'm sure someone's made this comment before, but if C++17 is modern C++, can we call C++20 postmodern C++, or are we going to retroactively call C++11-through-17 "medieval C++"?
Still, I'm hyped! Hopefully the toolchain vendors won't take too long to get everything implemented this time.
-Albatross
EDIT: Typos.
I'm sure someone's made this comment before, but if C++17 is modern C++, can we call C++20 postmodern C++, or are we going to retroactively call C++11-through-17 "medieval C++"?
Last edited on
Heh, I’d like to go with “postmodern”, but I don’t know if C++20 sufficiently embraces a healthy skepticism of objectivity with enough of a hippie-like enjoyment of randomness and subjectivity. It seems to me that it’s still trying too hard to reach enlightenment through a grand, unified ideology.
I like the name but that medieval is more of c++ pre STL. Which there is still PLENTY of people coding (see turbo C++ questions from India). The STL (really, the second or third crack at it, it was horribad in the first go) was the game changer, the 'great enlightenment' or Renaissance sort of moment.
| Surely that's the dark ages. And I guess C is prehistoric. |
Now I feel old.
I wrote in C for years before C++ existed. I think my first C compilation was in '78
| Niccolo wrote: |
|---|
| I think my first C compilation was in '78 |
Hoo boy, that'd mean you were were writing C about 6 years after its creation, and a whopping 11 years before its standardization. O_o
| Duthomhas wrote: |
|---|
| It seems to me that it’s still trying too hard to reach enlightenment through a grand, unified ideology. |
I think every well-designed programming language is opinionated and has an ideology to strive for. Whether that ideology is practical or not... well, that's another story. That said, what unified ideology are you referring to? I was more under the impression that C++ is caught between groups of people with different ideas of what's most important for C++.
-Albatross
| Hoo boy, that'd mean you were were writing C about 6 years after its creation, and a whopping 11 years before its standardization. |
That's actually true. I forget the hardware (it was a brand new installation at the local university - the actual machine was behind a glass wall - visitors like me couldn't touch it, just the terminals), and the K & R book had not yet been published (but released that year).
I was 15, and through my father's friends managed to get "invited" to learn on a "real computer system", as opposed to the 8 bit TRS-80, Apple 2 and other 6502 based machines I had at the house. One of the large donors who paid for the new machine introduced me to the brand new professor of the CS department, and I managed to work that door open into a daily visitation to study and learn C and UNIX. Since even the department was new I had only 2 other students competing for 6 terminals setup for students. Nearly free reign given the time.
Even at that point (post Apple 2 release), it was rare for families to have a computer at home, so a "kid" that knew assembler (6502 & Z80, modest CPU's to be sure), and, obviously, BASIC - was a kind of fascination to professors. You might find 1 in 2,000 people had ever seen a computer, other than in a store or a movie.
A different era, virtually a different world.
Last edited on
I also looked forward to Contracts. I hope they make it into C++23, without having any vital parts removed. As long as I can (1) disable contracts, (2) check contracts, and (3) assume contracts, I'll be happy.
Here is a list of some C++20 features that I'm excited about:
std::bit_cast - a safe alternative to std::memcpy when converting raw bits from one type to another.
constexpr std::string and std::vector - Nice to be able to use some resizable containers in constexpr functions.
std::erase/erase_if for containers - No need to use the erase-remove idiom anymore.
std::format - Looks like a nice alternative to standard stream formatting. Similar to how printf does it but type-safe and with a different syntax.
std::is_constant_evaluated - Useful if you want to provide a constexpr implementation and also a more efficient implementation that will be used at runtime but that cannot be constexpr for some reason. Though, one must be careful to avoid ending up with a function that gives different results depending on if it's evaluated in a constexpr context or not.
std::numbers::pi - Not a huge deal but nice to have it in the standard.
std::ranges - I haven't actually tested them, but it looks nice to be able to pass ranges (e.g. containers) without having to specify a begin and end iterator. Better error messages thanks to Contracts also seems like a big advantage because the current algorithm functions can often lead to pretty long error messages that are difficult to read.
Signed integers are guaranteed to use two's complement - This turns some previously implementation-defined behaviour into guaranteed behaviour (e.g. conversion from unsigned to signed). Not sure if it actually changes anything on current implementations but it's nice to know I can rely on things to work the same everywhere.
std::span - Makes it easy to work with subranges. Like std::string_view but for any type of data. Unfortunately there is no easy comparison with ==.
Here is a list of some C++20 features that I'm excited about:
std::bit_cast - a safe alternative to std::memcpy when converting raw bits from one type to another.
constexpr std::string and std::vector - Nice to be able to use some resizable containers in constexpr functions.
std::erase/erase_if for containers - No need to use the erase-remove idiom anymore.
std::format - Looks like a nice alternative to standard stream formatting. Similar to how printf does it but type-safe and with a different syntax.
std::is_constant_evaluated - Useful if you want to provide a constexpr implementation and also a more efficient implementation that will be used at runtime but that cannot be constexpr for some reason. Though, one must be careful to avoid ending up with a function that gives different results depending on if it's evaluated in a constexpr context or not.
std::numbers::pi - Not a huge deal but nice to have it in the standard.
std::ranges - I haven't actually tested them, but it looks nice to be able to pass ranges (e.g. containers) without having to specify a begin and end iterator. Better error messages thanks to Contracts also seems like a big advantage because the current algorithm functions can often lead to pretty long error messages that are difficult to read.
Signed integers are guaranteed to use two's complement - This turns some previously implementation-defined behaviour into guaranteed behaviour (e.g. conversion from unsigned to signed). Not sure if it actually changes anything on current implementations but it's nice to know I can rely on things to work the same everywhere.
std::span - Makes it easy to work with subranges. Like std::string_view but for any type of data. Unfortunately there is no easy comparison with ==.
Last edited on
I'm happy I can write function templates without the pointless template keyword, as
And yes, finally
void f(auto x) (this was a GCC extension for a while , now C++20 standard).And yes, finally
sort(v) instead of sort(v.begin(), v.end()), although range-enabled algos got shunted into a different namespace.
I'm looking forward to it. Although the job of compiler implementers seems to get harder with each release. And now more than ever, with the C++11 and beyond features, it is harder and harder to get proper "IntelliSense"-like real-time parsing features in C++, because parsing the language almost requires the computer to compile the language. I'm not expecting something like that soon, but hopefully new features will allow for better compiler error messages, like what Peter mentioned.
Does that have all the usual limitations/rules of templates (e.g. overload resolution)?
In other words, is
| void f(auto x) |
In other words, is
void f(auto x) { } just syntactic sugar for |
|
Last edited on
| Ganado wrote: |
|---|
| is void f(auto x) { } just syntactic sugar for |
yes: http://eel.is/c++draft/dcl.fct#17 "An abbreviated function template is equivalent to a function template..."
Oh, man. More to learn and self-teach. Oy, it never stops.
I was finally comfortable with most of what C++11 & C++14 added to the language, still wrapping my head what C++17 allowed me to do. Soon comes C++20 and I'll feel like a newb all over again. :(
I was finally comfortable with most of what C++11 & C++14 added to the language, still wrapping my head what C++17 allowed me to do. Soon comes C++20 and I'll feel like a newb all over again. :(
Yeaaah, C++20 is going to be another one of those releases that's so impactful that it really would call for major rewrites of existing (decent) tutorials — if they were keeping up to date at all. C++23 is looking like it'll also have some significant additions, but it'll probably be more like C++17 in scale.
Actually, a couple of years ago, I'd started writing a C++17 tutorial, but didn't get very far due to life circumstances. Maybe I should consider writing a C++20 tutorial instead, as massive an undertaking as that'd be.
-Albatross
Actually, a couple of years ago, I'd started writing a C++17 tutorial, but didn't get very far due to life circumstances. Maybe I should consider writing a C++20 tutorial instead, as massive an undertaking as that'd be.
-Albatross
"...Soon comes C++20 and I'll feel like a newb all over again..."
That happened to me when as a C programmer in the 80's, when C was finally standardized.
...then again when CFront (what was C++ in '86 as I recall) came out.
...then again with C++ 2.0 (templates were new)
...and of course with C99, and C++98, which was "just" after Windows released their 32bit API in '95 and NT (yeah, 3 years was quick by that point)
...then there was C++03 (C++0x for a while)
...of course C++11 was a REAL moment of re-newbiness
Through 14 wasn't so much
17...yeah, that was a bit more to think about
THIS one is more like C++11 (for all of us C and early C++ adopters).
At least I never had to look back to recall any of my RPG, VB or that one summer I had to work translating COBOL into a C application (we just took ideas, not really translating).
That happened to me when as a C programmer in the 80's, when C was finally standardized.
...then again when CFront (what was C++ in '86 as I recall) came out.
...then again with C++ 2.0 (templates were new)
...and of course with C99, and C++98, which was "just" after Windows released their 32bit API in '95 and NT (yeah, 3 years was quick by that point)
...then there was C++03 (C++0x for a while)
...of course C++11 was a REAL moment of re-newbiness
Through 14 wasn't so much
17...yeah, that was a bit more to think about
THIS one is more like C++11 (for all of us C and early C++ adopters).
At least I never had to look back to recall any of my RPG, VB or that one summer I had to work translating COBOL into a C application (we just took ideas, not really translating).
@Albatross,
For me C++17 in several aspects was as noteworthy as C++11.
One major change IMO: removing std::random_shuffle(), relying on <cstdlib> for rand().
If there is a C++ and C library way to do things I prefer using the C++ method(s).
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3551.pdf
I have created a personal use header only version of the simple toolkit proposed in that paper.
Makes it easy to "drop in" the header for any C++ project I want C++ generated random numbers not needing some hefty work. Light weight works for most of my uses.
For me C++17 in several aspects was as noteworthy as C++11.
One major change IMO: removing std::random_shuffle(), relying on <cstdlib> for rand().
If there is a C++ and C library way to do things I prefer using the C++ method(s).
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3551.pdf
I have created a personal use header only version of the simple toolkit proposed in that paper.
Makes it easy to "drop in" the header for any C++ project I want C++ generated random numbers not needing some hefty work. Light weight works for most of my uses.
Last edited on
@Niccolo, I feel like a newb with C++ overall. I have no formal training, no classroom instruction, I'm learning it all on my own. Books, online resources, etc.
A while back I found an eBook on C++17 by Nicolai M. Josuttis. (Not yet finished, 99% complete) I decided to buy it.
First chapter is structured binding with some source code, and it was wonderful. I "get it!"
I believe I will look into getting one of his other books, about C++ Templates.
A while back I found an eBook on C++17 by Nicolai M. Josuttis. (Not yet finished, 99% complete) I decided to buy it.
First chapter is structured binding with some source code, and it was wonderful. I "get it!"
I believe I will look into getting one of his other books, about C++ Templates.
| I feel like a newb with C++ overall. I have no formal training, no classroom instruction, I'm learning it all on my own. Books, online resources, etc. |
Better than my professors so far - I wouldn't worry about a lack of formal education on it holding back your knowledge and skills in the language.