Scott Meyers, author of the Effective C++ books, hosts his C++ papers, talk slides, and book information.
HN cites his essay on double-checked locking and his books, with commenters recommending Effective Modern C++ for learning to avoid C++ performance problems.
There's a looming feeling that C++17 is really going to be the last version of C++ (practically, in production). The Vasa is now half-sunk [0][1], but the alternatives are yet to be truly born. The current issues surrounding the language standards:
- The important but half-baked features of C++20 that has never really been polished enough for actual production usage (modules, coroutines)
- Unnecessary "hyper-modern" C++ features which are dead on arrival (ranges)
- The dramatic increase in build times due to the STL library (which are accelerated by those hyper-modern C++ features) [2]
- The fleeing of LLVM/Clang engineers to other projects (as you've said, Apple engineers shifting work to Swift, and Google abandoning Clang and moving to Carbon).
- Implosions in the ISO committee (notably the controversy surrounding the rape convict)
It's really not looking good, but there aren't that much alternatives so I think people will just stick to C++17 for the moment. Listing the worthwhile competitors:
- Rust is a bit too awkward to use in many cases where C++ is used (particularly with unsafe Rust), and inherits some of the hyper-modern complexities/insanities of C++.
- Zig is still too unstable, they just finished reworking the compiler
- Jai is not even released to the public
- D might be a candidate but IMO they should really commit 100% fully for GC-less betterC mode...
- Nim still has many warts and unbaked features, and also there was a split in the compiler team…
Interesting. This appears to solve a more general problem, which is: how to create a barrier against inter-procedural optimization and dead code elimination.
I wonder if this trick could also be used to solve the double-checked locking problem.
From the quintessential DCLP paper (http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf):
Consider again the line that initializes pInstance:
pInstance = new Singleton;
This statement causes three things to happen:
Step 1: Allocate memory to hold a Singleton object.
Step 2: Construct a Singleton object in the allocated memory.
Step 3: Make pInstance point to the allocated memory.
[...]
DCLP will work only if steps 1 and 2 are completed before
step 3 is performed, but *there is no way to express this
constraint in C or C++*.
But Colin's pattern here seems to be a way of indeed guaranteeing this. The volatile function pointer is a barrier against inter-procedural optimization: if the function must be called, then step 3 cannot possibly be performed before steps 1 and 2.
(There might still be necessary hardware barriers that are missing, and the lack of a memory model for pre-C11/C++11 probably makes it all technically undefined behavior anyway. But the key sequential ordering constraint that was claimed inexpressible in C and C++ appears to indeed be expressible with this trick, if indeed the trick works for guaranteeing a call to memset).
You're asking more specific questions that what I will cover, and they're good ones. It will be interesting to read how others reply.
For the other people looking, Stroustrup's A Tour of C++ [0] is the guide for getting quickly up to date with the "new C++", C++11 and onwards. It doesn't specifically cover C++14, but if you understand C++11, the few things coming in C++14 are for the most part minor enhancements to what is in C++11.
Scott Meyers should finish up the C++11/14 version of the Effective C++ series this year, and many are waiting for this. For now, his notes Overview of the New C++ (C++11/14) [1] are available for purchase.
If you like videos, there is a wealth of information from last years GoingNative conference [2]. More recently, at this years Build conferece, Herb Sutter gave a presentation on Modern C++: What You Need to Know [3].
Finally, come visit up over on reddit in /r/cpp [4]. Some heavyweights in the C++ world participate there, and the larger portion of participants are similarly knowledgeable in C++ as a whole.
[0] http://www.amazon.com/Tour-In-Depth-Series-Bjarne-Stroustrup/dp/0321958314
[1] http://www.aristeia.com/Licensing/personalUse.html
[2] http://channel9.msdn.com/Events/GoingNative/2013?direction=asc#tab_sortBy_day
[3] http://channel9.msdn.com/Events/Build/2014/2-661
[4] http://www.reddit.com/r/cpp
Scott Meyers (author of Effective C++ et al.) has talked about this subject many times (including in the aformentioned book) and it puts the ball squarely in the Rails team's court.
Let's make the reasonable assumption that your clients—the people using your interfaces— are trying to do a good job. They're smart, they're motivated, they're conscientious. They're willing to read some documentation to help them understand the system they're using. They want things to behave correctly.
That being the case, if they make a mistake when using your interface, it's your fault. We're assuming they're doing their best—they want to succeed. If they fail, it's because you let them. So, if somebody uses your interface incorrectly, either they're working hard at it (less likely) or your interface allowed them to do something easy that was not correct (more likely). This puts the shoe on the foot not used to wearing it: it means that responsibility for interface usage errors belongs to the interface designer, not the interface user.
Source: Scott Meyers: The Most Important Design Guideline? http://www.aristeia.com/Papers/IEEE_Software_JulAug_2004_revised.htm
His webpage: http://www.aristeia.com/ indicates that he has been a programmer since 1972. Even if he has been doing training/consulting for a couple of decades, that leaves a lot of time to get the basics down. I've never met him, though I have browsed one of his books once.
My own personal feeling is that books like these can be invaluable for people starting out in the industry. It gives you a reference point to relate to. If he can explain things well and people can understand his writing, then it can be useful even if the person isn't the best living coder on earth.
At some point in your development, you need to branch out from what people are saying in books and start to form your own opinions. You have to start questioning what the "experts" are saying and try to experiment with other techniques. It is frustrating when people hang on to certain ideas just because a famous author said it. Sometimes it holds us back. It doesn't make their contribution any less valuable, though, because at least newbies are getting to a certain level due to the well written books.
Yeah, my biggest issue with C/C++ on embedded systems is that it's cumbersome to build useful, safe abstractions of hardware. Almost every manufacturer-provided MCU driver library I've encountered is filled with void* and #define abuse that wouldn't fly in any other type of project.
I once worked on a project where some poor soul took the time to provide a zero-cost abstraction, described in a Scott Meyers presentation[1], for every register on an MCU. This resulted in thousands of lines of C++ template classes, which, while hurting compile times, resulted in a really strong, safe and performant API that drivers could be built upon. It was wonderful to use, but all that upfront work isn't realistic for most projects.
I'd definitely be interested in a language that supports this type of abstraction "natively" (i.e. doesn't require lots of boilerplate code) while providing C-like performance on bare-metal platforms. I know that some people are trying to make Rust fit this hole but I'm not sure how that's coming along.
1. http://www.aristeia.com/c++-in-embedded.html