[Dantheman]

Quote

Using your logic, why do we even have data types? Everything is inherently 1's and 0's, why don't we just stay at that level?

We're not talking about machine level. Even compiler's themselves treat pointers just like numbers. Print the value of a pointer, cast it into a number, print it out again. The contents are interpreted identically.

Read my response to Mikeblas. I understand why people disagree with me. Now, understand why I disagree with them. Strings are not numbers, try casting a string to number and see how its contents get interpreted (it's probably not possible, but you get my point). But the abstraction between pointers and numbers (to me) is almost non-existent. Besides a compiler fixing a pointer arithmetic, there's absolutely nothing else to them.

NickDMax, on 13 Jun, 2009 - 07:55 AM, said:

an address != to an integer because an address *may* have structure such as segment:offset or page:offset. Since the standard does not define what the address should look like compiler designers are free to design pointers for whatever strange mechanism a bit of hardware may use.

That's the thing, Nick. Of course it can be represented as a data structure. But I've never even heard of such implementation (in C\C++). And that's what I've been asking you guys for. If such implementation exists, then I've been wrong all along and will admit it.

This post has been edited by Dantheman: 13 June 2009 - 09:21 AM

[apw5020]

Dantheman, I hate to get involved, but you are just being a condescending dick.

[Dantheman]

apw5020, on 13 Jun, 2009 - 08:17 AM, said:

Dantheman, I hate to get involved, but you are just being a condescending dick.

You get what you give.

[Kanvus]

addresses have an x in it so it is part alphabetic 0x2f

if this post was longer, it would be more convincing and eventually true in some sense

[Dantheman]

Kanvus, on 13 Jun, 2009 - 08:26 AM, said:

addresses have an x in it so it is part alphabetic 0x2f

Is this a joke, or are you being serious?

[red_4900]

Out of topic :

KYA, on 13 Jun, 2009 - 07:51 AM, said:

To someone not as well versed as you in the arts of all thing computery, they might not understand that a memory address, a double, a number, hell even characters are all ultimately numbers.

I'm with KYA with this one. Dan, did you see the OP's topic type? The explanation should be at beginner's level. I learned C/C++, I learned Assembly, but I can't fully understand your argument. Maybe it's because I'm lacking in experience, I know. I'm afraid any beginner reading this will be..more afraid of pointer. If you really wish to discuss this in REAL detail, how about making new thread in C++ programmer's forum?

Not flaming you, just thinking that maybe you should make your explanation more beginner-friendly. Don't assume all beginner has learned Assembly.

This post has been edited by red_4900: 13 June 2009 - 09:40 AM

[NickDMax]

far pointers in the Large memory model were segment:offset pointers. The compiler had to maintain 2 integer parts -- the segment was placed in a segment register -- the offset was used in various ways. A program using the Large memory model would generally have several segments (the only reason to be so wasteful and use long pointers).

[Dantheman]

red_4900, on 13 Jun, 2009 - 08:39 AM, said:

Not flaming you, just thinking that maybe you should make your explanation more beginner-friendly. Don't assume all beginner has learned Assembly.

The whole assembly thing was directed towards the guys with whom I had an argument. Yes, the OP was a beginner, that's precisely why I said that "address of address" wouldn't make sense to him. I've described the pointers in terms of numbers, in hopes that it would make more sense to him. All I wanted to say is - pointers are nothing special, they are not as complicated as they seem, don't be afraid of them, they are nothing but numbers!

Quote

Far pointers in the Large memory model were segment:offset pointers. The compiler had to maintain 2 integer parts -- the segment was placed in a segment register -- the offset was used in various ways. A program using the Large memory model would generally have several segments (the only reason to be so wasteful and use long pointers).

Yes, but the pointer doesn't store all of this information in itself. It only holds the 16-bit offset. Compiler takes care of loading the appropriate value into segment registers.

This post has been edited by Dantheman: 13 June 2009 - 09:57 AM

[KYA]

It does beginners a disservice (truly anyone for that matter) to say a pointer holds a number, which was and continues to be my viewpoint. All numbers are arbitrarily meaningless unless meaning is given to them.

This post has been edited by KYA: 13 June 2009 - 10:12 AM

[Dantheman]

My original post:

Quote

It's the address of the integer variable that holds the address of x.

I think I made it clear what the contents of the integer variable represent.

[Oler1s]

Dantheman said:

thinking of pointers as nothing special, but simply as integers that hold address, made me understand exactly what pointers are! When I was thinking of pointers as some special abstract quantity, it was too confusing for me.

I fully understand. Abstract explanations feel like the vague hand waving of magicians. "It's all magic", when in reality, it all simplifies down to numbers and operations on numbers. It really helps to see specific implementations.

The problem is that you're declaring that a specific implementation defines what a pointer is. We've been arguing what a pointer is from the standards.

Quote

Of course it can be represented as a data structure. But I've never even heard of such implementation (in C\C++). And that's what I've been asking you guys for. If such implementation exists, then I've been wrong all along and will admit it.

Correctness isn't defined by the implementations. It's defined by the standards. If you want to argue about whether an implementation is sensible that's a different issue. A pointer is completely defined by the standard (which in turn leaves it to up to the implementation). If you are going to argue about what the pointer abstraction is, you can't point to an implementation, and say that's it.

Or put another way, you might argue that the constraints on pointer behavior imply that it must be an integral type (that's the line of argument I would pursue if I were on your side of the argument). Rather, consistently you've been pointing to implementations, and so we can never agree, because you talk about the implementations while we talk about the standard. I think you are incorrect because you then go ahead and say that the implementation defines the abstraction. Are we mistaken? Are you not extending your argument to make that erroneous conclusion?

[NickDMax]

No so! In the large memory module the pointers were 32bit values. I remember this because I did quite a bit of interfacing with assembly language and far pointers were nice because they contained both the offset and the segment. For example creating an interrupt vector was just a matter of reading the current interrupt vector from the interrupt table into a pointer (for various uses) and replacing it with your own pointer to a function.

The compiler only maintained the sement portion of the pointer for near pointers -- in the large memory model all pointers were far pointers (unless declared short).

[Dantheman]

Oler1s, on 13 Jun, 2009 - 09:04 AM, said:

Dantheman said:

thinking of pointers as nothing special, but simply as integers that hold address, made me understand exactly what pointers are! When I was thinking of pointers as some special abstract quantity, it was too confusing for me.

I fully understand. Abstract explanations feel like the vague hand waving of magicians. "It's all magic", when in reality, it all simplifies down to numbers and operations on numbers. It really helps to see specific implementations.

The problem is that you're declaring that a specific implementation defines what a pointer is. We've been arguing what a pointer is from the standards.

Quote

Of course it can be represented as a data structure. But I've never even heard of such implementation (in C\C++). And that's what I've been asking you guys for. If such implementation exists, then I've been wrong all along and will admit it.

Correctness isn't defined by the implementations. It's defined by the standards. If you want to argue about whether an implementation is sensible that's a different issue. A pointer is completely defined by the standard (which in turn leaves it to up to the implementation). If you are going to argue about what the pointer abstraction is, you can't point to an implementation, and say that's it.

Or put another way, you might argue that the constraints on pointer behavior imply that it must be an integral type (that's the line of argument I would pursue if I were on your side of the argument). Rather, consistently you've been pointing to implementations, and so we can never agree, because you talk about the implementations while we talk about the standard. I think you are incorrect because you then go ahead and say that the implementation defines the abstraction. Are we mistaken? Are you not extending your argument to make that erroneous conclusion?

Well, of course we can get all theoretical and state that pointers are implementation specific, so nothing is guaranteed. Heck, pointers may be represented as strings! Nothing stops C from being interpreted, yet people always claim that it is natively compiled. In the same sense, nothing stops Java from being natively compiled either.

I'll be honest, I don't read a C standard before making every post on this website. I've made my statement based simply on the fact that I've never even heard of any C implementation treating pointers as unique structures that hold anything other than an address. And I honestly don't even see the reason for that, especially for a low-level language. You're looking from a theoretical perspective and I'm looking from a practical perspective.

P.S. I honestly don't even remember reading that pointers can be non-integral. If anyone can give me a link to it, that'd be great.

This post has been edited by Dantheman: 13 June 2009 - 10:27 AM

[Dantheman]

NickDMax, on 13 Jun, 2009 - 09:10 AM, said:

No so! In the large memory module the pointers were 32bit values. I remember this because I did quite a bit of interfacing with assembly language and far pointers were nice because they contained both the offset and the segment. For example creating an interrupt vector was just a matter of reading the current interrupt vector from the interrupt table into a pointer (for various uses) and replacing it with your own pointer to a function.

The compiler only maintained the sement portion of the pointer for near pointers -- in the large memory model all pointers were far pointers (unless declared short).

Interesting stuff. But those pointers were still numbers, right? I mean that each pointer was a 32-bit number (I would guess a long long?), and compiler would just dissect it into segment/offset by shifting/bit-masking, right?

I already mentioned it before, I don't deny the fact that the way the address is being represent is platform-specific. I remember reading that in a C standard. They can hold absolute address, they can hold offset-address, etc...

I think we just look at this stuff from different perspective.

This post has been edited by Dantheman: 13 June 2009 - 10:28 AM

[NickDMax]

is this a long integer to you:

struct myFarPtr {
unsigned int segment;
unsigned int offset;
};

Sure it is held in 32 continuous bits... but it is not a long integer.

In the segmented memory system a far pointer was not just a long integer -- it was a continuous 32bits -- but the compiler had to treat the segment and the offset portions separately.