noexcept whenever possible?
noexcept functions. My advice is "Declare functions noexcept whenever possible." Some people appear to be concerned that this could be misconstrued as advocating noexcept even when it makes no sense, but I think the advice is a reasonable conclusion to the Item that supports it. I posted a draft version of that Item in early February, but I've revised the draft since then, and I'm making the current draft available now:noexcept whenever possible."constexpr functions are normally good candidates for noexcept?noexcept whenever possible. If they're special, why?inline functions get special consideration, or should they also be declared noexcept whenever possible? If they're special, how so?Chapter 1 Deducing Types
Item 1: Understand template type deduction.
Item 2: Understand decltype.
Item 3: Know how to view deduced types.
Chapter 2 auto
Item 4: Prefer auto to explicit type declarations.
Item 5: Remember that in variable declarations, auto + { expr }
yields a std::initializer_list.
Item 6: Be aware of the typed initializer idiom.
Chapter 3 From C++98 to C++11 and C++14
Item 7: Distinguish () and {} when creating objects.
Item 8: Prefer nullptr to 0 and NULL.
Item 9: Prefer alias declarations to typedefs.
Item 10: Prefer scoped enums to unscoped enums.
Item 11: Prefer deleted functions to private undefined ones.
Item 12: Declare overriding functions override.
Item 13: Prefer const_iterators to iterators.
Item 14: Use constexpr whenever possible.
Item 15: Make const member functions thread-safe.
Item 16: Declare functions noexcept whenever possible.
Item 17: Consider pass by value for cheap-to-move parameters that
are always copied.
Item 18: Consider emplacement instead of insertion.
Item 19: Understand special member function generation.
Chapter 4 Smart Pointers
Item 20: Use std::unique_ptr for exclusive-ownership resource
management.
Item 21: Use std::shared_ptr for shared-ownership resource
management.
Item 22: Use std::weak_ptr for std::shared_ptr-like pointers that can
dangle.
Item 23: Prefer std::make_unique and std::make_shared to direct use
of new.
Item 24: When using the Pimpl Idiom, define special member
functions in the implementation file.
Chapter 5 Lambda Expression
Item 25: Avoid default capture modes.
Item 26: Keep closures small.
Item 27: Prefer lambdas to std::bind.
Chapter 6 Rvalue References, Move Semantics, and Perfect Forwarding
Item 28: Understand std::move and std::forward.
Item 29: Distinguish universal references from rvalue references.
Item 30: Pass and return rvalue references via std::move, universal
references via std::forward.
Item 31: Avoid overloading on universal references.
Item 32: Understand alternatives to overloading on universal
references.
Item 33: Understand reference collapsing.
Item 34: Assume that move operations are not present, not cheap,
and not used.
Item 35: Familiarize yourself with perfect forwarding failure cases.
Chapter 7 The Threading API
Item 36: Make std::threads unjoinable on all paths.
Item 37: Specify std::launch::async if asynchronicity is essential.
Item 38: Be aware of varying thread handle destructor behavior
Item 39: Consider void futures for one-shot event communcation.
Item 40: Reserve std::atomic for concurrency, volatile for memory-mapped
I/O.
Item 41: Employ sequential consistency if at all possible.
On May 22, I'll giving a keynote address at the D Conference, The Last Thing D Needs. That'll take place in Meno Park, CA. I'm deliberately publishing no description of this talk, because I'd like to maintain the air of mystery engendered by the organizers' asking me to give a talk at conference on a programming language other than the one I'm normally associated with :-)
Classes that have custom destructors, copy/move constructors or copy/move assignment operators should deal exclusively with ownership. Other classes should not have custom destructors, copy/move constructors or copy/move assignment operators.By "not have," Martinho really means "not declare", because all classes have destructors, one way or another, and the blog post makes clear that Martinho expects a non-resource-handling class to have the copying and moving behavior exhibited by its data members (and hence to have the corresponding functions, assuming such functionality is employed). If we revise the wording of the rule in accord with
s/have/declare/g, we get:Classes that declare custom destructors, copy/move constructors or copy/move assignment operators should deal exclusively with ownership. Other classes should not declare custom destructors, copy/move constructors or copy/move assignment operators.This advice makes me a bit uncomfortable.
Widget that doesn't do resource management. Per the Rule of Zero, it declares none of the five special functions covered by the rule. Further assume that its data members are both copyable and movable. Widget objects are therefore copyable and movable, too.class Widget {
public:
... // no dtor or copy or move functions
};
Wonderful. Life is good.class Widget {
public:
~Widget(); // temporary destructor
... // no copy or move functions
};
The addition of the destructor has the side effect of disabling generation of the move functions, but because Widget is copyable, all the code that used to generate moves will now generate copies. In other words, adding a destructor to the class has caused presumably-efficient moves to be silently replaced with presumably-less-efficient copies. That strikes me as the kind of thing that (1) is likely to surprise people and (2) could really complicate debugging. Hence my discomfort.=default:class Widget {
public:
Widget(const Widget&) = default;
Widget(Widget&&) = default;
Widget& operator=(const Widget&) = default;
Widget& operator=(Widget&&) = default;
...
};
With this approach, the spirit of the Rule of Zero remains:
classes that don't manage resources should be designed so that the
compiler-generated functions for copying, moving, and destruction do the
right things. But instead of expressing this by not declaring those functions, it's expressed by declaring them explicitly and equally explicitly opting in to the compiler-generated implementations.defaults?noexcept whenever possible." const int ci = 42;
auto f = [ci]() mutable { std::cout << ci << '\n'; };
f(); // prints 42
This captures the local variable ci by value, thus putting a copy of it inside f. What's interesting is that because ci is const, the copy of it is const, too. That means that attempting to modify the copy of ci inside f won't compile:
const int ci = 42;
auto f = [ci]() mutable
{ std::cout << ++ci << '\n'; }; // error! can't modify
// copy of ci that's in f
I wrote about this a couple of years ago in my article, Appearing and Disappearing consts in C++. const int ci = 42;
auto f = [ci = ci]() mutable // note revised capture mode
{ std::cout << ++ci << '\n'; }; // okay! copy of ci in f is non-const!
The spec for such captures says that the type of the variable being initialized (the left-hand ci) is determined by the rules used by auto, and auto ignores the constness of initializing expressions when a non-reference, non-pointer is being initialized. So when ci is captured by value using this syntax, the copy inside f isn't const. (This assumes that the lambda is mutable, as it is here. For an explanation of why, I'll again refer you to Appearing and Disappearing consts in C++.)
So with C++14, we have two ways to capture a local variable by value: non-generalized and generalized. Non-generalized, which is valid in C++11 and C++14, retains the constness of the variable being captured in the type of the copy. Generalized, which is valid in C++14 only, discards the constness of the variable being captured in the type of the copy. To top things off, we have two syntaxes for non-generalized capture: implicit and explicit. Hence
the choices for capturing ci by value are: const int ci = 42;
auto f1 = [=]() mutable // non-generalized implicit copy
{ std::cout << ++ci << '\n'; }; // error! copy of ci in f is const
auto f2 = [ci]() mutable // non-generalized explicit copy
{ std::cout << ++ci << '\n'; }; // error! copy of ci in f is const
auto f3 = [ci = ci]() mutable // generalized copy
{ std::cout << ++ci << '\n'; }; // fine, copy of ci in f is non-const
Personally, I was never wild about the const retention in non-generalized captures, so I'm pleased that in C++14, there's a way to work around it.class ThreadRAII {
public:
ThreadRAII(std::thread&& thread): t(std::move(thread)) {}
~ThreadRAII() { if (t.joinable()) (t.join(); }
private:
std::thread t;
};
Using an RAII class to make sure that a std::thread object is brought into an unjoinable state on every path out of a block seems like an obviously-reasonable thing to do.std::promise<void> p;
std::thread t([&p]{ p.get_future().wait(); // start t and suspend it
funcToRun(); } // (conceptually)
);
... // t is "suspended" waiting for p to be set
p.set_value(); // t may now continue
This isn't the only way to suspend thread execution after creation of the thread and before execution of the work it's supposed to do, but it seems reasonable. In contrast to having the lambda spin on an atomic bool waiting for the flag to be set, for example, there is no need for the lambda to poll.std::promise<void> p; // as before
std::thread t([&p]{ p.get_future().wait(); // as before
funcToRun(); }
);
ThreadRAII tr(std::move(t)); // USE RAII CLASS HERE
... // as before
p.set_value(); // as before
The problem is that if an exception is thrown in the "...", we'll never set the value of the std::promise, and that means that the destructor of the RAII object (tr) will block forever. That's no better than program termination, and it might be worse.
In 1999, Addison-Wesley and I collaborated on a CD version of two of my books, Effective C++, Second Edition and More Effective C++. The CD was designed for contemporary browsers--contemporary to 1999. That was a time of rapid browser evolution, and it wasn't too long before browsers "progressed" to the point where the CD content didn't display correctly.According to the banner at the top of the page, the deal also includes free ground shipping within the USA. To get the discounts, you have to enter the magic promotion code CPLUSPLUS at checkout.Please feel free to point folks to informit.com/cplusplus which features a Buy 1 Save 30% | Buy 2 or More Save 40% discount code for all C++ titles. Note, while only the most recent C++ titles are featured on the landing page, the discount code applies to ALL titles (there is a giant "Shop all C++ Titles" button at the bottom of the page and folks can search for your products by your last name).
An Effective C++11/14 Sampler
After years of intensive study (first of C++0x, then of C++11, and most recently of C++14), Scott thinks he finally has a clue. About the effective use of C++11, that is (including C++14 revisions). At last year’s GoingNative, Herb Sutter predicted that Scott would produce a new version of Effective C++ in the 2013-14 time frame, and Scott’s working on proving him almost right. Rather than revise Effective C++, Scott decided to write a new book that focuses exclusively on C++11/14: on the things the experts almost always do (or almost always avoid doing) to produce clear, efficient, effective code. In this presentation, Scott will present a taste of the Items he expects to include in Effective C++11/14. If all goes as planned, he’ll also solicit your help in choosing a cover for the book.
auto parameters).i.e., auto return types).i.e., std::shared_mutex and std::shared_lock).auto type deduction.decltype.auto type deduction are the same as the rules for template type deduction, except that given a braced initializer such as { 1, 2, 3, 4 }, auto will deduce a std::initializer list type (in the case of { 1, 2, 3, 4 }, it will be std::initializer_list<int>), while template type deduction will fail. (I have no idea why type deduction for auto and for templates is not identical. If you know, please tell me!) The rules for decltype are more complicated, because they don't just distinguish between lvalues and rvalues, they also distinguish between id-expressions (i.e., expressions consisting only of identifiers, e.g., variable or parameter names) and non-id-expressions. For details on all these rules, consult this article by Thomas Becker, this article by me, or this article by Herb Sutter (for auto) and this one by Andrew Koenig (for decltype).decltype(auto). This feature leads to two questions, only the first of which is rhetorical:decltype(auto), which type deduction rules are to be followed: those for auto or those for decltype? Or does decltype(auto) have its own set of type deduction rules?decltype(auto)uses the decltype type deduction rules. The reason is that the type deduced by auto for an initializing expression strips the ref-qualifiers (i.e., lvalue references and rvalue references) and top-level cv-qualifiers (i.e., consts and volatiles) from the expression, but decltype does not. As a result, if you want the ref- and cv-qualifier stripping behavior, you can just write auto. If you don't, C++14 gives you the option of writing decltype(auto).decltype(longAndComplexInitializingExpression) var = longAndComplexInitializingExpression; // C++11 decltype(auto) var = longAndComplexInitializingExpression; // C++14For
auto function return types (another new C++14 feature), it's even more convenient. Consider a function template, grab, that authenticates a user and, assuming authentication doesn't throw, returns the result of indexing into some container-like object. Bearing in mind that some standard containers return lvalue references from their operator[] operations (e.g., std::vector, std::deque), while others return proxy objects (e.g., std::vector<bool>), and I believe it would be valid to define a container such that invoking operator[] on an rvalue would yield an rvalue reference, the proper "generic" way to declare this function in C++11 would be (I think):template<typename ContainerType, typename IndexType> //C++11
auto grab(ContainerType&& container, IndexType&& index) ->
decltype(std::forward<ContainerType>(container)[std::forward<IndexType>(index)]);
{
authenticateUser();
return std::forward<ContainerType>(container)[std::forward<IndexType>(index)];
}
In C++14, I believe this can be simplified to the following, thanks to function return type deduction and decltype(auto):
template<typename ContainerType, typename IndexType> // C++14
decltype(auto) grab(ContainerType&& container, IndexType&& index)
{
authenticateUser();
return std::forward<ContainerType>(container)[std::forward<IndexType>(index)];
}
Scott
The Universal Reference/Overloading Collision Conundrum
To help address the confusion that arises when rvalue references become lvalue references through reference collapsing, Scott Meyers introduced the notion of “universal references.” In this presentation, he builds on this foundation by explaining that overloading functions on rvalue references is sensible and useful, while seemingly similar overloading on universal references yields confusing, unhelpful behavior. But what do you do when you want to write a perfect forwarding function (which requires universal references), yet you want to customize its behavior for certain types? If overloading is off the table, what’s on? In this talk, Scott surveys a variety of options.
Though Scott will give a one-slide overview of the idea behind universal references at the beginning of the presentation, attendees are encouraged to familiarize themselves with the notion in more detail prior to the talk. Links to written and video introductions to universal references are available here.For time, location, and other details, consult the talk announcement.
For time and location, consult the talk announcement.Lambdas vs. std::bind in C++11 and C++14
C++ developers have long had a need to bind functions and arguments together for a later call. This is what makes it possible to invoke member functions on objects inside STL algorithms. The same technology can be used to create custom callback functions and to adapt function interfaces to different calling contexts.
In C++98, such binding was accomplished via std::bind1st and std::bind2nd. TR1 added std::tr1::bind, which was promoted to std::bind in C++11. But C++11 also introduced lambda expressions, and they’re slated to become even more powerful in C++14. That means that there are now two mechanisms in C++ for binding functions to arguments for later calls: std::bind and lambda expressions.In this talk, Scott examines the pros and cons of each approach, comparing them in terms of expressiveness, clarity, and efficiency, and he comes to the conclusion that one should almost always be used instead of the other. But which one?
This presentation assumes a basic familiarity with std::bind and C++11 lambda expressions.
I'm pleased to report that a new member of my Effective Software Development Series, Matt Galloway's Effective Objective-C 2.0, has just been published.
auto f = [&](int x, int y) { return fudgeFactor * (x + y); };
f was the closure, but it's not. f is a copy of the closure. The process of copying the closure into f may be optimized into a move (whether it is depends on the types captured by the lambda), but that doesn't change the fact that f itself is not the closure. The actual closure object is a temporary that's typically destroyed at the end of the statement. auto&& rrefToClosure = [&](int x, int y) { return fudgeFactor * (x + y); };
const will also work: const auto& lrefToConstToClosure = [&](int x, int y) { return fudgeFactor * (x + y); };std::move vs. std::forward, I explained that when you call std::forward, the expectation is that you'll pass a type consistent with the rules for template type deduction, meaning (1) an lvalue reference type for lvalues and (2) a non-reference type for rvalues. I added,
If you decide to be a smart aleck and write [code passing an rvalue reference type], the reference-collapsing rules will see that you get the same behavior as [you would passing a non-reference type]
Well. As I said, the joke seems to be on me, because the standardization commitee apparently consists largely of smart alecks.f:auto forwardingLambda = [](auto&& param) { /* perfect-forward param to f */ };
Writing the perfect-forwarding call is easy, but it's probably not obvious how. The normal way to perfect-forward something it to use std::forward, so we'd expect to write essentially this: auto forwardingLambda = [](auto&& param) { f(std::forward<T>(param)); };
But, uh oh, there's no T to pass to std::forward. (In the class generated from the lambda expression, there is, but inside the lambda itself, there's no type for param.) So what do we pass to std::forward? We can hardly pass auto. (Consider what would happen if we had a lambda taking multiple parameters, each of type auto and each of which we wanted to forward. In that case, each std::forward<auto> would be ambiguous: which auto should std::forward use?)auto in lambdas are the same as for templates. This means that if an lvalue argument is passed to the lambda, param's type will be an lvalue reference--exactly what we need for std::forward. If an rvalue argument is passed, its type will be an rvalue reference. For such parameters, we can recover the type to pass to std::forward by stripping it of its reference-ness. We could thus write forwardingLambda like this:auto forwardingLambda = [](auto&& param) {
f(std::forward<std::conditional<std::is_rvalue_reference<decltype(param)>::value,
std::remove_reference<decltype(param)>::type,
decltype(param)>::type>(param));
};
At least I think we could. I don't have a C++14 compiler to try it with, and, anyway, it's too gross to waste time on. It would be sad, indeed, if this is what the standardization committee expected us to do to effect perfect forwarding inside its spiffy new C++14 lambdas. Fortunately, it doesn't.
If you decide to be a smart aleck and write [code passing an rvalue reference type to std::forward], the reference-collapsing rules will see that you get the same behavior as [you would passing a non-reference type]
That means that if param's type is an rvalue reference, there is no need to strip off its reference-ocity. Instead, you can smart aleck your way to success by simply passing that type directly to std::forward. Like so: auto forwardingLambda = [](auto&& param) { f(std::forward<decltype(param)>(param)); };
Frankly, this is more verbose than I'd prefer. One could imagine a world where you could say something like this:auto forwardingLambda =
[](<T1>&& param1, <T2>&& param2) { f(std::forward<T1>(param1), std::forward<T2>(param2)); };
But that's not the world we live in, and given that C++14 gives us polymorphic lambdas, variadic lambdas, and move-enabled lambdas, I'm not going to complain about the world of C++14 lambdas. Except possibly to Herb :-) std::async that are special, it's the shared state they refer to that is. In the comments that followed that post, it was pointed out that this could change in C++14, but the proposal to that effect was rejected at the standardization committee meeting last month. As Anthony Williams put it in his blog post,Herb Sutter's late paper on the behaviour of the destructor ofstd::future(N3630) was up next. This is a highly conterversial topic, and yielded much discussion. The crux of the matter is that as currently specified the destructor ofstd::futureblocks if it came from an invocation ofstd::async, the asynchronous function was run on a separate thread (with thestd::launch::asyncpolicy), and that thread has not yet finished.
[...]
Much of the discussion focused on the potential for breaking existing code, and ways of preventing this. The proposal eventually morphed into a new paper (N3637) which created 2 new types of future:C++14 now has CD ("committee draft") status, but that doesn't mean things can't change. A member of the committee emailed me as follows:waiting_futureandshared_waiting_future.std::asyncwould then be changed to return awaiting_futureinstead of afuture. Existing code that compiled unchanged would then keep the existing behaviour; code that changed behaviour would fail to compile. Though the change required to get the desired behaviour would not be extensive, the feeling in the full committee was that this breakage would be too extensive, and the paper was also voted down in full committee.
[The] paper on changing [the behavior of futures referring to shared state from std::async] was rejected, after a LOT of discussion. The discussion has continued on the reflector, and we may get a NB comment on the C++14 draft about it, but for now there is no change.
My impression is that many committee-watchers had considered a change in the specification for std::async to be a sure thing, but, as I wrote in yet another blog post, the committee tends to be quite conservative about the possibility of breaking existing code. At this point, that looks to be the line they're going to follow as regards the behavior of (the shared state corresponding to) futures produced by std::async.void doSomeWork();
void f1()
{
std::thread t(doSomeWork);
... // no join, no detach
}
What happens?void f2()
{
auto fut = std::async(std::launch::async, doSomeWork);
... // no get, no wait
}
Now what happens?void f3()
{
std::packaged_task<void()> pt(doSomeWork);
auto fut = pt.get_future();
std::thread(std::move(pt)).detach();
... // no get, no wait
}
Now what happens?void f()
{
std::future<void> fut = std::async(std::launch::async,
[] { /* compute, compute, compute */ });
} // block here until thread spawned by
// std::async completes
Only std::futures returned from std::async behave this way, so I had been under the impression that they were special. But now I believe otherwise. I now believe that all futures must behave the same way, regardless of whether they originated in std::async. This does not mean that all futures must block in their destructors. The story is more nuanced than that.The thread object [for the function to be run asynchronously] is stored in the shared state and affects the behavior of any asynchronous return objects [e.g., futures] that reference that state.and in 30.6.8/5, where we read:
the thread completion [for the function run asynchronously] synchronizes with [i.e., occurs before] [1] the return from the first function that successfully detects the ready status of the shared state or [2] with the return from the last function that releases the shared state, whichever happens first.It's provision [2] that's relevant to us here. It tells us that if a future holds the last reference to the shared state corresponding to a call to std::async, that future's destructor must block until the thread for the asynchronously running function finishes. This is a requirement for any future object. There is nothing special about std::futures returned from std::async. Rather, the specialness of std::async is manifested in its shared state.
