This talk was amazing, I was overwhelmed by the amount of work going into C++. The problem is that it is already an abysmally complex language (to me) and it doesn't look like anything is getting simpler. It's as if you had to be there from the start to have a full image of how the language grew and truly understand the interplay between all the "features", otherwise it's too late to become an expert, and in some cases even too late to become comfortable writing good maintainable code in C++.
Unfortunately nothing comes close to its level of "practical usefulness" in all dimensions (expressiveness, reasonable speed, ecosystem, etc...). I personally just stick to C because things are simple to understand and I just live with its shortcomings.
You don't need to use or master every tool in the shed. The hard part about C++ is to choose the right tools and to avoid the bad parts.
Things like memory management and concurrency are actually getting better.
- Put a smart pointer on the stack to handle your allocations. Share it and it persists. Forget about it and it deallocates your memory. No need to use raw pointers directly.
- Use things like futures to manage your concurrency. No need to know the finer semantics of mutexes just to pass around a few values.
- Templates enable a lot of cool stuff but you don't have to understand much about them to actually use them in a library.
That being said, if C solves your problems well, use it. There is nothing wrong with that. If you only need some parts of C++, use them where it actually makes sense.
The only problem is that this makes it a bit of a write only language. When there is an ocean of language features you don't know much about because you never use them, it becomes a barrier to reading someone else's code and find that they use those features extensively.
The worst is hotshot programmers that seem hellbent on using every feature a language offers because they just learned it in school and want to apply what they know, even though half of the time all they're doing is adding complexity for little gain.
To get an image of how the language grew (from a mid-90s perspective), you can read "The Design & Evolution of C++" by Bjarne Stroustrup. Then read "The C++ Programming Language (4th ed.)" to understand the new parts. And read "C++ Core Guidelines" (free on GitHub!) to grasp some best practices in modern C++. And, of course, practice.
"If all you have is a hammer, everything looks like a nail". In C you have to build everything from scratch. If you need classes, hack some structs. If you need string concatenation, write some mallocs and strcpy, and so on. C is cool, but really, there's no way C is more "practical" than C++11, and C++14 will be even better.
Perhaps you mean C++17? Almost the entirety of C++14 is supported in the latest versions of all major compilers as of about the middle of last year. There are some pieces held back (particularly in GCC pre-5.0 and MSVC), however they are tiny parts of the standard which do not largely affect the majority of changes you'll make from C++98 to C++11/C++14.
> It's as if you had to be there from the start to have a full image of how the language grew and truly understand the interplay between all the "features", otherwise it's too late to become an expert, and in some cases even too late to become comfortable writing good maintainable code in C++.
Although this is perhaps a poor anecdote more than anything, I myself only learned C++ six years ago (when I was learning to program, to boot). Overall the switch to using C++ today is more of an "unlearning" process, and requires that you don't treat the language as you would treat C (for better and or worse).
Overall I don't think it's true that you had to be there from the start, as you could easily just learn C++11 and C++14 style idioms today and avoid the hairier parts of the language if you want to. Reading through Scott Meyers' books are a great start, but overall I found that switching to a more modern style was very easy if you already know some basic concepts from other languages (range-based for, what a lambda is, how auto / type-inference works).
I guess really, is that I think giving up because C++ has evolved very differently from C or how other languages evolve just seems... defeatist?
> It's as if you had to be there from the start to have a full image of how the language grew and truly understand the interplay between all the "features", otherwise it's too late to become an expert, and in some cases even too late to become comfortable writing good maintainable code in C++.
This is funny to me (not in a condescending way) because I had the exact opposite thought today. I actually came back to C++ on my own fairly recently after learning about the modern version of the language. I was lamenting about how lucky I was to have started learning with C++14 because I didn't have to go through the horrible C++98 and C++03 eras. In fact I could simply ignore most of it.
It's all about diving straight into the modern stuff. The biggest problem with learning C++ is that most textbooks, classes, university courses don't actually teach you the real C++ parts until the last 4 weeks of the courses. Instead they teach you "C with classes.. and std::cout".
This has been acknowledged as an problem by some of the more prominent members of the committee.
I urge you to watch Kate Gregory's talk from cppcon 2015 "Stop Teaching C".
Not only is she a great presenter, but she makes amazing points about what is fundamentally wrong with how C++ is taught in classrooms around the globe. I really hope her talk makes some impact. I know I used to hate the language. That was when I was writing it for my university that for some reason didn't want to upgrade their 2007 gcc compiler. The C++ programming I learned from that course was so outdated that I literally cringe looking back. It's totally pointless to teach C++ that only compiles on legacy compilers. CS education can be so backwards sometimes. We have C++14 on every major compiler, people!
Either way, I'm not optimistic the language will ever be popular on this website. From what I've observed, every C++ topic, project, or observation is used as an excuse to bash the language and talk about Rust.
In high level parallel programming, say for SIMD or GPU (which really is just a fancy name for a wide SIMD engine with a ton of hardware threads to hide memory latency and a 2D-oriented gather/scatter memory controller), I wish there was a way to still expose the situation when your data is in reality shared by multiple "cores", when they're actually just different lanes in a same SIMD/WARP/whatever unit. Right now you just pretend they're separate, even when they can't even branch individually.
Example: Think about image processing algorithm, say 3x3 kernel. If you have 16-wide SIMD, using 3 registers, you only need special handling for the first and last pixels, only they cross the processing boundary. 14 pixels in the middle already have all of the data. If you can plan your memory accesses, you can do even better by shifting a pixel in from each new 16 pixel fetch.
Through abstraction you need to gather the 9 (3x3 kernel) center+neighboring values and run clamping for each neighbor access, even if you're not at the boundary of the image data. Even when a good SIMD/GPU compiler notices the data is already loaded, you still end up with needless saturation arithmetic (clamp) and most likely extra memory loads, potentially many times as many.
Sure, swizzling for locality of reference and a good cache controller help, but extra ALU work and memory accesses still mean sub-optimal performance.
This is where I've gotten good gains (up to 2-5x) when manually writing SIMD asm or intrinsics.
That's a lot of performance to leave on the table, given that CPU and GPU performance hasn't improved much in last 3 years.
This year we will get HBM1/2 [1] + more ALUs to use up that bandwidth for GPUs.
Next year AVX-512 for x86 CPUs. I guess HBM comes to also CPUs in a few years.
My guess is after that next significant improvements come maybe 2020-2025, if the current performance improvement trend holds.
Next step is probably CPUs absorbing GPU duties. So far memory bandwidth has been an issue, but now you can stick HBM chips just as well in a CPU package as in a GPU package. Just need some lower clocked ultra-wide cores.
10 comments
[ 5.3 ms ] story [ 40.5 ms ] threadThis talk was amazing, I was overwhelmed by the amount of work going into C++. The problem is that it is already an abysmally complex language (to me) and it doesn't look like anything is getting simpler. It's as if you had to be there from the start to have a full image of how the language grew and truly understand the interplay between all the "features", otherwise it's too late to become an expert, and in some cases even too late to become comfortable writing good maintainable code in C++.
Unfortunately nothing comes close to its level of "practical usefulness" in all dimensions (expressiveness, reasonable speed, ecosystem, etc...). I personally just stick to C because things are simple to understand and I just live with its shortcomings.
Things like memory management and concurrency are actually getting better.
- Put a smart pointer on the stack to handle your allocations. Share it and it persists. Forget about it and it deallocates your memory. No need to use raw pointers directly.
- Use things like futures to manage your concurrency. No need to know the finer semantics of mutexes just to pass around a few values.
- Templates enable a lot of cool stuff but you don't have to understand much about them to actually use them in a library.
That being said, if C solves your problems well, use it. There is nothing wrong with that. If you only need some parts of C++, use them where it actually makes sense.
The worst is hotshot programmers that seem hellbent on using every feature a language offers because they just learned it in school and want to apply what they know, even though half of the time all they're doing is adding complexity for little gain.
Perhaps you mean C++17? Almost the entirety of C++14 is supported in the latest versions of all major compilers as of about the middle of last year. There are some pieces held back (particularly in GCC pre-5.0 and MSVC), however they are tiny parts of the standard which do not largely affect the majority of changes you'll make from C++98 to C++11/C++14.
Although this is perhaps a poor anecdote more than anything, I myself only learned C++ six years ago (when I was learning to program, to boot). Overall the switch to using C++ today is more of an "unlearning" process, and requires that you don't treat the language as you would treat C (for better and or worse).
Overall I don't think it's true that you had to be there from the start, as you could easily just learn C++11 and C++14 style idioms today and avoid the hairier parts of the language if you want to. Reading through Scott Meyers' books are a great start, but overall I found that switching to a more modern style was very easy if you already know some basic concepts from other languages (range-based for, what a lambda is, how auto / type-inference works).
I guess really, is that I think giving up because C++ has evolved very differently from C or how other languages evolve just seems... defeatist?
This is funny to me (not in a condescending way) because I had the exact opposite thought today. I actually came back to C++ on my own fairly recently after learning about the modern version of the language. I was lamenting about how lucky I was to have started learning with C++14 because I didn't have to go through the horrible C++98 and C++03 eras. In fact I could simply ignore most of it.
It's all about diving straight into the modern stuff. The biggest problem with learning C++ is that most textbooks, classes, university courses don't actually teach you the real C++ parts until the last 4 weeks of the courses. Instead they teach you "C with classes.. and std::cout". This has been acknowledged as an problem by some of the more prominent members of the committee.
I urge you to watch Kate Gregory's talk from cppcon 2015 "Stop Teaching C".
https://www.youtube.com/watch?v=YnWhqhNdYyk
Not only is she a great presenter, but she makes amazing points about what is fundamentally wrong with how C++ is taught in classrooms around the globe. I really hope her talk makes some impact. I know I used to hate the language. That was when I was writing it for my university that for some reason didn't want to upgrade their 2007 gcc compiler. The C++ programming I learned from that course was so outdated that I literally cringe looking back. It's totally pointless to teach C++ that only compiles on legacy compilers. CS education can be so backwards sometimes. We have C++14 on every major compiler, people!
Either way, I'm not optimistic the language will ever be popular on this website. From what I've observed, every C++ topic, project, or observation is used as an excuse to bash the language and talk about Rust.
Example: Think about image processing algorithm, say 3x3 kernel. If you have 16-wide SIMD, using 3 registers, you only need special handling for the first and last pixels, only they cross the processing boundary. 14 pixels in the middle already have all of the data. If you can plan your memory accesses, you can do even better by shifting a pixel in from each new 16 pixel fetch.
Through abstraction you need to gather the 9 (3x3 kernel) center+neighboring values and run clamping for each neighbor access, even if you're not at the boundary of the image data. Even when a good SIMD/GPU compiler notices the data is already loaded, you still end up with needless saturation arithmetic (clamp) and most likely extra memory loads, potentially many times as many.
Sure, swizzling for locality of reference and a good cache controller help, but extra ALU work and memory accesses still mean sub-optimal performance.
This is where I've gotten good gains (up to 2-5x) when manually writing SIMD asm or intrinsics.
That's a lot of performance to leave on the table, given that CPU and GPU performance hasn't improved much in last 3 years.
This year we will get HBM1/2 [1] + more ALUs to use up that bandwidth for GPUs.
Next year AVX-512 for x86 CPUs. I guess HBM comes to also CPUs in a few years.
My guess is after that next significant improvements come maybe 2020-2025, if the current performance improvement trend holds.
Next step is probably CPUs absorbing GPU duties. So far memory bandwidth has been an issue, but now you can stick HBM chips just as well in a CPU package as in a GPU package. Just need some lower clocked ultra-wide cores.
[1]: https://en.wikipedia.org/wiki/High_Bandwidth_Memory