# pointers or arrays

## Recommended Posts

Well I'm up to the pointers lesson on cprogramming.com and I'm also reading a book the book has arrays before pointers and this site has it the opposite.Which should I learn first?Thanks in advance.

##### Share on other sites
Arrays are very basic and easy to understand, I would learn them first than pointers.

##### Share on other sites
Quote:
 Original post by JettozArrays are very basic and easy to understand, I would learn them first than pointers.

thank you

##### Share on other sites
Arrays.. pointers you will "learn" about 20 times before you learn them .. hehehe

##### Share on other sites
It really isn't possible to learn about one without the other. Anyway, there are more sophisticated tools (that will prevent you from making mistakes and frequently require less effort to learn and use) for almost every circumstance in which either would apply.

##### Share on other sites
Well, arrays are basically pointers in a nifty coat, so starting with pointers might be a better way to go.

Though, TBH, it really doesn't matter. Once you have grasped both concepts (which aren't too difficult), the order you grasped them in won't make any difference.

##### Share on other sites
It's funny — I can handle pointers perfectly well, but arrays still sometimes give me trouble. I guess everyone has their own weaknesses.

I second Zahlman's suggestion, though I do not agree about his initial statement: why are arrays necessary for understanding pointers?

##### Share on other sites
Pointers are the trickier concept. In C++ pointers have an elegant interface/implementation but arrays don't. Well actually no, the pointer declaration syntax is counterintuitive in C++ but you soon learn to ignore it. So if you think that you are really smart then I would go with pointers first, otherwise I would go for arrays first.

##### Share on other sites
Quote:
 Original post by GlakWell actually no, the pointer declaration syntax is counterintuitive in C++ but you soon learn to ignore it.

In fact, the entire C type system is like that, and C++ has kept most of it as legacy. See also cdecl.

##### Share on other sites
Quote:
 Original post by ToohrVykIt's funny — I can handle pointers perfectly well, but arrays still sometimes give me trouble. I guess everyone has their own weaknesses.I second Zahlman's suggestion, though I do not agree about his initial statement: why are arrays necessary for understanding pointers?

Um, I didn't really think that one through :)

##### Share on other sites
Pointers tend to be harder to grasp in HLLs then lower level languages.
(In C++, I think its the synthax that makes it more difficault)

Arrays are pointers, as stated before. However, I do recommend
learning arrays first to get a better understanding of pointers,
then moving onto pointers themselves[smile]

##### Share on other sites
It doesn't really matter what order, as long as you learn them eventually. In fact, why not learn them at the same time? Personally I didn't learn how arrays and pointers were related until quite some time (well I was brought up with BASIC so I was shielded from the harsh reality!). Once you learn about pointer arithmetic you can appreciate how arrays work. But I learnt them as seperate topics, then found out how they were related later, and I'm just fine! :P

##### Share on other sites
The concept of arrays is much easier to understand. So learn that first, the concept as in how to basically use them.

Like others have said, arrays are just a wrapper for pointers, but pointers are much more complicated that arrays.

You'll be doing it all in the end anyway, so maybe even do

arrays -> pointers -> arrays -> pointers + arrays.

##### Share on other sites
Quote:
 Original post by CrypterArrays are pointers, as stated before.

Nuh-uh. There are some fundamental differences. An array does decay to a pointer, but if you wish to keep it intact, you will have to do some non-pointerish work at every corner in your program (typedef, reference-to-array, encapsulating in a structure) and gouge your eyes out once you start handling multidimensional arrays and try to write generic array manipulation functions.

I believe the main reason why people think arrays are so easy to manipulate, is because they take the obvious shortcut of transforming the array into a pointer at the first occasion they get (through decay) and then manipulate the pointer. Which would further prove the point that pointers are easier to understand and use than arrays.

Because, strangely enough, the fundamental operation that any programmer would expect to be able to do, which is passing an array to a function, actually takes a decent amount of mind-bending before you actually get it right. You know, without losing that number of elements in array property that C arrays have, but pointers don't.

And don't even get me started on returning arrays from functions.

Zahlman — :P

##### Share on other sites
Quote:
 Which would further prove the point that pointers are easier to understand and use than arrays.

I cant see how you think pointers are easier to understand than arrays. Especially when getting to rvalue, lvalue and endianess.

##### Share on other sites
Quote:
 Original post by RandEspecially when getting to rvalue, lvalue

rvalue and lvalue are a sick, sick terminology which is sadly overcomplicated by the both imperativeness of C, and a long history of bad teaching — I mean, even us language semanticians sometimes get these notions mixed up, and we're the ones who design languages in the first place, so are you going to use them to teach about C?

I must admit, I only managed to get the explanations of these two terms when I stared at OCaml code for thirty seconds. OCaml has "values", and some of these values, called references, "reference" other values. A C or C++ variable is a reference from OCaml: it is a value (the rvalue) and references a value (the lvalue). Then, a C pointer and a C++ reference is a value which references a reference (its lvalue is the rvalue of another varable, in ugly-C-speak), except that C pointers have value semantics while C++ references have reference semantics.

Right, so that might not be clear to someone who isn't familiar with OCaml. So, let's put it the way that so many books put it: you have values. You have addresses, which are a special type of values (along with integers, characters, and so on). All addresses are associated with values (the value stored at that address), although some values (such as constants or temporaries) might not have an address. Using an address, you can apply a dereference operation which allows you to read and/or modify the associated value. A variable x is an explicit association between an address (expressed as the constant expression &x) and a value (expressed as the possibly mutable expression x). An address is called an rvalue, a value is called an lvalue (silly names, and not perfectly true — take a peek at your language standard for the actual exact definitions). A pointer is a type of variable which stores an address, and has a nifty *p notation for the dereference operation.

Quote:
 endianess

Now, I may be missing something, but what does this have to do with pointers, but not with arrays?

##### Share on other sites
Quote:
Original post by ToohrVyk
Quote:
 Original post by RandEspecially when getting to rvalue, lvalue

I understand what they are. I'm saying they are more confusing than using arrays. This is about which are easier to learn first, array vs. pointers.

Quote:

Quote:
 endianess

Now, I may be missing something, but what does this have to do with pointers, but not with arrays?

Its only significant if using the debugger to track whats happening in memory, on 2 differing endian machines. Byte and Word order is opposite for different endians. So if you start messing around with byte/word/long pointers, then the data appears out of order. This isn't applicable with arrays of such types. Especially because you cant cast a byte array to a word array etc.

##### Share on other sites
Quote:
 Original post by RandI understand what they are. I'm saying they are more confusing than using arrays. This is about which are easier to learn first, array vs. pointers.

This was precisely my point, so I'll try to express it again: rvalue and lvalue are a lousy, overcomplicated, outdated, legacy way of explaining pointers to C programmers. If your C++ manual or teacher attempts to explain things this way, find a better book to understand what pointers are (preferably one which starts with C++ references, and derives pointers from there), and only then attempt to understand what rvalue and lvalue are.

Besides, as I've stated above, it's been ages since I've been confused by anything a pointer does, but I still sometimes have a block when trying to pass an array to a function. My impression still is that you can do almost the same things with both arrays and pointers, but the array version of these operations is so hauntingly complicated that the complex operations only ever get done with pointers anyway — which leads people to believe that they're the complicated ones.

Quote:
 Its only significant if using the debugger to track whats happening in memory, on 2 differing endian machines. Byte and Word order is opposite for different endians. So if you start messing around with byte/word/long pointers, then the data appears out of order. This isn't applicable with arrays of such types. Especially because you cant cast a byte array to a word array etc.

I'd look at this another way: if someone taught you that you could reinterpret_cast without knowing what you're doing, then that someone is guilty. In particular, the standard states that the memory representation of basic types is subject to endianness issues, and that this subsequently reflects to exploring such types as sequences of bytes. This is mainly a memory layout issue though, and has about as much to do with pointers as it has to do with arrays. And yes, you can cast a word array to a byte array in C++:

int a_words[10] = {0};int *p_words = a_words;// word-to-byte pointer conversionchar *p_bytes = reinterpret_cast<char*>(p_words); // word-to-byte array conversionchar (&a_bytes)[40] = reinterpret_cast<char (&)[40]>(a_words);

##### Share on other sites
Quote:
 Original post by ToohrVykint a_words[10] = {0};int *p_words = a_words;// word-to-byte pointer conversionchar *p_bytes = reinterpret_cast(p_words); // word-to-byte array conversionchar (&a_bytes)[40] = reinterpret_cast(a_words);

Assuming ints are 4 times the size of chars ;):

size_t const newSize = sizeof( int ) * 10;char (&a_bytes)[newSize] = reinterpret_cast< char (&)[newSize] >( a_words );

On the pointer vs. arrays debate, I tend to think learning pointers first is actually necessary. What does array decay even mean to someone who hasn't learned about pointers?

jfl.

##### Share on other sites
Fair enough Toohrvyk.

I was just going off my own personal experience of when i learnt, and yes it was the old horrible C way 15 years ago.

I just found arrays easier aswell coming from basic since they exist in that too.

##### Share on other sites
Quote:
 Original post by jflangloisAssuming ints are 4 times the size of chars ;)

Yes, of course. [grin]

##### Share on other sites
Thanks everyone your posts have been a great help.I gues I'll learn them both.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628379
• Total Posts
2982354

• 10
• 9
• 15
• 24
• 11