Scott Meyers - Effective Modern C++

Distributed in lowland rainforests in eastern Australia, monsoon forests in northern Australia, and the Lesser Sunda Islands and Maluku Islands of Indonesia, the Rose- crowned fruit dove's diet consists of various fruits like figs (which it swallows whole), palms, and vines. Camphor Laurel, a large evergreen tree, is another food source for the fruit dove. They feed — in pairs, small parties, or singly — in rainforest canopies, usually in the morning or late afternoon. To hydrate, they get water from leaves or dew, not from the ground.

The fruit dove is considered vulnerable in New South Wales due to rainforest clearing and fragmentation, logging, weeds, fire regime-altered habitats, and the removal of Laurel Camphor without adequate alternatives.

Many of the animals on O'Reilly covers are endangered; all of them are important to the world. To learn more about how you can help, go to animals.oreilly.com.

The cover image is from Wood's Illustrated Natural History, bird volume. The cover fonts are URW Typewriter and Guardian Sans. The text font is Adobe Minion Pro; the heading font is Adobe Myriad Condensed; and the code font is Dalton Maag's Ubuntu Mono.

More flexible designs — ones that permit callers to determine whether parentheses or braces should be used in functions generated from a template — are possible. For details, see the 5 June 2013 entry of Andrzej's C++ blog , “ Intuitive interface — Part I .”

Applying finalto a virtual function prevents the function from being overridden in derived classes. finalmay also be applied to a class, in which case the class is prohibited from being used as a base class.

The checking is typically rather roundabout. Functions like std::vector::push_backcall std::move_if_noexcept, a variation of std::movethat conditionally casts to an rvalue (see Item 23), depending on whether the type's move constructor is noexcept. In turn, std::move_if_noexceptconsults std::is_nothrow_move_constructible, and the value of this type trait (see Item 9) is set by compilers, based on whether the move constructor has a noexcept(or throw()) designation.

The interface specifications for move operations on containers in the Standard Library lack noexcept. However, implementers are permitted to strengthen exception specifications for Standard Library functions, and, in practice, it is common for at least some container move operations to be declared noexcept. That practice exemplifies this Item's advice. Having found that it's possible to write container move operations such that exceptions aren't thrown, implementers often declare the operations noexcept, even though the Standard does not require them to do so.

“Regardless of the state of the program” and “no constraints” doesn't legitimize programs whose behavior is already undefined. For example, std::vector::sizehas a wide contract, but that doesn't require that it behave reasonably if you invoke it on a random chunk of memory that you've cast to a std::vector. The result of the cast is undefined, so there are no behavioral guarantees for the program containing the cast.

Because Point::xValuereturns double, the type of mid.xValue() * 10is also double. Floating-point types can't be used to instantiate templates or to specify enumerator values, but they can be used as part of larger expressions that yield integral types. For example, static_cast(mid.xValue() * 10)could be used to instantiate a template or to specify an enumerator value.

There are a few exceptions to this rule. Most stem from abnormal program termination. If an exception propagates out of a thread's primary function (e.g., main, for the program's initial thread) or if a noexceptspecification is violated (see Item 14), local objects may not be destroyed, and if std::abortor an exit function (i.e., std::_Exit, std::exit, or std::quick_exit) is called, they definitely won't be.

This implementation is not required by the Standard, but every Standard Library implementation I'm familiar with employs it.

To create a full-featured make_uniquewith the smallest effort possible, search for the standardization document that gave rise to it, then copy the implementation you'll find there. The document you want is N3656 by Stephan T. Lavavej, dated 2013-04-18.

In practice, the value of the weak count isn't always equal to the number of std::weak_ptrs referring to the control block, because library implementers have found ways to slip additional information into the weak count that facilitate better code generation. For purposes of this Item, we'll ignore this and assume that the weak count's value is the number of std::weak_ptrs referring to the control block.

Item 25explains that universal references should almost always have std::forwardapplied to them, and as this book goes to press, some members of the C++ community have started referring to universal references as forwarding references .

Eligible local objects include most local variables (such as winside makeWidget) as well as temporary objects created as part of a returnstatement. Function parameters don't qualify. Some people draw a distinction between application of the RVO to named and unnamed (i.e., temporary) local objects, limiting the term RVO to unnamed objects and calling its application to named objects the named return value optimization (NRVO).

This assumes that bitfields are laid out lsb (least significant bit) to msb (most significant bit). C++ doesn't guarantee that, but compilers often provide a mechanism that allows programmers to control bitfield layout.

std::bindalways copies its arguments, but callers can achieve the effect of having an argument stored by reference by applying std::refto it. The result of

auto compressRateB = std::bind(compress, std::ref(w ), _1);

is that compressRateBacts as if it holds a reference to w, rather than a copy.

Assuming you have one. Some embedded systems don't.

This is a simplification. What matters isn't the future on which getor waitis invoked, it's the shared state to which the future refers. ( Item 38discusses the relationship between futures and shared states.) Because std::futures support moving and can also be used to construct std::shared_futures, and because std::shared_futures can be copied, the future object referring to the shared state arising from the call to std::asyncto which f was passed is likely to be different from the one returned by std::async. That's a mouthful, however, so it's common to fudge the truth and simply talk about invoking getor waiton the future returned from std::async.