Domanda

The Standard states, that nullptr is a pointer literal of type std::nullptr_t (2.14.7). And 18.2p9 defines nullptr_t by

namespace std {
  typedef decltype(nullptr) nullptr_t;
}

By 7.1.6.2p4 decltype(nullptr) is the type of the expression nullptr, which is by definition std::nullptr_t (since the expression nullptr is a prvalue). Substituting that into the definition of nullptr_t results in

typedef nullptr_t nullptr_t

On the other hand a typedef specifier does not introduce a new type, it's just a name for another existing type. So, what is exactly nullptr_t? I'm not able to comprehend these definitions.

È stato utile?

Soluzione 2

Internally there is an entity that is the null pointer constant type. It is one of the fundamental types.

The keyword, literal and expression nullptr has this type. decltype(nullptr) refers to this type.

However the name std::nullptr_t is not a keyword (not even a context-sensitive one), and so the name does not exist until declared. If you refer to the name std::nullptr_t without declaring it, it is an error, as for any undeclared name.

So although the type exists at the start of translation like any fundamental type, the name does not exist.

In fact there are other fundamental types that do not have a "single spelling", such as short int. A short int can be refered to as short, short int, signed short int, signed short, or any permutation thereof.

It is also not dissimilar to the relationship between the typeid operator (keyword), and the type of the typeid(...) expression, std::typeinfo. typeinfo is also not a keyword and the name does not exist before being declared.

Basically, you are conflating an entity (the null pointer constant type) with a name (std::nullptr_t)

If you ask why didn't the language designers specify nullptr_t and typeinfo as keywords, I would speculate that they are not common enough to risk a name collision with a user-defined name with the same spelling. Recall that such a collision would occur in any and all scopes.

Altri suggerimenti

It is implementation-specific. What is important is that (p. 18.2/9 of the C++11 Standard):

[...] The type for which nullptr_t is a synonym has the characteristics described in 3.9.1 and 4.10. [...]

As long as it behaves like the Standard specifies in those two paragraphs, it can be anything.

I believe the logical fallacy in your argument is that this:

By 7.1.6.2p4 decltype(nullptr) is the type of the expression nullptr, which is by definition std::nullptr_t (since the expression nullptr is a prvalue)

Does not mean that nullptr_t is not a type alias. For instance, if I define:

typedef decltype(42) foo;

I can say that the type of the expression:

42

Is foo. Yet, foo is just an alias for another type (int).

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top