dereference

The standard says that dereferencing the null pointer leads to undefined behaviour. But what is "the null pointer"? In the following code, what we call "the null pointer": struct X { static X* get() { return reinterpret_cast<X*>(1); } void f() { } }; int main() { X* x = 0; (*x).f(); // the null pointer? (1) x = X::get(); (*x).f(); // the null pointer? (2) x = reinterpret_cast<X*>( X::get() - X::get() ); (*x).f(); // the null pointer? (3) (*(X*)0).f(); // I think that this the only null pointer here (4) } My thought is that dereferencing of the null pointer takes place only in the last case. Am

I'm trying to use the char method isLetter() , which is supposed to return boolean value corresponding to whether the character is a letter. But when I call the method, I get an error stating that "char cannot be dereferenced." I don't know what it means to dereference a char or how to fix the error. the statement in question is: if (ch.isLetter()) { .... .... } Any help? What does it mean to dereference a char and how do I avoid doing so? The type char is a primitive -- not an object -- so it cannot be dereferenced Dereferencing is the process of accessing the value referred to by a reference

Sometimes data at memory address 0x0 is quite valuable -- take x86 real mode IVT as a more known example: it starts at 0x0 and contains pointers to interrupt handlers: a dword at 0x00 is a pointer to division by zero error handler. However, C11 language standard prohibits dereferencing null pointers [WG14 N1570 6.5.3.2], which are defined as pointers initialized with 0 or pointers initialized with a null pointer [WG14 N1570 6.3.2.3], effectively banning the very first byte. How do people actually use 0x0 when it's needed? C does not prohibit dereferencing the null pointer, it merely makes it

I've seen a lot of questions on this but I'm going to ask the question differently without specific code. Is there a way of EASILY determining what is causing the type to be incomplete? In my case I'm using someone elses code and I'm completely sure I don't have the headers right, but (since computers do this stuff much faster and better than human eyeballs) is there a way to get the compiler to say, "hey you think you have type X at line 34 but that's actually missing ." The error itself only shows up when you assign, which isn't very helpful. Potatoswatter I saw a question the other day

Does dereferencing a pointer and passing that to a function which takes its argument by reference create a copy of the object? In this case the value at the pointer is copied (though this is not necessarily the case as the optimiser may optimise it out). int val = *pPtr; In this case however no copy will take place: int& rVal = *pPtr; The reason no copy takes place is because a reference is not a machine code level construct. It is a higher level construct and thus is something the compiler uses internally rather than generating specific code for it. The same, obviously, goes for function

Given that the name of an array is actually a pointer to the first element of an array, the following code: #include <stdio.h> int main(void) { int a[3] = {0, 1, 2}; int *p; p = a; printf("%d\n", p[1]); return 0; } prints 1 , as expected. Now, given that I can create a pointer that points to a pointer, I wrote the following: #include <stdio.h> int main(void) { int *p0; int **p1; int (*p2)[3]; int a[3] = {0, 1, 2}; p0 = a; p1 = &a; p2 = &a; printf("p0[1] = %d\n(*p1)[1] = %d\n(*p2)[1] = %d\n", p0[1], (*p1)[1], (*p2)[1]); return 0; } I expected it to compile and print p0[1] = 1 (*p1)[1] = 1 (*p2)