关于《Effective Modern C++》勘误中“非左值名称”的技术咨询

Great question! Let's break this down clearly, tying together C++ standard rules and Scott Meyers' intent in *Effective Modern C++.

Which named entities are not lvalues? #

Scott’s errata points out that not all "names" (identifiers or identifier-like constructs) are lvalues. The key examples and other similar cases include:

• nullptr: This is a named prvalue (pure rvalue) of type std::nullptr_t. Even though it looks like a variable name, it’s a special literal that can’t be addressed (e.g., &nullptr is invalid).
• this: Inside member functions, this is a prvalue pointer to the current object. You can’t assign to it (this = &obj is illegal), which aligns with rvalue behavior, and taking its address (&this) is also invalid.
• Enumerators: For example, in enum Fruit { Apple, Banana };, Apple and Banana are named prvalues. They’re constant values of the enum type, and you can’t take their addresses (e.g., &Apple won’t compile).

Did Scott only refer to nullptr and this? #

No, not exclusively. While those two are the most commonly misunderstood cases he highlighted, the C++ standard includes other named prvalues like enumerators. That said, nullptr and this are the ones that trip up most developers because their identifier-like syntax makes them easy to mistake for lvalues.

What makes nullptr different from true/false? Why isn’t true considered a "name"? #

Here’s the critical distinction:

• true and false are boolean literals, not "names" (identifiers). Literals are direct value representations (like 1 for integers or "foo" for strings)—they don’t refer to a named entity in the program’s scope. So they’re not part of the "non-lvalue names" discussion at all.
• nullptr, by contrast, is an identifier-like literal. It looks like a variable name, which is why many developers incorrectly assume it’s an lvalue. But it’s a special case: it’s a prvalue that can’t be addressed or assigned to.
• Your comparison to 1 is spot-on: 1 isn’t a "non-lvalue name" because it’s not a name at all. Same with true/false—they’re just literal values, not named entities. The confusion with nullptr comes from its syntax, which mimics a named variable, unlike the keyword-style literals true/false.

To recap the litmus test: if you can take the address of a named entity (e.g., &myVariable works), it’s an lvalue. If you can’t (e.g., &nullptr, &this, &Apple fail), it’s a prvalue (non-lvalue).

内容的提问来源于stack exchange，提问作者Enlico