In the C++11 standard, I don't understand the reason why taking the address of nullptr
is disallowed whereas one is allowed to take the address of their own std::nullptr_t
instances. Aside from the fact that nullptr
is a reserved keyword, is there any designated reasoning for this decision?
Simply because it amuses me, I attempted to circumnavigate this restriction with the following function:
decltype(nullptr)* func(const decltype(nullptr) &nref) noexcept { return const_cast<decltype(nullptr)*>(reinterpret_cast<const decltype(nullptr)*>(&nref)); }
I had to use reinterpret_cast
on the parameter because without it I was getting the hysterical error:
error: invalid conversion from 'std::nullptr_t*' to 'std::nullptr_t*' [-fpermissive]
When I call this function by passing nullptr directly I get a different address each time. Is nullptr
dynamically assigned an address just-in-time for comparisons and such? Or (probably more likely) perhaps is the compiler forcing a temporary copy of the underlying object?
Of course none of this is vital information, I just find it interesting why this particular restriction was implemented (and subsequently why I am seeing the behavior I am).
Due to the nature of undefined behavior, you can simplify the statement to simply be " this is never nullptr " since no rule needs to be upheld in the presence of undefined behavior. You're right.
Just return '0' (zero). That is the representation of a null pointer in C++. nullptr would be better, but seriously, use std::find_if and preferably a std::vector<Person> without the pointer.
It's not even an address abstraction, it's the constant specified by the C standard and the compiler can translate it to some other number as long as it makes sure it never equals a "real" address, and equals other null pointers if 0 is not the best value to use for the platform.
No, you don't have to set it to NULL , but some consider it good practice as it gives a new pointer a value that makes it explicit it's not pointing at anything (yet). If you are creating a pointer and then immediately assigning another value to it, then there's really not much value in setting it to NULL .
It's the same as not being able to take the address of 5
even though you can take the address of an int
after giving it the value 5
. It doesn't matter that there's no alternative value for a nullptr_t
to have.
Values don't have addresses; objects do.
A temporary object is generated when you pass such a value to a const &
parameter, or otherwise bind a value to a const reference, such as by static_cast< T const & >( … )
or declaring a named reference T const & foo = …;
. The address you're seeing is that of the temporary.
If you're after a standard answer, § 18.2/9 puts your observations pretty bluntly:
Although nullptr’s address cannot be taken, the address of another nullptr_t object that is an lvalue can be taken.
Alternatively, § 2.14.7 says this about nullptr
:
The pointer literal is the keyword nullptr. It is a prvalue of type std::nullptr_t.
So what is a prvalue? § 3.10/1 answers that:
A prvalue (“pure” rvalue) is an rvalue that is not an xvalue. [ Example: The result of calling a function whose return type is not a reference is a prvalue. The value of a literal such as 12, 7.3e5, or true is also a prvalue. — end example ]
Hopefully, trying to take the address of any of those things in the example will make more sense as to why you can't take the address of nullptr
. It's part of those examples!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With