Quote:Original post by Crypter
Arrays 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

Quote:Original post by Rand
Especially 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?

Quote:Original post by Rand
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.

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