book

Effective Modern C++

by Scott Meyers

November 2014

Intermediate to advanced

336 pages

9h 37m

English

O'Reilly Media, Inc.

Read now

Unlock full access

Using Code ExamplesSafari® Books OnlineHow to Contact Us
Terminology and ConventionsReporting Bugs and Suggesting Improvements
Item 1: Understand template type deduction.Case 1: ParamType is a Reference or Pointer, but not a Universal ReferenceCase 2: ParamType is a Universal ReferenceCase 3: ParamType is Neither a Pointer nor a ReferenceArray ArgumentsFunction ArgumentsItem 2: Understand auto type deduction.Item 3: Understand decltype.Item 4: Know how to view deduced types.IDE EditorsCompiler DiagnosticsRuntime Output
Item 5: Prefer auto to explicit type declarations.Item 6: Use the explicitly typed initializer idiom when auto deduces undesired types.
Item 7: Distinguish between () 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: Declare functions noexcept if they won’t emit exceptions.Item 15: Use constexpr whenever possible.Item 16: Make const member functions thread safe.Item 17: Understand special member function generation.
Item 18: Use std::unique_ptr for exclusive-ownership resource management.Item 19: Use std::shared_ptr for shared-ownership resource management.Item 20: Use std::weak_ptr for std::shared_ptr-like pointers that can dangle.Item 21: Prefer std::make_unique and std::make_shared to direct use of new.Item 22: When using the Pimpl Idiom, define special member functions in the implementation file.
Item 23: Understand std::move and std::forward.Item 24: Distinguish universal references from rvalue references.Item 25: Use std::move on rvalue references, std::forward on universal references.Item 26: Avoid overloading on universal references.Item 27: Familiarize yourself with alternatives to overloading on universal references.Abandon overloadingPass by const T&Pass by valueUse Tag dispatchConstraining templates that take universal referencesTrade-offsItem 28: Understand reference collapsing.Item 29: Assume that move operations are not present, not cheap, and not used.Item 30: Familiarize yourself with perfect forwarding failure cases.Braced initializers0 or NULL as null pointersDeclaration-only integral static const and constexpr data membersOverloaded function names and template namesBitfieldsUpshot
Item 31: Avoid default capture modes.Item 32: Use init capture to move objects into closures.Item 33: Use decltype on auto&& parameters to std::forward them.Item 34: Prefer lambdas to std::bind.

Item 35: Prefer task-based programming to thread-based.Item 36: Specify std::launch::async if asynchronicity is essential.Item 37: Make std::threads unjoinable on all paths.Item 38: Be aware of varying thread handle destructor behavior.Item 39: Consider void futures for one-shot event communication.Item 40: Use std::atomic for concurrency, volatile for special memory.
Item 41: Consider pass by value for copyable parameters that are cheap to move and always copied.Item 42: Consider emplacement instead of insertion.

Content preview from Effective Modern C++

Chapter 4. Smart Pointers

Poets and songwriters have a thing about love. And sometimes about counting. Occasionally both. Inspired by the rather different takes on love and counting by Elizabeth Barrett Browning (“How do I love thee? Let me count the ways.”) and Paul Simon (“There must be 50 ways to leave your lover.”), we might try to enumerate the reasons why a raw pointer is hard to love:

Its declaration doesn’t indicate whether it points to a single object or to an array.
Its declaration reveals nothing about whether you should destroy what it points to when you’re done using it, i.e., if the pointer owns the thing it points to.
If you determine that you should destroy what the pointer points to, there’s no way to tell how. Should you use delete, or is there a different destruction mechanism (e.g., a dedicated destruction function the pointer should be passed to)?
If you manage to find out that delete is the way to go, Reason 1 means it may not be possible to know whether to use the single-object form (“delete”) or the array form (“delete []”). If you use the wrong form, results are undefined.
Assuming you ascertain that the pointer owns what it points to and you discover how to destroy it, it’s difficult to ensure that you perform the destruction exactly once along every path in your code (including those due to exceptions). Missing a path leads to resource leaks, and doing the destruction more than once leads to undefined behavior.
There’s typically no way to ...