Scott Meyers

Modification History and Errata List for Effective Modern C++

Last Updated 20 March 2022
by Scott Meyers

What follows are my notes on what I've changed in Effective Modern C++ since its official publication in November 2014 (i.e., excluding "Early Release" and "Rough Cuts" versions) and what I believe may need to be changed in the future. Most of the changes (or prospective changes) are cosmetic and don't affect the technical content of the book. Entries that do affect technical material are preceded with an exclamation mark ("!") and are displayed in red.

Each entry includes the following information:

I am always interested in bug reports and suggestions for improvements to Effective Modern C++. To submit comments, send email to emc++@aristeia.com.

The following issues have been addressed in published versions of the book:

    DATE                                                                                        DATE
  REPORTED WHO PLATFORM LOCATION  WHAT                                                          FIXED
  -------- --- -------- --------  ----------------------------------------------------------  --------
   1/13/15 sdm Digital  Metadata  Digital TOCs should included a link to the book's            4/ 2/15
                                  copyright page.

  12/ 7/14 kxh ePub on  Metadata  Author is shown as "(Unknown author)".                       3/31/15
               Marvin

  12/16/14 rxk All      All       When words in code font are broken across lines, they're     5/19/15
           sdm                    not hyphenated.

  11/18/14 sdm Kindle   All       Font size in code displays should be increased to match      1/20/15
                                  size in the rest of the book. 

  11/18/14 lxs Kindle   All       Inter-paragraph spacing should be increased.                 1/20/15

  11/28/14 kxa Kindle   All       Highlighted code text (i.e., red and/or italicized) is       4/14/15
   1/ 7/15 bxy on                 invisible. Wide and narrow ellipses are swapped. 
               Nexus              (Problems reported on Nexus 4, 5, 7, and 10.)

  11/18/14 sdm PDF      vii       Item title for Item 8 is incorrectly indented.               1/20/15

   4/17/15 sdm PDF      xiv       Twice in first para, bad line break between day and month    5/ 8/15
                                  in a date.

   4/17/15 sdm PDF      xiv       Near end of first para, sentence-ending period should        5/ 8/15
                                  precede the parenthesis, not follow it.

   4/17/15 sdm PDF      xiv       Add tyk for performing an extraordinarily thorough           1/25/16
                                  post-publication review of the book.

   1/ 9/16 sdm PDF      xv        Ashley Morgan Williams ==> Ashley Morgan Long                1/25/16
                        310
                        315

  11/15/14 kxv PDF      xv        "reviwing" ==> "reviewing"                                   1/20/15

  11/21/14 sdm Safari   5         In last line of first code display, final parenthesis in     3/31/15
               Online             comment wraps to next line.

!  1/30/15 txk PDF      12        The third paragraph (beginning with "These examples all      3/24/15
                                  show lvalue reference  parameters, but type deduction
                                  works exactly the same way for rvalue reference
                                  parameters") should be removed. When the type of param
                                  in the template f on page 11 is changed to an rvalue
                                  reference (i.e., to have type "T&&"), it becomes a
                                  universal reference, and then the rules for Case 2
                                  (on pages 13-14) apply. 

  11/22/14 sdm PDF      21-22     In November 2014, N3922 was adopted for draft C++17.         3/25/15
                                  With this change to the language, it is no longer the 
                                  case that the following two statements do the same thing: 

                                    auto x3 = { 27 };
                                    auto x4{ 27 };

                                  Under N3922, x4 is of type int, not
                                  std::initializer_list<int>. Some compilers have
                                  already implemented this prospective language change.
                                  I added a footnote to this effect.

   3/18/16 gxk PDF      21        In the footnote added to resolve an earlier erratum,         1/ 5/17
                                  remove the cross reference to Item 42.

  12/19/16 sdm PDF      21        In footnote, "some compilers" => "many compilers".           1/ 5/17

   3/26/15 sdm PDF      24        In first line, "Occasionally" should be followed by a        3/26/15
                                  comma.

   2/ 9/15 tyk PDF      24        Clarify that in authAndAccess, we're interested only in      1/25/16
                        28        supporting containers taking numeric index values. 
                                  (This excludes std::map and std::unordered_map, which 
                                  take indices of arbitrary types).

  12/13/14 rxm PDF      25        I should mention that for functions with deduced return      3/25/15
                                  types, if there is more than one return statement, all
                                  return statements must yield the same deduced type.

   3/27/15 sdm PDF      26-27     Bad page break between the comment and the code it applies   3/30/15
                                  to. 

   1/22/16 sdm PDF      28        Improper indentation of "-> decltype(...)".                  1/25/16

   2/ 2/15 mxw PDF      28        Reworded last para on page to reflect that not all names     3/25/15
                                  are lvalues. Also added weasel wording regarding "lvalue
                                  expressions more complicated than names" to try to avoid
                                  contradicting 7.1.6.2/4 bullet 1 without getting sucked
                                  into the details.

   2/17/15 mam PDF      31        When attempting to instantiate an undefined template,        3/24/15
                                  Intel C++ 15.0.2 on Linux issues a diagnostic that
                                  fails to mention the type being used for the
                                  instantiation.

   1/ 6/16 sdm PDF      31        Too much blank space above first code example.               1/25/16

  12/ 1/14 daa PDF      33        "the type that all three compilers report for param are" ==> 1/20/15
                                  "the type that all three compilers report for param is"   

  11/21/14 sdm PDF      34        "neither are IDEs or templates" ==>                          1/20/15
                                  "neither are IDEs nor templates"

  11/17/14 txk PDF      34        Boost's web site is boost.org, not boost.com.                1/20/15

  11/23/14 bbs PDF      37-38     In the dwim functions, it would be more ideomatic to use a   3/25/15
                                  for loop instead of a while loop.

   2/ 8/15 mxm PDF      38        In comment next to initialization of x3,                     3/24/15
                                  "x's value is well-defined" ==> "x3's value is well-defined"

   1/ 6/17 sxa PDF      41        In last para, xref to Items 2 and 6 should include Item 3,   5/18/18
                                  too. 

   2/ 8/17 sdm PDF      41        At beginning of 4th line of second para, "const" should be   1/ 5/17
                                  italicized, i.e., it should start with 
                                  "<const std::string, int>". (This error exists only in the
                                  PDF and printed versions of the book and only in the 
                                  8th-10th printings. Kindle and epub versions of the book
                                  don't have this mistake, nor do earlier versions in PDF
                                  and print.) 

   1/ 6/17 sxa PDF      45        At end of 2nd para, "Pantheon" => "pantheon".                5/18/18

   1/25/15 txk PDF      47        In comment of penultimate code block,                        3/24/15
                                  "impliclitly" ==> "implicitly".

  11/23/14 bbs PDF      47-48     In last para, I should make explicit my assumption that      3/30/15
                                  the container isn't empty. 

! 11/23/14 bbs PDF      48        Twice on page, "d * c.size()" ==> "d * (c.size() - 1)".      1/20/15

!  3/26/15 lxz PDF      48        The 1/20/15 fix for the code on this page resolved the       4/ 3/15
                                  problem (present in early printings of the book) that when
                                  d==1.0, index would be c.size(), hence out of
                                  bounds. Unfortunately, it also resulted in index being
                                  c.size()-1 (the last element of the container) only when
                                  d==1.0. 

   2/18/15 vhg PDF      51        In second paragraph, I say that narrowing conversions        3/24/15
                                  using braced initializers won't compile, but the
                                  Standard requires only that compilers issue some kind of
                                  diagnostic message. A warning fulfills this requirement,
                                  and some compilers issue only warnings for at least some
                                  narrowing conversions using braced initializers. 

  12/19/16 sdm PDF      54-55     First line of page 55 should be moved to page 54 to keep     1/ 5/17
                                  the comment together.

! 11/20/16 cxl PDF      55        Comment on last line on page is incorrect: the               1/ 5/17
                        314       constructor for w5 is called with a one-element
                                  std::initializer_list, not an empty one.  For details,
                                  consult this blog post.

   2/12/15 sdm PDF      58        Formatting of Item title is incorrect: too much space        3/24/15
                                  after the colon.

  12/21/14 tjb PDF      61        lockAndCall implementations should include this line at      1/20/15
                                  the beginning:  

                                    using MuxGuard = std::lock_guard<MuxType>;
 
   4/21/16 gxp PDF      71        2nd para suggests that it's possible to specify the          1/ 5/17
                                  underlying type only for unscoped enums. Reword.

   2/23/15 mxk PDF      77        In next-to-last para, wchar_t, char16_t, and char32_t        3/24/15
                                  are keywords, hence should not be std::-qualified.

   7/16/16 axd PDF      77        Penultimate para fails to mention volatile-only overloads    1/ 5/17
                                  (i.e., volatile void*, volatile char*).

  11/17/15 rxh PDF      81        Of the three compilers I use for my testing (gcc, MSVC,      1/25/16
           bxc                    Clang), only one (gcc) issues no warnings when full
           sdm                    warnings are enabled (i.e. -Wall -Wsuggest-override).

  11/12/16 hxb PDF      81-82     Derived::mf4 should be declared virtual.                     1/ 5/17

  11/23/14 bbs PDF      83-85     I should mention that if a member function is                3/26/15
                                  reference-qualified, any other overload of the same
                                  member function (i.e., matching name and parameter
                                  types) must also be reference-qualified.

  12/25/14 mxs PDF      85        A better way to have the rvalue reference overload of the    3/26/15
   1/27/15 tyk                    "data" member function return an rvalue is to have it
                                  return an rvalue reference. That would avoid the creation
                                  of a temporary object for the return value, and it would
                                  be consistent with the by-reference return of the original
                                  "data" interface near the top of page 84.

  11/12/16 hxb PDF      86        Missing space after first comma in page's first call to      1/ 5/17
                        88        std::find.

   1/22/16 sdm PDF      88        Missing spaces around "->" in return type for cbegin         1/25/16
                                  at bottom of page.

   1/22/16 sdm PDF      89        In first para, incorrect font for final "r" in               1/25/16
                                  "const_iterator".

   1/ 4/15 jxz All      PDF       At end of sentence before code display, space between        1/20/15
                        pg 95     "seems" and "appropriate" is too wide. In ePub version,
                                  there are two spaces, but in PDF and Mobi versions,
                                  there's a single overly-wide space.

   1/18/15 bbs PDF      99-100    In pow, exp should be declared unsigned, because the         1/25/16
                                  algorithm works only for non-negative exponents.

! 12/24/14 akb PDF      105       Neither std::mutex nor std::atomics are move-only. They      3/25/15
                        106       are neither copyable nor movable, so classes containing
                        108       them are rendered both uncopyable and unmovable. 

  11/14/16 sdm PDF      105       In antipenultimate line on page (i.e., 3rd-to-last line—     1/ 5/17
                                  I just wanted to use the word "antipenultimate" :-}),
                                  "i.e," => "i.e.,".

   1/ 4/15 jxz PDF      106       It would be better to use std::hypot to compute the          3/25/15
                                  distance from the origin, because (1) std::hypot does
                                  exactly what's needed and is part of the standard
                                  library and (2) as this blog post explains, it handles
                                  potential overflow values much better than the code shown
                                  in the book. 

  12/12/14 bxr PDF      107       "CacheValid" ==> "cacheValid".                               1/20/15

! 12/12/14 bxr PDF      107       The text above the code display near the middle of the       1/20/15
                                  page says that reversing the order of the assignments
                                  solves the problem, but that's incorrect. Multiple threads
                                  could still perform the expensive calculations before
                                  cacheValid is set.

   8/31/16 txb PDF      112       In antipenultimate line (see above) of paragraph above       1/ 5/17
                                  first code display, "i.e," => "i.e.,". 

   3/25/15 gxs PDF      115       At end of second bullet in "Things to Remember,"             3/25/15
                                  "and a destructor" ==> "or a destructor".

   1/24/17 djm PDF      115       Reword last sentence of bullet at top of page to improve     5/18/18
                                  clarity. Also undo 3/25/15 change suggested by gxs,
                                  i.e., at end of second bullet in "Things to Remember," 
                                  "or a destructor" ==> "and a destructor".

   3/ 6/17 djm PDF      115       In last sentence of third bullet in box, "with an            5/18/18
                                  explicitly declared destructor" ==> "with an explicitly
                                  declared copy operation or destructor".

   6/ 2/15 lxz PDF      118       In fourth para, "it's not possible" ==> "it wasn't          10/21/15
                                  possible". (In C++11, std::auto_ptrs can be stored in 
                                  containers.)

   8/31/16 ryk PDF      118       "Item 17" in footer should be Item 18.                       1/ 5/17


   6/19/16 axd PDF      123       The book's claim that stateless function object deleters     1/ 5/17
                                  incur no size penalty is true in practice, but it's not
                                  guaranteed by the Standard. Reword. Be caseful to avoid
                                  implying that stateless function objects in general have
                                  no size.

   6/23/15 dgw ePub     119       In iBooks, the beginnings or endings of some sentences       6/30/15
                        124       are missing. (This is a systemic problem. The list of
                        127       affected pages is probably not complete.)
                        135
                        138       

   6/ 2/15 lxz PDF      128       Text near end of the first paragraph implies that the        1/25/16
                                  control block may not contain a weak count, but, as I note
                                  on page 144 (in Item 21), the weak count is always present.

  12/15/14 sdm PDF      129       "on page 115" ==> "on page 117".                             1/20/15

   1/18/15 bbs PDF      133       In first para, both copy- and move assignment can call for   1/25/16
                                  reference count manipulations, because the target of a
                                  move assignment must typically decrement the reference
                                  count of the control block it currently points to.

   6/10/17 tgm PDF      136       In line 7 of 2nd para, the final "s" in "std::weak_ptrs" is  5/18/18
                                  in wrong font.

   6/ 2/15 lxz PDF      139       Text in the second paragraph implies that std::make_unique   1/25/16
                                  supports custom deleters, but that is not the case.

  12/19/14 sdm PDF      151       Last line on page is indented too far.                       1/20/15

   1/29/15 tyk PDF      152-153   std::unique_ptr's move operations are noexcept, so           1/25/16
                                  Widget's should be, too. Compiler-generated versions would
                                  be noexcept automatically (see below), but user-declared
                                  versions must be explicitly declared noexcept.

   1/ 8/16 sdm PDF      153       In first para, clarify that compilers must be able to        1/25/16
                                  generate code to destroy pImpl in the event of an
                                  exception, even if the move constructor is noexcept. (The
                                  source of this requirement is 12.6.2/10 in C++14, though
                                  there's a proposal to relax it.) 

! 12/18/14 ahp PDF      154       The copy operations shown on this page unconditionally       3/26/15
                                  dereference pImpl, but an earlier move operation could
                                  have left pImpl null. The code should check for nullness
                                  and, if present, deal with it in a reasonable fashion.

  12/18/14 ahp PDF      155       Using compiler-generated copy and move operations for        3/26/15
                                  Widget containing a pImpl of type std::shared_ptr would
                                  replace the value semantics of the class (i.e., deep copy)
                                  with reference semantics (i.e., shallow copy).

  11/12/16 hxb PDF      158       "Item 22" in footer should be Item 23.                       1/ 5/17

   1/ 4/15 jxz PDF      160       Near top of page, declaration of Annotation constructor      1/20/15
                                  is missing terminating semicolon.

   1/ 6/16 nxj PDF      163       Add "Things to Remember" bullet about how declaring          1/25/16
                                  objects const disables move semantics for them.

  12/16/14 rxm PDF      168       In second line on page, "args is zero or more" ==>           1/20/15
                                  "params is zero or more".

   1/24/17 djm PDF      168       In last sentence before box, "general relativity" =>         5/18/18
                                  "Einstein's theory of relativity".

   2/11/15 mjs PDF      171       The last sentence of the second paragraph is misleading,     3/25/15
                                  because for setters that are passed the "wrong" type
                                  argument, the performance gap between (a) overloading on
                                  lvalues and rvalues and (b) pass-by-universal-reference
                                  is determined by several factors:
                                  - Cost of constructing a temporary object of the "right"
                                    type from the argument;
                                  - Cost of moving the temporary into the data member;
                                  - Cost of assigning the argument to the data member
                                    (which may incur the costs of a temporary
                                    construction and destruction).
                                  I eliminated the sentence.

   1/30/15 tyk PDF      171       Page should contain a cross reference to Item 41, which      1/25/16
                                  has a fuller discussion of the tradeoffs between the use
                                  of overloading and passing by universal reference.

   7/ 7/15 mys PDF      179       In 2nd-to-last para, the overload taking a universal         1/25/16
                                  reference would deduce T to be short&, not short, because
                                  logAndAdd is being called with an lvalue (nameIdx).

  12/15/14 sdm PDF      184       "on page 175" ==> "on page 177".                             1/20/15

  12/15/14 sdm PDF      185       "on page 177" ==> "on page 178".                             1/20/15

   4/15/15 sdm PDF      186       In first para, bad line break between "Item" and "26".       5/ 8/15

   4/15/15 sdm PDF      187       In first para, bad line break between "Item" and "9".        5/ 8/15

  12/15/14 sdm PDF      188       "on page 178" ==> "on page 180".                             1/20/15

  12/11/14 kxv PDF      192       "on page 206"==> "on page 183". Also, page number            1/20/15
                                  should be a link. 

   2/22/15 vhg PDF      192       Final paragraph says that std::is_base_of<T,T>::value is     3/24/15
                                  true, but that's the case only for class types. When T
                                  is a built in type such as int, std::is_base_of<T,T>::value
                                  is false. 

   4/ 6/15 sdm PDF      200       In first sentence, bad line break between "Item" and "9".    5/ 8/15

  12/19/14 ahp PDF      210       This section also applies to declaration-only integral       3/24/15
                                  static constexpr data members (i.e., to constexpr data
                                  members as well as const data members).

  11/12/16 hxb PDF      216       "Item 30" in footer should be Item 31.                       1/ 5/17

  12/17/14 rxm PDF      217       In first comment block, reference to Item 2 should be to     1/20/15
                                  Item 5. 

   6/28/15 bvw PDF      226       C++11 code examples on these pages use std::make_unique,     1/25/16
                        229       but std::make_unique is a C++14 feature, not C++11

   2/10/15 sxt PDF      Item 33   Inside the lambda, the call to func should be eliminated,    3/30/15
                                  because it plays no role in any of the examples.

  11/14/16 sdm PDF      230       In second-to-last line preceding the last code display,      1/ 5/17
                                  "i.e," => "i.e.,".

   2/10/15 sxt PDF      231-232   For consistency with the rest of the Item, the lambda        3/30/15
                                  parameter on page 231 should be named x, not param, and in
                                  the variadic version on page 232, it should be named xs,
                                  not params. 

   3/27/15 sdm PDF      232-233   Bad page break between the comment and the code it applies   3/30/15
                                  to. 

! 11/30/14 rxb PDF      234       The revised versions of setSoundB still invoke               1/20/15
                        235       steady_clock::now() when std::bind is called instead of
                        236       when the bind object is called. A proper fix requires
                                  nesting a third call to std::bind inside the second one,
                                  e.g., as follows for the C++14 version of the code:

                                    auto setSoundB =
                                      std::bind(setAlarm,
                                                std::bind(std::plus<>(), 
                                                          std::bind(steady_clock::now), 
                                                          1h),
                                                _1,
                                                30s);

!  5/ 5/15 mam PDF      235       With the code at the top of the page, calls to               1/25/16
                                  setSoundB won't compile, because
                                  std::plus<steady_clock::time_point>'s operator()
                                  declares two parameters of type steady_clock::time_point,
                                  but we're passing a time_point and a duration. 

                                  The fix is to essentially implement C++14's generic
                                  std::plus ourselves. Its templatized operator() function
                                  accepts arguments of any type. So:

                                    struct genericAdder {
                                      template<typename T1, typename T2>
                                      auto operator()(T1&& param1, T2&& param2)
                                        -> decltype(std::forward<T1>(param1) + std::forward<T2>(param2))
                                      {
                                        return std::forward<T1>(param1) + std::forward<T2>(param2);
                                      }
                                    };

                                    auto setSoundB =
                                      std::bind(setAlarm,
                                                std::bind(genericAdder(),
                                                          std::bind(steady_clock::now),
                                                          hours(1)),
                                                _1,
                                                seconds(30));

   3/ 9/16 jxm PDF      235       The lambda used to initialize setSoundL is missing the       1/ 5/17
                                  using directive for std::literals.

!  2/23/15 vhg PDF      239       Inside operator() for the closure boundPW, pw is const,      3/25/15
                                  because operator() is a const member function. However,
                                  PolyWidget::operator() is not const, so the call
                                  "pw(param)" attempts to invoke a non-const
                                  member function on a const object, and that's invalid.

   3/23/15 sdm PDF      241       In first paragraph,                                          3/24/15
                                  "compiler-writers" ==> "compiler writers".

   2/ 8/15 tyk PDF      241       Clarify that std::async isn't synonymous with "task-based    1/25/16
                                  programming," it's just an example of it.

   1/ 6/15 oxb PDF      247       In paragraph above final code block,                         1/20/15
                                  "std::launch::deferred" ==> "std::future_status::deferred"

   5/23/15 pxz Kindle   ~8526     The end of the paragraph beginning with "If f runs           6/30/15
                                  concurrently with the thread calling std::async (i.e., if
                                  the launch policy chosen for f is std::launch::async)" is
                                  not displayed. This problem was introduced in the
                                  2015-05-08 release, i.e., it did not exist in prior
                                  releases. 

   1/ 1/15 fxf PDF      251       In second comment block, reference to Item 2 should be to    1/20/15
                                  Item 5. 

   7/26/16 mtb PDF      251       Clarify that terminating "program execution" means all the   1/ 5/17
                                  threads, i.e., the entire process.

  11/19/14 dxj PDF      257       "isappropriate" ==> "is appropriate"                        12/12/14 (print and epub)
                                                                                               1/20/15 (PDF, mobi, and Safari)

   4/ 9/15 sdm PDF      269       Footnote should replace blog post reference with             1/25/16
                                  this followup blog post.

!  4/13/15 lxp PDF      270       Italicized comment opposite first "…" is incorrect.          1/25/16
                                  ThreadRAII isn't being used in this example, so an
                                  exception in this region would cause joinable std::threads
                                  to be destroyed, hence would lead to program termination.

   3/ 1/16 jsb PDF      271       2nd para of Item 40 says that "operations on [std::atomics]  1/ 5/17
                                  behave as if they were inside a mutex-protected critical 
                                  section." For std::atomics using sequential consistency,
                                  this is true, but for std::atomics using weaker
                                  consistency models, it's only partially true. Regardless
                                  of the consistency model, std::atomics appear to other
                                  threads to change values atomically, but std::atomics
                                  using weaker models permit some instruction reorderings
                                  that would not be permitted if mutexes were used. (As the
                                  footnote on page 274 implies, Effective Modern C++
                                  assumes the use of sequential consistency throughout the
                                  book.)

  11/12/16 hxb PDF      272       In 4th line from bottom "e.g," => "e.g.,".                   1/ 5/17

   6/19/16 axd PDF      273       Penultimate para suggests that compilers can detect data     1/ 5/17
                                  races and use the leeway from the resulting undefined
                                  behavior to generate code to do anything they like. This
                                  is misleading. Code generation occurs during compilation,
                                  but data races occur at runtime. Reword.

   7/17/15 sdm PDF      274       In 2nd line of footnote, "that use the syntax" ==>          10/21/15
                                  "that uses the syntax".

  12/15/14 sdm PDF      281       "Recall on page 2" ==> "Recall from page 4".                 1/20/15

   6/19/16 axd PDF      278       2nd para says "the code must be written like this", but      1/ 5/17
                                  that's not true. Instead of invoking
                                  std::atomic<int>::store on y, assignment can be used:

                                    y = x.load();           // same as y.store(x.load());

   1/11/15 pxv PDF      283       In final paragraph, "addName will be copy constructed" ==>   1/20/15
                                  "newName will be copy constructed".       

   1/23/15 kxv PDF      289       Near middle of page, saying "changeTo’s use of assignment    3/25/15
                        290       to copy the parameter newPwd probably causes that
                                  function’s pass-by-value strategy to explode in cost" is
                                  misleading. It suggests that the problem is that changeTo
                                  uses assignment, but that's how changeTo has to be
                                  implemented. The real problem is that changeTo uses pass
                                  by value for its parameter. At the bottom of the page, I
                                  show how using pass by reference-to-const eliminates the
                                  problem.  

   1/23/15 kxv PDF      292       In the "Things to Remember" box, the second bullet point     3/25/15
                                  is unclear and should be reworded. 

  11/24/14 sdm PDF      299       Line 6 is unnecessarily indented.                            1/20/15

  11/25/14 sdm PDF      300       In the text following first code fragment, the constraint    3/24/15
                                  on the pointer passed to the std::regex constructor is
                                  incorrect. It's that the pointer be non-null, not that it
                                  point to a valid regular expression. (Null pointers yield
                                  undefined behavior. Pointers pointing to invalid regular
                                  expressions yield exceptions.)

   8/ 3/15 sdm PDF      303       Allusion to "Adventure" should refer to page 292, not       10/21/15
                                  page 295.

   9/ 7/15 kyh PDF      308       In second column, entries for std::basic_ios::basic_ios     10/21/15
                                  and std::basic_ios::operator= should refer only to page
                                  75, not both 75 and 160.

   2/19/18 sdm PDF      310       In column 2, eliminate fourth line from bottom of page.      5/18/18

   6/19/16 sdm PDF      313       std::is_constructible should refer to page 196, not 195.     1/ 5/17

   1/ 8/15 bvw PDF      315       Bart Vandewoestyn ==> Bart Vandewoestyne                     1/20/15

The following changes have been proposed, but have not yet been published:

    DATE
  REPORTED WHO PLATFORM LOCATION  WHAT
  -------- --- -------- --------  ----------------------------------------------------------
   3/ 2/21 rtc PDF        4       In comment in last code example, "SomeFunc" ==> "someFunc".

   6/17/20 dxr PDF       11       In Step 1 in the middle of the page, not only should the
                                  reference part of expr's type be ignored (if it exists), 
                                  but the reference part of ParamType should also be ignored
                                  (if it exists).

!  9/27/19 kst PDF       21       C++98 permits scalar types to be initialized using the 
                                  "type var = { value };" syntax, so the initialization of
                                  x3 near the top of the page is valid in C++98. What C++11
                                  did was extend this initialization syntax to non-scalar
                                  types.

   3/20/22 ayk PDF       57       In last code fragment on page, variable v is never used.

  12/24/18 dxk PDF       77       Text on these pages refers to deleting instantiations or 
                         79       declaring them private, but it's actually the template
                                  specializations that are deleted or declared private, not
                                  the template instantiations.

  12/ 6/21 mxh PDF       86       In first para, "what the iterator points to" ==> "the data 
                                  the iterator points to", and in the para after the first 
                                  code example, "what an iterator points to" ==> "the data
                                  an iterator points to".                                

   4/ 9/19 fxr PDF       96       In middle para on page, the statement that functions in the
                                  C++ Standard Library inherited from C are not declared
                                  noexcept is true, but 17.6.5.12/3 of the C++11 and C++14
                                  Standards makes clear that implementations should treat
                                  them as if they were.                                  

   5/12/20 dyg PDF      163       In last para in Item, "only for references" ==> "only for
                                  universal references".

   3/12/19 gpk PDF      194       For consistency with the original code on page 180, remove
                                  the "…" from both constructor bodies on this page.

   5/10/19 dxk PDF      214       The second "Things to Remember" bullet should include
                                  declaration-only integral constexpr data members.

  12/17/19 jxr PDF      219       In sentence above last code display, there's an extra space
                                  between "container" and "of".

    9/8/20 dxt PDF      288       Lines 6-7 of the first para say that newName is copy-constructed
                                  into the names vector, but it'd actually be move-constructed.

   2/20/19 dxk PDF      314       In first column, add page 294 to entry for
                                  std::vector::emplace_back.

What follows are interesting comments about the material in Effective Modern C++, but I don't expect to be able to modify the book to take these comments into account until (if ever) I write a second edition.

    DATE                                                                                    
  REPORTED WHO PLATFORM LOCATION  WHAT                                                      
  -------- --- -------- --------  --------------------------------------------------------------------
   1/21/15 sdm PDF      All       The leading within paragraphs is sometimes inconsistent. This is
                                  because the code font is slightly taller than the non-code font, so
                                  lines containing text in code font get a bit more leading than those
                                  without. Reducing the size of the code font 5% fixes that problem,
                                  but it leads to a surprisingly large number of revised page breaks
                                  throughout the book, so we've decided to live with the inconsistent
                                  leading. 

   1/12/15 sdm Kindle   All       The book's TOC is at the end of the book, rather than at the
                                  beginning. This is O'Reilly policy for digital books, because
                                  E-readers have their own intrabook navigation systems.

  11/18/14 sdm Kindle   All       On some platforms, spacing above or below code displays is excessive,
                                  (e.g., on Kindle app on iPad, there's too much space above code
                                  displays, whereas on Kindle for PC, there's too much space after
                                  code displays). I'm told "there are known inconsistencies within the
                                  Kindle device/app family, and there is no way to account for each
                                  variation." Not that that has prevented us from trying.

  11/21/14 bxm Kindle   All       Search functionality is...counterintuitive. Examples:

                                                             Kindle       Actual
                                    Text to Search For        Hits      Occurrences
                                    ------------------       ------     -----------
                                    std::array                 0            27
                                    std:: array                25           0
                                    std :: array               0            0

                                    #include <string>          0            5
                                    #include < string>         0            0
                                    #include < string >        5            0

                                    = delete                   2            12
                                    = delete;                  10           10

                                  If you're aware of a good description of how Kindle search
                                  works, please let me know. I'd like to link to it.

   1/13/15 sdm Kindle   All       The book's digital TOC lacks entries for individual Items, but this
               on PC              is apparently a limitation of Kindle on PC. On other Kindle platforms,
                                  I'm told that the digital TOC does link to individual Items. 

   3/29/15 scp Kindle   All       Emphasized words (presumably italicized) are invisible. I'm told this
               on HTC             is a problem with the Kindle app when using the default font
               One (M8)           (Caecelia). Choosing a different font should resolve the issue.

! 10/ 5/14 txn All      Item 1    Case 1 applies only when ParamType is a non-universal reference.
                                  It doesn't apply when ParamType is a pointer type, because
                                  parameters of pointer type are treated like by-value parameters.
                                  (The pointer is passed by value.) So the three cases are really:

                                  Case 1: ParamType is a non-universal reference.
                                  Case 2: ParamType is a universal reference.
                                  Case 3: ParamType is a non-reference.

                                  This is a simpler way of classifying template type deduction
                                  behavior: two major cases (reference parameters and non-reference
                                  parameters) and two sub-cases for one of the major cases (universal
                                  reference parameters and non-universal reference parameters).

   4/29/21 dxw PDF      11        It could make things clearer if (1) an example were given where expr is a
                                  reference, but not a reference-to-const, and (2) the variable name for
                                  the reference-to-const were rcx instead of rx.

  12/18/14 csc PDF      24        In the final line of the code example, if v were a const vector,
                                  decltype(v[0]) would be const int&, because std::vector::operator[]
                                  is overloaded on const, and the const version has a
                                  reference-to-const return type.

   7/ 5/17 rxz PDF      27        Technically, parameters bind to arguments, but in some places in the
                        87        book (as noted by the page numbers at left), I refer to arguments as
                        166       binding to parameters (or, in some cases, as expressions as binding to
                        192       variables). I believe the current wordings are pretty clear, and I'm
                                  concerned that trying to rewrite the explanations to be technically
                                  correct might make things worse, so I'm leaving as is the places 
                                  where I refer to things binding to names instead of names binding to
                                  things. 

   3/17/15 fdb PDF      27-28     Except for std::vector<bool>, container<T>::operator[] for all
                                  standard library containers returns T&, which is an lvalue.  Given an
                                  rvalue container rc, then, indexing into it (e.g., rc[i]) yields an
                                  lvalue, even though rc itself is an rvalue. Because authAndAccess
                                  with a decltype(auto) return type returns exactly what
                                  container<T>::operator[] does, an implication is that in the code
                                  defining s on page 27, s will be copy constructed, even though the
                                  element initializing it is in an rvalue std::deque<string>.
                                    authAndAccess could be revised to return rvalues for rvalue
                                  container arguments, but the crux of the issue in this case is that
                                  operator[] for rvalue containers yields an lvalue. Given C++11's
                                  support for overloading on lvalue and rvalue objects (as described
                                  in Item 12 of EMC++), it'd be interesting to know why operator[]
                                  for an rvalue object doesn't return an rvalue reference (which, for
                                  function return types, is an rvalue).

   1/26/15 tyk All      Item 3    The behavior of these two ways of declaring a function template may
                                  not be the same:

                                    template<typename T>
                                    auto f()->decltype(expr)    // #1 -- explicit return type
                                    {
                                      ...
                                      return expr;
                                    }

                                    template<typename T>
                                    decltype(auto) f()          // #2 -- deduced return type
                                    {
                                      ...
                                      return expr;
                                    }

                                  In #1, if expr is invalid, SFINAE will cause f to be removed from
                                  the candidate overload set, but in #2, if expr is invalid, f
                                  will be ill-formed, and compilation will fail. The same would be true
                                  for an auto return type. This means that it's not always possible to
                                  replace an explicit return type with a deduced return type.  
                                    (If the sentence with "SFINAE" makes no sense to you, you should
                                  probably not be writing templates with auto or decltype(auto) return 
                                  types.) 

   6/19/16 axd All      38        The text suggests that it's always a good idea to initialize
                                  variables, but there are cases where it makes sense to leave
                                  variables uninitialized (e.g. as described here). 

  11/22/14 tyk All      Item 6    A noteworthy difference between the explicity typed initializer
                                  idiom (ETII)'s

                                    auto var = static_cast<type>(expr);

                                  and this auto-free alternative,
 
                                    type var = expr;

                                  is that explicit conversions are permitted in the ETII version, but
                                  not in the auto-free one. However, the ETII version is equivalent to
                                  these auto-free versions:

                                    type var(expr);
                                    type var{expr};

                                  In effect, the ETII performs direct initialization, not copy
                                  initialization, and as such is arguably less safe (due to support
                                  for more conversions) than an auto-free variable declaration using
                                  copy initialization syntax.

  11/23/14 bbs PDF      46        A way to confirm that an expression (such as a function call)
                                  returns the type you expect is to use static_assert. On page 45, for
                                  example, the type of the object sum could be asserted to be Matrix:

                                    static_assert(std::is_same<decltype(sum), Matrix>::value,
                                                  "sum isn't a Matrix!");

                                  Typically, you want to strip reference and cv-qualifiers before
                                  doing the comparison, so you can use std::decay (as on pages
                                  190-191), but, as I note on page 191-192, std::decay will also turn
                                  arrays and functions into pointers, and you may not want that. In
                                  that case, you'll want to use something more like R. Martinho
                                  Fernandes' Unqualified type trait.

   4/23/15 nwp PDF      59        The fact that nullptr isn't a pointer type means that it can't be
                                  passed to templates partially specialized for pointers:

                                    template<typename T>
                                    void f(T*);            // partial specialization for pointers

                                    f(nullptr);            // error!

  10/24/14 dxn PDF      Item 9    Just as C++14 standardizes the convention of using a "_t" suffix
                                  for nested types, C++17 is likely to standardize the convention of
                                  using a "_v" suffix for values (i.e., a nested "value" member).

   1/25/15 tyk All      Item 9    Another advantage of alias templates over typedefs nested inside
                                  templatized structs is that type deduction is applicable to
                                  parameters of alias template types, but not to parameters of
                                  typedef-inside-a-struct types:

                                    template<typename T>                            // alias template from
                                    using MyAllocList = std::list<T, MyAlloc<T>>;   // Item 9 (PDF page 64)

                                    template<typename T>                            // f1 is a function
                                    void f1(MyAllocList<T>& list);                  // template

                                    MyAllocList<Widget> lw;                         // also from Item 9

                                    f1(lw);                                         // fine, T in f1
                                                                                    // deduced as Widget
                                           

                                    template<typename T>                            // struct with nested typedef
                                    struct MyAllocList {                            // from Item 9 (PDF page 64)
                                      typedef std::list<T, MyAlloc<T>> type;
                                    };

                                    template<typename T>                            // f2 is a function
                                    void f2(typename MyAllocList<T>::type& list);   // template

                                    MyAllocList<Widget>::type lw;                   // also from Item 9

                                    f2(lw);                                         // error! can't
                                                                                    // deduce T in f2

  11/23/14 bbs PDF      71-73     In C++14, std::tuples can be indexed by the type of a field instead
                                  of its index, as long as the type is unique. That has only limited
                                  applicability to the example in the book, because the first and
                                  second fields are of the same type (std::string), but it's still
                                  worth knowing about.

   6/19/16 axd All      71-73     Another approach to creating enums to identify std::tuple fields is
                                  to nest an anonymous enum inside a struct, e.g.:

                                    struct UserInfoFields
                                    {
                                        enum { name, email, reputation };
                                    };

                                    auto val = std::get<UserInfoFields::name>(uInfo);




   2/12/15 hxh All      Item 11   Move operations should probably never be deleted. If you want
                                  neither moving nor copying to be available, deleting the copy
                                  operations suffices. (That will prevent generation of the move
                                  operations.) If you want only copying to be supported, declaring
                                  the copy operations (possibly via "=default") will again prevent
                                  the move operations from being generated.
                                    If you try to permit copying but disable moving by declaring the
                                  copy operations but deleting the move operations, you will prevent
                                  the copying of rvalues, because the deleted move operations will
                                  be a better match during overload resolution than the "fallback"
                                  copy operations. 

   3/29/15 dxg All      Item 11   dxg writes: "I had a class with default constructor declared as
                                  private without implementation. I decided to do a simple refactor
                                  and made the function public and deleted. After that clang found an
                                  unused field in the class! While the function had a declaration
                                  compiler had no any information about its body, so it can't prove
                                  that the field has been unsued (the constructor could be defined
                                  anywhere with the usage of the field)."

   1/25/15 tyk All      83-85     One application of reference-qualified member functions is to prevent
                                  modification of rvalues (e.g., objects returned from
                                  functions). Such modification is not permitted for rvalues of
                                  built-in types, so this would be a way for user-defined types to
                                  mimic that behavior. 
                                    The approach is to restrict use of modifying member functions to
                                  lvalues by "&"-qualifying them, e.g.:

                                    class Widget {
                                    public:
                                      Widget& operator=(const Widget&) &;   // copy-assign only lvalues
                                      Widget& operator=(Widget&&) &;        // move-assign only lvalues

                                      void setName(const std::string&) &;   // setter is only for lvalues
                                    };

  12/18/14 ahp PDF      88-89     The Standard requires that std::cbegin be implemented by calling
   1/26/15 tyk                    std::begin (as shown in the book), but in C++14, the code could be
                                  made a smidge more generic by using the following implementation,
                                  which, unlike the code in the book, would work with container-like
                                  objects supporting non-member begin instead of member begin:

                                    template <class C>
                                    decltype(auto) cbegin(const C& container)
                                    {
                                      using std::begin;
                                      return begin(container);
                                    }

                                  Achieving the same thing in C++11 is trickier, because we have to
                                  make std::begin visible during evaluation of the return type
                                  declaration without making it visible outside the cbegin function
                                  we're declaring. The following works:

                                    namespace cbegin_access_impl {         // helper namespace
                                      using std::begin;

                                      template<class C>
                                      auto cbegin(const C& container)->decltype(begin(container))
                                      { 
                                        return begin(container);
                                      }
                                    }

                                    template<class C>
                                    auto cbegin(const C& container)->decltype(cbegin_access_impl::begin(container))
                                    { 
                                      return cbegin_access_impl::begin(container); 
                                    }

   1/24/15 sdm PDF      92        In the third sentence of the fourth paragraph, the word "sporting"
                                  is correct; it's not a typo for "supporting." To "sport" something
                                  can mean to wear it as an adornment, so in the sentence in the book,
                                  I'm talking about functions that offer (i.e., that "sport") the
                                  strong exception safety guarantee.

  12/19/14 ahp All      Item 16   For cached values that are constant, use of a std::once_flag and
                                  std::call_once is probably preferable to use of a mutex or a
                                  std::atomic. However, if a cached value can change over time (e.g.,
                                  in the examples in Item 16, if the coefficients of a Polynomial can
                                  be changed at runtime (thus changing its roots) or if the value
                                  returned by Widget::magicValue changes each day at midnight), the
                                  approaches shown in the Item are likely to be more appropriate.

  11/17/15 jxl All      105-6     Though introduction of the std::mutex causes Polynomial and Point to 
   2/ 9/17 abt                    become uncopyable and unmovable, copyability and movability can be
                                  restored by defining the copy and move operations manually. abt
                                  writes that one way to approach the matter would be to "create
                                  a new mutex for the object being created and then copy everything
                                  else. Likewise, custom copy/move assignment operators would be
                                  required and would copy/move all items except for the mutex."

  11/17/15 jxl PDF      106-7     If magicValue is called often enough and the cost of mutex acquisition
                                  is high enough compared to the cost of using std::atomics, it could
                                  be an overall performance improvement to use std::atomics for
                                  cacheValid and cachedValue, even though cachedValue might be computed
                                  more than once. That's because the cost savings on each access could
                                  more than compensate for the excess costs associated with multiple
                                  magicValue computations.

  11/17/15 jxl PDF      108       If more than one variable or memory location requires synchronization,
                                  but all can be packed into the amount of memory that can be manipulated
                                  truly atomically by the underlying hardware (typically one or two
                                  words), an alternative to use of a std::mutex is a std::atomic<PackedType>,
                                  where PackedType is a user-defined type containing the variables to be
                                  manipulated as a unit. 

   1/11/16 sdm All      Item 17   Compiler-generated special functions are implicitly noexcept unless
                                  their compiler-generated implementations call non-noexcept
                                  functions. Destructors and move operations rarely call functions
                                  that can throw, so implicitly-generated destructors and move
                                  operations are typically noexcept. (As noted in Item 14, even
                                  user-declared destructors are usually implicitly noexcept.)

   1/18/15 bbs PDF      117       Another disadvantage of raw pointers is that deleting incomplete
                                  types through them, while often eliciting a warning,
                                  nevertheless compiles. Trying to do the same thing through a smart
                                  pointer is an error, and the code
                                  typically fails to compile.

   8/31/16 ryk PDF      117       Two more disadvantages of raw pointers:
                                    - If they're not explicitly initialized, their initial value may
                                      not be defined. std::unique_ptr and std::shared_ptr are
                                      initialized to null by default. 
                                    - As data members, they typically require that the containing
                                      class implement the special member functions. With smart pointer
                                      data members, this is generally unnecessary. 

  12/13/14 rxm All      Item 18   The makeInvestment interface is unrealistic, because it implies that
                                  all derived object types can be created from the same types of
                                  arguments. This is especially apparent in the sample implementation
                                  code, where are arguments are perfect-forwarded to all derived class
                                  constructors.

  12/15/14 sdm PDF      122       The encapsulation offered by the "auto"-returning version of
                                  makeInvestment is diluted by the fact that in order to call it, its
                                  body must be visible. In practice, this means that functions with
                                  deduced return types must often be defined in header files. 
                                    On the plus side, the "auto"-returning version of makeInvestment
                                  prevents the name "delInvmt" from being visible outside the
                                  function. 

   1/28/15 tyk PDF      122-123   A drawback of giving makeInvestment an "auto" return type is that
                                  it complicates things for callers who need to know that type (e.g.,
                                  to declare a container holding objects returned from
                                  makeInvestment). tyk argues that there's no point in trying to hide
                                  a factory function's return type.

   1/18/15 bbs PDF      124       A situation where you might choose to use std::unique_ptr<T[]> 
                                  instead of a standard container is when the size of the array isn't
                                  known during compilation (thus ruling out std::array) and where you
                                  want to minimize memory usage. The footprint of std::unique_ptr<T[]>
                                  is slightly smaller than that of a std::vector, std::deque, or
                                  std::string. 

  12/20/14 tyk All      Item 21   Make functions can't be used when the constructor to be called isn't
   6/23/15 whb                    public. (Declaring the make functions friends may not work, because
                                  make functions may internally call other functions that actually
                                  perform the constructor invocation.) An example of this is in Item
                                  19 (on page 132 of the PDF version of the book), where Widget
                                  declares a static factory function instead of using a make function.
                                    For workarounds, see this StackOverflow discussion.

   3/23/15 etc All      Item 21   Make functions can't be used to create smart pointers to abstract
                                  base classes, e.g., that are initialized by cloning functions. For
                                  example: 

                                    class Base {
                                    public:
                                      virtual Base* clone() const = 0;
                                    };

                                    class Derived: public Base {
                                    public:
                                      virtual Derived* clone() const override;
                                    };

                                    Derived d;
                                    
                                    auto pb1 = std::make_shared<Base>(d.clone());  // error!
                                    auto pb2 = std::shared_ptr<Base>(d.clone());   // fine                              

   5/ 8/18 hxp All      140-141   In C++17, argument evaluation order rules have been revised such
                                  that no resource leak can occur.

   1/29/15 tyk PDF      152       In second para, I say that the compiler-generated move operations do
                                  "exactly what's desired: perform a move on the underlying
                                  std::unique_ptr". Such moves are shallow, but for a class with value
                                  semantics like Widget, deep move operations would be at least as
                                  reasonable, and they'd avoid the need to handle null pImpl pointers
                                  in Widget member functions. However, they'd also require allocating
                                  and initializing a Widget::Impl object for moved-from objects, even
                                  if the next operation to be performed on the Widget was destruction.

   1/19/15 bbs All      Item 22   The Pimpl idiom reduces build times, but the indirection introduced
                                  by the pPimpl pointer may increase runtime, and the pointer itself
                                  increases total memory usage.

   3/10/16 mtl PDF      154       The shown Widget::operator= works correctly if a Widget is
                                  assigned to itself, but such assignment would incur the cost of
                                  copying an Impl object, and that could be expensive. If that cost is
                                  sufficiently high, or if self-assignment is expected to be common,
                                  it could be worthwhile to add the customary self-assignment check to
                                  the top of operator=:

                                    Widget& Widget::operator=(const Widget& rhs)
                                    {
                                      if (this == &rhs) return *this;

                                      ...                                // implementation as in book
                                    }

                                  However, this kind of check has costs of its own. The function is a
                                  little longer, and a new branch is added. 

   2/11/15 sdm PDF      171       In last paragraph, I say that the number of overloads grows
                                  geometrically instead of exponentially, because, per 
                                  the Wikipedia page, "geometric" is appropriate for discrete domains,
                                  while "exponential" applies to continuous domains.

   5/24/20 dyg PDF      175-6     The fact that local objects eligible for the RVO and not elided
                                  must be treated as rvalues is the reason why functions returning
                                  move-only types may return local variables of those types.

  12/19/14 ahp All      Item 26   The fact that template functions may outcompete non-template
                                  functions with the same name (i.e., overloads) is not unique to
                                  templates taking universal references or even to C++11. The same
                                  thing can happen in C++98 with a template taking a const T&
                                  parameter, because such a parameter can bind to all types and can
                                  accept both lvalues and rvalues. In my (Scott's) experience,
                                  however, this rarely leads to trouble in practice, probably because
                                  there are no move semantics in C++98.

   3/ 1/18 ext PDF      187-8     An alternative to having logAndAddImpl at the top of page 188 call
                                  logAndAdd is to have it call directly to the version of
                                  logAndAddImpl taking a non-integral type, i.e., 

                                    void logAndAddImpl(int idx, std::true_type)
                                    {
                                      logAndAddImpl(nameFromIdx(idx), std::false_type());
                                    }

                                  This approach has the advantages that (1) it avoids the call to
                                  logAndAdd that merely forwards to logAndAddImpl and (2) it may
                                  simplify the declaration order among the logAndAdd template and the
                                  logAndAddImpl template specializations.

   1/21/15 sdm All      195-6     Several people have suggested moving std::is_constructible from a
                                  static_assert inside the Person constructor to the
                                  std::enable_if/std::enable_if_t outside it. This would change the
                                  behavior of the code. The enable_if controls whether the constructor
                                  should be considered during overload resolution. The static_assert
                                  controls whether the function, once it’s been chosen by overload
                                  resolution, has received a valid argument type. If
                                  std::is_constructible were part of the enable_if clause and a caller
                                  passed an argument of an invalid type, the error message would say
                                  something like "No function found for an argument of type [type of
                                  argument]." With std::is_constructible inside the static_assert, the
                                  error message would say "Parameter n can't be used to construct a
                                  std::string."

   2/ 3/16 shc PDF      196       To get the message specified in the static_assert to appear before
                                  the errors resulting from invalid template instantiation, the
                                  static_assert can be moved into a lambda whose invocation precedes
                                  the normal initializer in a comma expression in the member
                                  initializer list: 

                                    class Person {
                                    public:
                                      template<                                // as before
                                        typename T,
                                        typename = std::enable_if_t<
                                          !std::is_base_of<Person, std::decay_t<T>>::value
                                          &&
                                          !std::is_integral<std::remove_reference_t<T>>::value
                                        >
                                      >
                                      explicit Person(T&& n)
                                      : name((
                                              []{ static_assert(std::is_constructible<std::string, T>::value,
                                                                "Parameter n can't be used to construct a std::string"); }(),
                                              std::forward<T>(n)
                                             ))
                                      {
                                        …                   // the usual ctor work goes here
                                      }

                                      …                     // remainder of Person class (as before)

                                    };

                                  The code is a bit tricky, because you have to surround the comma
                                  expression with parentheses in order to avoid an incorrect parse
                                  (as explained here). 

                                  Note that it's not possible to use the static_assert in the comma
                                  expression directly (i.e., to omit the lambda), because only
                                  expressions can be used in a member initializer, and static_assert
                                  is a declaration, not an expression.

  12/31/14 axk All      Item 28   If a template taking a parameter of type cv T& (where cv is
   2/ 1/15 tyk                    const or volatile or both) is explicitly instantiated with a
                                  reference type, cv refers to the reference in the explicitly-
                                  specified reference type and is ignored. Reference-collapsing then
                                  applies as usual:  

                                    template<typename T>
                                    void func(const T& param);

                                    int x;
                                    func<int&>(x)  // inside func, param's type is
                                                   // int&, not const int&

                                  For details, consult this StackOverflow question.
                                    The phenomenon of cv qualifiers disappearing when references to
                                  references arise is not limited to function template parameters. In
                                  general, if references to references arise during compilation (e.g.,
                                  in parameter type construction, typedef construction, or type
                                  creation via decltyp expressions), any cv-qualifiers that apply to
                                  the referred-to type are discarded before reference collapsing
                                  occurs. Here's a modified example from the end of Item 28 (on
                                  page 202 of the printed and PDF versions of the book):

                                    template<typename T>
                                    class Widget {
                                    public:
                                      typedef const T&& RvalueRefToConstT;  // compared to example
                                      …                                     // in book, const has
                                    };                                      // been added

                                    Widget<int&> w;               // w::RvalueRefToConstT is int&

   3/12/19 gpk All      209       Another workaround for the inability to perfect forward braced
                                  initializers is to overload the forwarding function such that
                                  a new overload takes a std::initializer_list:

                                    template<typename T>                       // as in book
                                    void fwd(T&& param) { … }

                                    template<typename T>                       // new overload
                                    void fwd(std::initializer_list<T> ilist)
                                    {
                                      f(ilist);
                                    }

                                    fwd( {1,2,3} );                            // fine, calls new overload

                                  gpk notes that this approach seems to violate Item 26 ("Avoid
                                  overloading on universal references"), but in this case, the
                                  overly greedy behavior of universal reference parameters isn't a problem.
                                  In fact, when it comes to braced initializer arguments, the problem in
                                  some sense that they're not greedy enough.

  12/19/14 ahp All      Item 30   A workaround for the inability to perfect-forward const/constexpr
                                  data members and bitfields is to use the member to create a
                                  temporary expression with the same value. For example, instead of
                                  "foo(my_static_const)", pass "foo(+my_static_const)", or instead of
                                  "foo(my->bit_field)", pass "foo(my->bit_field+0)".  This must be
                                  applied at each call site and may change the type of the expression
                                  (chars and shorts will typically be promoted to ints, for example),
                                  but it may be acceptable in some contexts.
                                    If a static member is in a library that is header-only, this
                                  approach keeps it header-only, and if the class is part of a library
                                  not under the programmer's control, this solution avoids providing a
                                  definition for a symbol that the user didn't declare.

   8/10/15 nwp PDF      216       Because each lambda gives rise to a unique closure class, two
                                  textually identical lambdas create different types. This can
                                  lead to code duplication if the closure type's operator() isn't
                                  inlined. The problem can be avoided by storing the lambda's closure
                                  in an auto variable and using that variable in all locations
                                  where the lambda would otherwise be employed:

                                    f1([x, y, z]{ /* complex code */ });         // each call creates a
                                    f2([x, y, z]{ /* same code as above */ });   // new closure class with
                                                                                 // a new operator()
                                                                                 // function

                                    auto func = [x, y, z]{ /* same code as above*/ };

                                    f1(func);                                    // both calls use the
                                    f2(func);                                    // same closure class's
                                                                                 // operator() function

  12/19/14 ahp PDF      223       Just as "[=]" could mislead readers into thinking that a lambda was
                                  self-contained, "[]" could have the same effect; a reader
                                  might think that "no capture" implies "self-contained." The behavior
                                  of both "[=]" and "[]" lambdas can be dependent on objects with
                                  static storage duration.

   6/15/14 tyk All      Item 34   Lambdas can be much more verbose than std::bind. This is especially
                                  true for a bound "pass through" function, i.e., a bound function
                                  whose arguments are perfect forwarded and whose return value is 
                                  decltype(auto)'d to the caller (i.e., where "perfect returning" is
                                  used). For example, given

                                    class Widget {
                                    public:
                                      const std::vector<std::string>& update(std::string newVal);
                                      ...
                                    };

                                  and a Widget w we know we want to invoke update on, compare the
                                  following equivalent ways to express the binding of w and update:

                                      // assume "using namespace std::placeholders;" has already been done
                                      auto boundWithBind = std::bind(&Widget::update, w, _1);

                                      auto boundWithLambda =
                                       [w](auto&& newVal)->decltype(auto)
                                       { return w.update(std::forward<decltype(newVal)>(newVal)); };

   2/ 8/15 tyk All      Item 35   "Task-based programming" is a design approach based on (1) defining
                                  units of work ("tasks") to be executed, (2) specifying the data and
                                  timing dependencies among the tasks, and (3) relying on the runtime
                                  system to execute the tasks such that the dependencies are
                                  respected.  std::async is the best tool in the C++14 Standard
                                  Library for such programming, but it doesn't fully enable task-based
                                  programming, as this blog post explains.

   6/19/16 axd All      244       The book notes that task-based programming significantly reduces
                                  the likelihood of an out-of-threads exception, but that doesn't
                                  change the validity of page 243's statement that well-written
                                  software must deal with such exceptions. Task-based programming
                                  therefore has no fundamental advantage over thread-based
                                  programming as regards the need for software to address out-of-thread
                                  exceptions. 

  12/18/17 pxj All      244       Rigorously speaking, the std::launch::async launch policy doesn't 
                        246       guarantee that std::async will run the passed-in function on a
                                  different thread, it merely guarantees that program execution will
                                  proceed as if the passed-in function ran on a different thread.
                                  This flexibility might permit implementations to, for example, run the
                                  passed-in function on an existing-but-not-currently-used thread in a
                                  thread pool, or to optimize out execution of the passed-in function
                                  entirely (e.g., if they could establish that eliminating execution of
                                  the function would have no effect on the observable behavior of the
                                  program).

   2/ 8/15 tyk PDF      251-256   The program will be terminated if an exception arises in the lambda
                                  expression inside doWork, i.e., if the filtering function or
                                  std::vector::push_back throws. This can be fixed by wrapping the
                                  lambda in a std::packaged_task, but if control in doWork never
                                  reaches performComputation (e.g., due to conditionsAreSatisfied
                                  returning false or to an exception arising while t's priority is
                                  being set), the use of ThreadRAII::DtorAction::join on page 256
                                  would cause doWork to block waiting for the lambda to finish, even
                                  though its result (the data in goodVals) would never be used. 
      
                                  Having the lambda move-capture filter and return goodVals would make
                                  it possible to change the ThreadRAII DtorAction to
                                  ThreadRAII::detach, thus eliminating the need to block. Rewriting
                                  doWork to incorporate these ideas yields:

                                    bool doWork(std::function<bool(int)> filter,
                                                int maxVal = tenMillion)
                                    {
                                      std::packaged_task<std::vector<int>()> 
                                         filterTask([filter=std::move(filter), maxVal]
                                                    { 
                                                      std::vector<int> goodVals;
                                                      for (auto i = 0; i <= maxVal; ++i)
                                                        { if (filter(i)) goodVals.push_back(i); }
                                                      return goodVals;
                                                    });

                                      auto goodValsFuture = filterTask.get_future();
                                      
                                      ThreadRAII t(std::thread(std::move(filterTask)), 
                                                   ThreadRAII::DtorAction::detach);
                                      
                                      auto tnh = t.get().native_handle();
                                      …

                                      if (conditionsAreSatisfied()) {
                                        auto goodVals = goodValsFuture.get();
                                        performComputation(goodVals);
                                        return true;
                                      }
                                                 
                                      return false; 
                                    }

                                  A noteworthy aspect of this implementation is that if an exception
                                  occurs in the lambda, it will be propagated to doWork only if
                                  conditionsAreSatisfied returns true. If conditionsAreSatisfied
                                  returns false, the exception will be ignored. 

  10/27/15 kzh PDF          254   std::thread::join and std::thread::detach can emit exceptions, and
                                  that means that ThreadRAII's destructor can throw. If this happens
                                  during stack unwinding due to another exception, program execution
                                  either terminates or yields undefined behavior. 
                                    My advice on how to approach this problem is described in Item 8
                                  of Effective C++, Third Edition: add a function to ThreadRAII
                                  that clients can call if they need to be able to handle exceptions
                                  that may arise when the destructor action is performed. 

   1/19/15 bbs All      Item 38   The fact that the final future referring to a shared state created
                                  via a call to std::async and where the launch policy is
                                  std::launch::async blocks until the asynchronously running task
                                  completes means that "fire and forget" std::async calls that ignore
                                  std::async's return value may block until the asynchronously running
                                  task finishes. That is, such calls may run synchronously. That's
                                  because the std::future returned from std::async will be destroyed
                                  at the end of the statement calling std::async, so if the launch
                                  policy is std::launch::async, that std::future's destructor will
                                  block until the invoked task finishes running. (The Standardization
                                  Committee considered changing this behavior, but they ultimately
                                  decided to keep it in the interest of backwards compatibility.)

   2/ 7/15 tyk All      Item 40   A secondary use for volatile is to prevent compilers from optimizing
                                  away code that has no effect on observable program behavior. If you
                                  try to time an empty loop to calcuate the loop overhead (e.g., try
                                  to time "for (int i = 0; i < 10'000'000; ++i);"), compilers
                                  will typically optimize the loop away and report that no time was
                                  spent there. To prevent the optimization, the loop variable can be
                                  declared volatile: "for (volatile int i = 0; i < 10'000'000; ++i);".

   1/30/15 tyk All      Item 41   Another behavioral difference between (1) overloading for lvalues
                                  and rvalues and (2) a template taking a universal reference (uref)
                                  is that the lvalue overload declares its parameter const, while the
                                  uref approach doesn't. This means that functions invoked on the
                                  lvalue overload's parameter will always be the const versions, while
                                  functions invoked on the uref version's parameter will be the const
                                  versions only if the argument passed in is const. In other words,
                                  non-const lvalue arguments may yield different behavior in the
                                  overloading design vis-a-vis the uref design.

   1/30/15 tyk All      Item 41   A universal reference parameter can bind to virtually any kind of
                                  argument. (Exceptions are covered in Item 30.) An implication is that 
                                  metaprogramming techniques based on testing the validity of function
                                  calls with certain kinds of arguments are rendered largely useless,
                                  because virtually all calls to functions taking universal references
                                  are considered valid. That's not the case with functions taking
                                  parameters of specific types, because only argument types compatible
                                  with the parameter types yield valid calls. This difference can be a
                                  reason to overload for lvalues and rvalues of specific types instead
                                  of writing a template taking universal references. 

Who's who:

  txn = Tyson Nottingham                     tjb = Tyler Brock
  dxn = Daniel Nielsen                       akb = Agustín K-ballo Bergé
  kxv = Kostas Vlahavas                      mxs = Minkoo Seo
  txk = Takatoshi Kondo                      axk = Andrey Khalyavin
  lxs = Lewis Stiller                        fxf = Fabrice Ferino
  dxj = Dainis Jonitis                       jxz = Jay Zipnick
  tyk = Tomasz Kamiński                      oxb = Oliver Bruns
  kxa = Ken Aarts                            bvw = Bart Vandewoestyne
  rxb = Ryan Brown                           bxy = Benjamin Yates
  daa = Daniel Alonso Alemany                bxm = Bernhard Merkle
  bxr = Barry Revzin                         pxv = Petr Valasek
  rxm = Robert McCabe                        mxw = Marcel Wid
  rxk = Rex Kerr                             mxm = Miroslaw Michalski
  kxh = Kjell Hedstrom                       mjs = Matthias J. Sax
  csc = Curtis S. Cooper                     mam = Mark A. McLaughlin
  bbs = Bartek Szurgot                       vhg = Vlad Gheorghiu
  ahp = Adam Peterson                        mxk = Mitsuru Kariya 
  hxh = Howard Hinnant                       gxs = Grebёnkin Sergey
  sxt = Semen Trygubenko                     fdb = Ferdinand deBoevere
  lxz = Leor Zolman                          dxg = Denis Gladkiy
  scp = Siu Ching Pong                       lxp = Lucas Panian
  etc = Eitan Frachtenberg                   nwp = Nathan W. Panike
  pxz = Piotr Zygielo                        dgw = Don Goodman-Wilson
  whb = Will Bickford                        mys = Marek Scholle
  kyh = Kisung Han                           kzh = Kalle Huttunen
  rxh = Rein Halbersma                       bxc = Ben Craig
  jxl = Johannes Laire                       nxj = Nicolai Josuttis
  shc = 蘇浩禎 Su Hao-Chen                    jsb = Jesper Storm Bache
  jxm = József Mihalicza                     mtl = Matthew Limber
  gxk = Gerhard Kreuzer                      gxp = Gennaro Prota
  axd = Alex Dumov                           mtb = Mitch T. Besser
  ryk = Robin Kuzmin                         txb = Tim Buchowski
  hxb = Harri Berglund                       cxl = Calum Laing 
  djm = Declan Moran                         abt - Allen Taylor
  sxa = Stephane Aubry                       tgm = Tomasz Grzegorz Markiewicz
  rxz = Ryan Zischke                         pxj = Péter Joó
  ext = Evgeny Tarasov                       hxp = Helge Penne
  dxk = Daniel Khoshnoudirad                 gpk = Greg Klein
  fxr = Fraser Ross                          kst = Keith S. Thompson
  dyg = Dmitriy Gruzman                      dxr = Dan Raviv
  dxt = David Tzur                           jxr = Julio Merino
  rtc = Roberto Turrado Camblor              dxw = Wang Dianchao 王殿超
  mxh = Marja Hölttä                         ayk = Andrew Kay

From here you may wish to visit the Amazon Page for Effective Modern C++.