Differance between Array and Pointers

As an wmbedded Engineer which one to prefer Array or Pointer , and why ?

Reply to
hsk2kor
Loading thread data ...

As an wmbedded Engineer which one to prefer Array or Pointer , and why ?

Reply to
hsk2kor

I try to avoid pointers and dynamic memory. The allocation and deallocation is a timing issue that is not constant, nor simple to calculate.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
Reply to
Rene Tschaggelar

The choice entirely depends on what you are trying to achieve. What is is that you want to do?

Reply to
Tom Lucas

You should prefer an Array when you need an array. If you need a pointer, then Pointer is definitely preferable.

Because

--
Grant Edwards
grante@visi.com
Reply to
Grant Edwards

Which are completely different things. I too avoid dynamic memory like the plague, but without pointers, some of my products would not work because indices take too long to calculate.

Meindert

Reply to
Meindert Sprang

??? - That's like asking if I prefer a bolt or a nail. Without providing some context on the intended application, the question is meaningless.

Reply to
Roberto Waltman

Theres is no difference at the hardware level(unless the hardware implements arrays). Arrays are just collections of contiguous memory and are usually handled by the compiler behind the scenes. Points give you the lowest level of access. But guess what? the compiler converts all array access into pointer access.

For example, In Intel 80x86 there is no "array" opcode and "pointer" opcode. All memory access no matter what it is, is done through the mov instruction(well, there are a few other specialized instructions but it doesn't change the point). So in reality there are no arrays by your definition(by assuming they are different than pointers) at this level. What makes them different is just what someone else(The compiler) does for you to make your life easier... the same thing happens with structs, classes, functions, static and dynamic memory, etc... They are all tools implemented by a HLL to make your life easy and make all the guts of the hardware transparent to you. (For example, "arrays" can have bounds checking implemented by the compiler while for pointers it cannot unless you do it manually(i.e., you implement what the compiler does for arrays). But the difference is not between arrays and pointers).

So it all depends on what you are trying to do and what you need to do.

Reply to
Abstract Dissonance

How many compilers would baulk or compile wrongly for 0.5MB array or larger as in a grabbed video frame.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Click to see the full signature
Reply to
Paul Carpenter

Well, except that arrays tend to be much larger than pointers, and the number of access cycles is different.

An array is a contiguous region of memory containing N elements of M bytes each.

A pointer is a (usually) 2-8 byte value which contains the address of some other data.

Maybe you're confusing addresses with pointers?

Er, no? When you pass an "array" to a function, it passes a pointer to the array instead, but other than that the compiler does not convert arrays into pointers. In fact, if you have a const array and reference one element with an integer index, the compiler might optimize the whole access away if it can.

It does, however, have different addressing modes that are optimized for arrays vs pointers.

Arrays: x = foo[j] mov.l foo[4*esi],eax

Pointers: x = *foo; mov.l [ebx],eax

Reply to
DJ Delorie

Umm. An array is a "virtual region of memory". Can you access more than one element at a time? How do you access regions of memory at the lowest level?

Nope.

Arrays are "virtual" objects and are not part of the hardware design(atleast in every MP I've seen). If you are talking about an "array" you are just talking about a region of memory that you have considered to be a group of elements. How do you access those elements(at the lowest level)? Through a "pointer".

Nope. Thats jut a pointer using scaled indexing.

I suppose that we have different concepts of pointers. You are treating indexing as arrays while I see them just as pointers. I don't see a pointer as necessarily a fixed address and don't consider offsets to that pointer an array.

Could be my fault but I just don't see any technical difference. My there is a very specific definition of a pointer?

would you consider

rep movs

as an array or a pointer reference?

The way I see it is that index and offset referencing are just making pointers easier to work with. I guess you can call that method arrays if you want to but I don't see any reason to make up a new word for something that is suitiable in IMO.

If you apply your same logic to classes then you should be able to demonstrate the ability to work with "efficiently" with classes at the low level. It all ends up boiling down to "pointers" in the end no matter how you look at it.

I suppose one could make a distinction to represent which "method" is more efficient. (i.e., its generally better to use a rep then a loop or using indexing vs. a loop). To me these are just means to make life easier when working with pointers then constituiting a whole knew type of data. (i.e., arrays are just logical groups of bytes but no hardware I know of implements a hardware data type called an array.).

I think we are arguing over semantics though. If the OP ment what you ment then the obvious question is to go with what is most efficient(or, atleast should be).

If someone is going to do something like

Loop1: mov edi, [esi] add esi, 4 loop Loop1

when they can just do

rep movsd

Then theres a serious problem(unless they intentionally chose the first one for some good reason)

Both methods are the same, one uses pointers and the other "arrays"(Atleast I think you will say that). To me they are exactly the same(i.e., they accomplish the same task.. one is more efficient though).

Its similar to using a loop method

loop Some_Loop

or

dec ecx jnz Some_Loop

They are exactly the same. Intel could have implemented loop as a macro and just used the longer code. I definately wouldn't give the two "different" methods a different name unless there was a good reason(and there might be).

I could be wrong though but I don't see what you have stated above as any good reason making such a distinction. (i.e., a one that warrants any real discussion over). If there is a good reason then, by all means, please enlighten me.

As far as I'm concerned, Any time one has to do memory access then they are working with pointers(directly or indirectly). In Masm/Tasm/Nasm that consists of using any [ ] or any instruction that does that "indirectly"(i.e., where there is an equivilent piece of code that uses [ ]). You can call certain methods arrays and others pointers if you want but I don't see any need. (because there is an equivilence and there is no physical data element called an array in any hardware architecture I know of(one has bytes, bits, nibbles, words, pages, etc...).

Although I guess one could take this equivilence idea to far and end up doing everything with just one instruction and end up saying there is no use for anything else.

Reply to
Abstract Dissonance

To me, a pointer is a variable in memory that contains the address of something else. I.e. a pointer has a value which is an address, and the pointer itself has an address. To use a pointer, you first have to load it from memory into a register, then use it to load the something else into memory.

An array is the big chunk of memory itself. You can have a pointer to an array, and the array has an address. If you put an array inside a structure and pass the structure to a function, the array is passed by value - not by passing its address.

Likewise, an integer is a small hunk of memory. You can have a pointer to an integer, and the integer has an address.

Consider:

char *foo = "hello"; char bar[] = "hello";

On a 32 bit system, foo is a pointer - a 4 byte variable which initially contains the address of an array of chars which takes up 6 bytes. Bar, however, is a 6 byte variable that *is* an array of chars.

Reply to
DJ Delorie

Pointers reach conceptually anywhere, indices are used to access an array (at least conceptually, if we consider overloaded []). So in the case of arrays, we have a choice of accessing its elements by pointers or by indices. E.g., void my_p_memcpy(char *dst, const char *src, size_t count) { while(count-- != 0U) *dst++ = *src++; } void my_x_memcpy(char dst[], const char src[], size_t count) { for(; count != 0U; count--) dst[count-1U] = src[count-1U]; }

All other things being equal, consider two things:

- instruction set

- compiler habits and one more thing:

- code readability and suitability for static analysis

Some processors are great pointer machines, some do better with indices. If you write in Assembler, you've got to observe this stuff. If you write in an HLL, the compiler may take advantage of the instruction set or defeat its benefits. But then, it may depend on a context, and a good optimizer would make a better choice. E.g., I've seen the compiler replace my index arithmetic with pointers, completely optimizing out a loop counter. The key is not to write "clever" code so the optimizer can decompose it into cliches it knows about.

Indices are usually better readable than pointers, although the memcpy above is a counter-example. Code analysis tools may be better in finding the "voted most popular" off-by-one error if it knows array sizes passed to the functions, in which case indices may be more natural. Especially with variable-length arrays as in FORTRAN or C99.

Regards, Ark

Reply to
Ark

Well umm if you are allocating chunks that are always the same size it would be stupid to use something like malloc. But if the sizes are all completely random then nothing is going to be better than malloc and you CAN figure out the worst case cenerio for time.

This reminds of the playstation portable. People were doing things like while(1) {malloc(1) i++}. The system had 32MB memory but i would randomly get to between 8,000 and 9,000 because of all the overhead and the way a kernal runs in the background.

Reply to
DAC

I usually prefer a array or stack of pointers but then again it really depends on what you are talking about. After all an array really is just allocating memory and then using a pointer. No real difference.

Reply to
DAC

Except that arrays are usually statically allocated.

FWIW: the use of pointers says nothing about malloc. Malloc uses pointers, but pointers needn't use malloc.

Steve

formatting link

Reply to
Steve at fivetrees

I guess you feel that a pointer is sorta "fixed" in some sense while I think it is sorta of variable. when I see bar[] I do think of it as an array but I also sorta think of it as a pointer. I don't see a huge difference. I suppose its becaue I used to program more heavily in assembly and that was my language of choice.... there I believe arrays are much less definite than in HLL's because they are really just pointers to memory addresses. Maybe I just never really thought about them as being arrays but just "dynamic pointers"(instead of something like a pointer with a fixed value that doesn't change throughout the program or changes very little).

For example, you could have a pointer to a location in memory and it could "virtually" point to an array... theres no way to tell what kinda data its pointing to. You just have to know. In C you always know because when you define the data type you are telling C to syntactically treat it as an array(and mainly what it tries to do is bounds checking and allocation). So in C there is a difference in the sense that it will do some things for you behind the scenes but in assembly that doesn't happen and so there is really no distinction. Atleast thats the way I look at it.

In your example above I just see two pointers to the "array" of characters. The first one doesn't have automatic bounds checking while the second one does. The first one also makes it harder in C to handle the array elements... but if you had to do it in assembly both definitions would be equivilent.

i.e.,

str db "Hello", 0 foo dw OFFSET str

if I wanted to get the 3rd element I could do

add foo, 2 mov al, [foo]

but that changes the location of foo so I could want to first copy foo to a temp address. (so in your sense foo is acting as a pointer)

or I could use a temp variable and indexing

mov si, foo mov bx, 2 mov al, [bx + si]

and you would call that an array(basically)

but to me they are the exact same but just different ways of doing it. The first way isn't a good idea unless you don't mind destorying foo's address(but ofcourse its easy to fix in this case by just subtracting what you changed or pushing foo onto the stack).

The second method makes it so one doesn't have to worry about screwing up foo and is more array like.

I think I do see what you mean though. One can define an array to be "A group of sequential data" and then its surely different from a pointer. But since when a pointer points to something you treat it how ever you want (as an array, integer, float, etc...) then it makes it more ambiguous. In HLL's they remove this ambiguity but in assembly its always there and sometimes useful. I guess I'm just so used to thinking about arrays and pointers together that I think they are the treat them in the same context. Its just that you can't really have an array without a pointer and technically you can't have pointers without arrays(since you can't quantify what its pointing to(atleast in assembly)).

Jon

Reply to
Abstract Dissonance

Well, I write compilers for embedded systems for a living. There's a huge difference.

Everything has an address. A pointer is a variable whose value is interpreted as an address. You can call them different things if you want, but nobody will understand you because everyone else uses my definitions.

No.

bar db "hello",0 .L45 db "hello",0 foo dd .L45

foo is a pointer. bar and .L45 are arrays. foo, .L45, and bar are all addresses.

mov al, 3[bar] vs mov ebx,foo mov al, 3[ebx]

Reply to
DJ Delorie

umm... ok... I guess theres no use arguing then...

So show me how to look at a com file and determine the data types such as arrays from it without looking at the code itself or reverse engineering the code into source.

Then by your definition

bar1 db 'h'

bar2 db 'e' bar3 db 'l' bar4 db 'l' bar5 db 'o' bar6 db 0

is not an array? I know for a fact that you cannot see any difference between that and your bar at the machine level.... But yet I can treat the bar1,..,bar2 as an "array" simply by making a pointer to bar1 and using indexing to easily access an element... what is this method called then? How is it fundamentally any different from using bar db "hello", 0?

Whatever... show me on the intel hardware databook where they define a hardware data type of array?

Oh.. show me also how to use an array without using pointers, ok? Can you please make up some code to, say, increment the ith element by 1 without using pointers(i.e., [] memory addresses).

Seems to me you are arguing over how to say potato.

Reply to
Abstract Dissonance

Thank you for the lovely straw man. No.

mov eax, array[4*esi]

See? You're using the wrong definitions again. You can't increment the element without using its ADDRESS but you can do it without using POINTERS.

inc word ptr foo[2*esi]

Reply to
DJ Delorie

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.