I wonder what really the &a returns?
Suppose
First case
int a;
int *p= &a ; it works no error
Second case
long int a;
long int b;
b = & a; it wont work
Most of us say b is a variable not a pointer. But see the below.
So the question is if the &a
returns the address which is an unsigned integer then why cant we assign it to a normal variable? But why only to pointers?
See below
b = (unsigned int) &a ; it works after typecasting though its not practicable.
If the address is integer format then why don't the unsigned or long integers save it? I was thinking, there must be some hidden secret behind it. Could anyone reveal it? What I thought is, p开发者_JS百科ointers must be doing something inside but I wonder what it would be and why a normal variable cant be.
Thanks for all your answers but the actual question what really the &a
returns? Integer value or not? if it is integer number why a variable cannot hold it? long int a =65535 \valid why not int a= &b if value of address b is 65535
I'm not worried to use it as pointer, please the question is about just saving the value. Not deferencing the address. People saying 32 or 64 bit, I'm not worried about that. Why it cant save the address if address is a integer number?
I mean why cant we assign the value, I'm not saying to assign the properties of pointers to variable but just assign the value thats it
a=65535
b = a \\ works it assigns b - 65535
&a=65535
b = & a \\ doesn't work, if address is a some integer value,why we can't store it in a variable?
take the 16 bit as example normal pointer (the address ) size is 2 bytes and variable size is 2 bytes why cant we store the address in other variable if address is integer value thats my question i find many answers like ++ it increments by 4 to pointer and value 1 to variable, not worried about that just assigning the value is more important question.
b = & a ; address of a is 4000
++b ; becomes 4001 thats it,thats not a problem
Integers, even long int
, are not always going to be the same size as a pointer. Sometimes they will be (for example, most 32-bit architectures have sizeof(int) == sizeof(void *)
), sometimes they will be different (for example, some 64-bit architectures have sizeof(long) == sizeof(void *)
but some do not -- Visual C++ on Windows being a prime example of a compiler where sizeof(long) != sizeof(void *)
).
There's also the fact that void *
is simply not the same type as long int
.
Imagine a class Foo
and a class Bar
, defined like so:
class Foo {
public: int a;
};
class Bar {
public: int b;
};
It's like asking why you can't assign an instance of class Foo
to a variable of type Bar
-- they're not the same thing, even though in this case both Foo
and Bar
have the same underlying bit pattern.
returns the address which is an unsigned integer
No, it isn't. A pointer (address) is a pointer. Period.
You can and it was very common, it is a pertinent portability issue now though as it cannot be used on x64 platforms with a 64-bit pointer and a 32-bit integer.
It may originate from assembler usage where a register can be easily interpreted as both an integer and a pointer.
It is not overly sensible in modern usage as it can easily lead to mistakes and confusion. Type safety improvements in compiler design disallow such usage but C99 re-introduces some similar support with uintptr_t
and intptr_t
which are "Integer types capable of holding object pointers".
To paraphrase your question:
Why can't we assign [a pointer] to [an integer] variable?
The answer is: because it is not assembler, C and C++ are strongly typed languages.
It's not specific to C or C++. This is the same in all strongly typed languages. It's to a degree even true in English. We can say that "the color of the book is blue", but not "the color of the book is wooden". A type restricts the possible values that a variable can have.
A variable int*
type can only hold values that are addresses of int's, and a variable of type long int
can only hold values between LONG_MIN
and LONG_MAX
inclusive. That's just two completely distinct sets of values.
C and C++ are not absolute. Typecasting will allow you to bypass some restrictions. E.g. (int) 3.5
tells the compiler that you want to convert the non-integer value 3.5 to an approximately-similar integer value. This works better if the two types are more similar. Other languages may not have such typecasting; there you might need to call a function instead. E.g. ROUND(3.5, INT)
Niko, IMHO the point of typed languages is that you cannot just assign one thing to the other, even though they're all just a bunch of bits on the lowest level.
if the address is integer format then why dont the unsigned or long integers save it . I was thinking, there must be some hidden secret behind it.
The address is not an integer; it's an address. On a 64 bit system, this:
int *p;
allocates a 64 bit variable, whereas this:
int b;
allocates a 32 bit variable. They're not the same. They may appear to be the same size on some systems, but they're not the same. Consider just as one example the ++ operator. On a 32 bit system, ++ on a pointer increments the pointer by 4, whereas ++ on an integer increments the integer by 1. The compiler is trying to help you by telling you you're doing something wrong.
Pointers usually are implemented as integers, but C++ specification only defines their behaviour (where are to be equal or different two pointers, etc.).
Transforming a pointer into a uint is like transforming one instance of some other class/type.
Regarding to why b = (uint) &a;
works, probably it's implementation-dependent. (And arch-dependent).
From what I'm getting out of your question, you're under the impression that because an address is represented as hex, it's an integer. Well, sure, but that doesn't mean you can put an integer into a pointer the way you're thinking.
Data (the variable) has information with it..meta data. The size of it, the value, the datatype....the address where it's stored. A pointer is holding that last piece of meta data, the address. It is a special datatype who's primary job is to hold addresses. The value of the pointer is independent of the value of the data, they are 2 seperate things. The value of the pointer tells you where to find the data you're looking for. This is why you cannot put an integer into a pointer in the way you're trying. It's like saying that you live at some street address, and you are also that address. Imagine if people called you by your address, that would be silly!
Consider this: You have a class called x, which contains some members. You create a pointer to this class. The pointer still holds an address with a hex format..but the object can't be broken into a 4 or 8 byte (32 bit and 64 bit respectively) value! Take note, the format of the pointer across all datatypes is the same, regardless of their value.
int a; int *p= &a;
Now..the reason why this worked is because you took the address of variable a and put it into a pointer p. Keyword is ADDRESS, which is what a pointer holds.
long int a;
long int b;
b = & a;
This did not work because you tried putting the ADDRESS (a pointer) of a into b, which is just a variable.
To put it simply, you cannot put an address into a normal variable. An address can only be stored in a pointer.
There is a misconception in your intitial thinking: there are "normal variables" and "poitners". There is no such concept. There are just "variables" and "types".
- int is a "container for an integer value"
- class Person is a container for a Person description.
- int* is a container for the address of an integer
- Person* is a container for an address of a Person.
The & operator returns the address of a variable, and its type is a "pointer to that type".
Assignments can go only from an expression of a given type to a variable of a compatible type.
int, int*, Person and Person* are all each other incompatible.
You cannot assign an int* to an int for the same reason you cannot assign a Person to an int or an int to a Person. Unless you have a function that alows you to write an expression returning one type from the other. just like operator &
does and the &a
expression gives you.
精彩评论