8

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, pointers 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
eddie
  • 1,252
  • 3
  • 15
  • 20
niko
  • 9,285
  • 27
  • 84
  • 131
  • 2
    What's a "normal variable"? "pointers must be doing something inside" Correct. What more do you need to know? They're **not** integers. They're pointers. Please **update** your question to explain what you mean by "normal variable". – S.Lott Sep 09 '11 at 11:51
  • 3
    While it's an integer under the hood, the types don't match, so you can't assign them. That's like saying `UnrelatedClassA` and `UnrelatedClassB` are just bytes, so why can't you assign one to the other? It's part of the type system. – Seth Carnegie Sep 09 '11 at 13:49

9 Answers9

23

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.

Dean Harding
  • 71,468
  • 13
  • 145
  • 180
8

returns the address which is an unsigned integer

No, it isn't. A pointer (address) is a pointer. Period.

Ingo
  • 36,037
  • 5
  • 53
  • 100
  • Although what you're saying is in fact true, this isn't really helpful to a pointer newbie, which I assume OP is. – MGZero Sep 09 '11 at 18:17
  • 1
    MGZero - I appreciate that he *thinks* about the problem, and I just point him to the steps where he assumes wrong. I am confident he is able to resolve the problem by thinking further. This is IMHO better as to get everything served on a silver tablet. – Ingo Sep 10 '11 at 18:58
6

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.

Community
  • 1
  • 1
Steve-o
  • 12,678
  • 2
  • 41
  • 60
3

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)

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • `(int) 3.5` is a rather bad example since it shows a conversion instead of a cast. If it were a real cast, the value would be not `3` but whatever the interpretation of the bit sequence is. – blubb Sep 09 '11 at 11:59
  • @Simon: In C++, it's unambiguously a cast. A `static_cast`, to be precise. It's also a conversion; the two are not exclusive. You seem to be thinking of a `reinterpret_cast`, which is one of the other cast types. However, you can't `reinterpret_cast(3.5)`; `double` to `int` is not on the list of possible conversions. (§ 5.2.10) – MSalters Sep 09 '11 at 12:18
2

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.

Raku
  • 591
  • 2
  • 13
2

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.

Scott C Wilson
  • 19,102
  • 10
  • 61
  • 83
1

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).

robermorales
  • 3,293
  • 2
  • 27
  • 36
1

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.

MGZero
  • 5,812
  • 5
  • 29
  • 46
0

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.

Emilio Garavaglia
  • 20,229
  • 2
  • 46
  • 63