Differance between Array and Pointers

hmmm... to hard?

ok... so you how bout you giving me technical definitions of pointer, array, and address?

I will give you mine... maybe you can find fault...

address - An Integer pointer - An Integer array - An Integer

I could state definitions that give a better idea of how they are used

address - a location in memory of a data type pointer - an integer that holds the address of some data type array - a contiguous sequence of data types starting at an address.

But these definitions are not acurate. A location? whats a location? A data type? whats a data type? a contiguous sequence? Where does it start? How does one use it?

An array might be a collection of sequential data types but that doesn't tell you how to use it... you must have a pointer to the array.

But in reality isn't an "array" then just a sequential collection of addresses? but how do we store pointers? We have to store them an an address? so isn't a pointer just an address of an address?

heres some code from vc++ 2k5 in debug mode to

unsigned char a[30]; for(int i=0;i

lol... seems that way to me too. When programming a micro pics one doesn't even have the ability to work with pointers(atleast not in the sense of intel... one has pointers but they are "fixed" and are more like data types). (remember, I'm arguing that it doesn't make a difference what we call it ;)

Well, my point was that one shouldn't really think of them as different because in reality they are the same idea... ofcourse arrays usually mean that you are working with a sequential set of data types and usually involves some type of iteration.... but so do pointers... if I want to use pointers to do array stuff then I will and it will turn out that at the lowest level the array stuff is using pointers too. So, for me they are equivilent and really address just a superfical way to work with contiguous data types... its just a "thought" tool but not anything more than that... I would never really think of using calling char foo[] in reality it is... its a pointer to a memory location... I am telling the compiler that I will want to use the memory locations after it to... so if I do foo[2] it will "create" a pointer to the 2 memory location after the one pointed to by foo... it doesn't matter how it does this as it will have to use pointers(memory addressing and one could do it without pointers in some sense(but one would just call it pointers)).

I see no problem that if a person completely understand pointers that they should have no problem in understanding arrays... but you probably won't gain any understanding of pointers from arrays(using the standard definition). I could be wrong but...

Jon

Not relevent as stated.

Address - a value which indicates a location in memory. Pointer - a location in memory which contains an address. Array - one of many data types which can reside in memory.

No, a sequential collection of values. Each value has an address, the values may themselves *be* addresses, or they may be other things.

My uncle had a dog which was a pointer, but it was also irrelevent to this thread. If you want to know "what's the difference between a pointer and an array" you don't start by defining them to be the same, and you don't try to misdirect the topic by arguing over syntactic sugar that's rarely used in embedded programming. Most asm dialects use "mov.w" and "mov.b" to indicate operand width, because the "ptr" syntax is confusing when you're used to dealing with high level "pointers".

I think the disagreement seems to be about the high-level concepts, and the implementations. As high-level concepts, arrays and pointers are very different things. They are often used together in C, as C makes little distinction between a pointer to a type and a pointer to an element in an array of that type, but this is just because C exposes more of the low-level implementation than most languages. In particular, in C you can (mostly) treat the name of an array as a pointer to its first element for accessing the data in the array, just as you do at the assembly level. But both in C and in assembly, arrays and pointers are different beasts.

Also note that the OP said nothing about C, assembly, or any particular architecture (actually, he didn't say much of use at all). In many other languages there are much bigger differences between arrays and pointers, and they can't be cast around as they can in C and assembly (assuming the common C and assembly implementation). For example, BASIC has arrays but no pointers, and while Forth has pointers, I don't think it has arrays (but I could be wrong there). Strongly typed languages will not let you mix array access and pointers, and some languages may implement arrays in completely different ways (such as using a linked list).

In short, you use an array to store a block of data containing a number of items of the same type (some languages do not even have that requirement), while you use a pointer to store the address of or a reference to an object.

The phrase "allocating memory and then using a pointer" has no implication of using "malloc". Statically allocated data is still "allocated", by the linker rather than at run time. Of course, it's still wrong - arrays are sequences of data, a pointer is a variable that holds the address of something.

I'd expect that compilers for targets with 16-bit addresses would fail, but compilers for targets with 32-bit (or more) addresses would be perfectly happy. Any compiler which arbitrarily fails for a particular size of array that is within the addressing range of the target, is broken.

Many languages (including lots of C implementations) restrict index type to an int as 16 bit (often as signed), not as a function of the processor but as a function of reading specs and often BAD implementation.

When you start looking at arrays like grabbed frames, most of the work being done is on regulary step basis 1,2, line, column etc. which means often it is easier to treat as a linear block and do simpler pointer arithmetic. Compare this with treating it as a 2D array and I have seen some hosts have horrendous code bloat to deal with the translations.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

Yup.

I remember a long time ago on a 32-bit computer at university doing something like: malloc(1024*1024*64) to see what would happen.

The hard disk started making crunching noises for a very long time while my program paused. Though had read about virtual memory, I hadn't really expected it to *actually* try to go get all that memory!!!. :)

-Le Chaud Lapin-

You'd have to refer to comp.lang.c for the full story, I suppose. But normally compilers processors with 32-bit pointers have size_t as a

32-bit unsigned int, and can therefore have array indexes up to 32-bit (I believe, but am not certain, that it is size_t that is the controlling type here, not int). Occasionally, you might use a 16-bit int model on a 32-bit address target, I suppose. You certainly meet a similar situation on 64-bit targets with 32-bit ints, and I'm fairly certain that you can have 64-bit indexes with such programming models.

Are you sure you did not call something like calloc(1024*1024, 64), in which case such behaviour would be perfectly justifiable, especially if a lot of dynamic memory had previously been freed and is now allocated again using calloc, thus forcing page-in from the page file to clear the pages.

Of course any virtual memory system with the concept of multiple users should be able to deliver zeroed pages just for security reasons, without storing these pages into the page file at this time.

A dynamic memory system should be able to detect that when implementing calloc if the pages have already been used and hence require zeroing or if pages are zeroed virgin virtual memory pages returned by the OS.

Paul

Good question; I didn't think of that.

I'm pretty sure I used malloc, as I hardly ever use calloc. But now that you mention it, I am thinking that I might have allocated the memory statically in a global array

-Le Chaud Lapin-