Returning Array

Hi all,

please correct me if i make a stupid statement....

I know/think i know its not possible to explicitly return an array within C. However i am undert the impression that it is possible to do so using pointers. Ive had a read of various tutorials but none of which really have helped me in what im trying to do.

Im trying to....

1. pass an array to a function,

2. manipulate the array data

3. return the array back to main

thats the simplest way i can describe it i think. I have provided the required sinpets from my main function and the function that i want to edit my array elements.


heres what ive tried......fairly certain its rubbish but what the hell... if some one could help me clear this one up id be very greatful

thanks

Baffa

Code:

---

void MixColumns(int *ptr[], int size){

int r[4];


r[0] = ptr[0]*2 + ptr[12] + ptr[8] + ptr[4]*3;

r[1] = 2*(ptr[4]) + ptr[0] + ptr[12] + 3*(ptr[8]);

r[2] = 2*(ptr[8]) + ptr[4] + ptr[0] + 3*(ptr[12]);

r[3] = 2*(ptr[12]) + ptr[8] +ptr[4] +3*(ptr[0]);


ptr[0] = r[0];

ptr[4] = r[1];

ptr[8] = r[2];

ptr[12] = r[3];


return ptr;

}

int main (){


int current_state[16];

int *ptr = current_state;

current_state = MixColumns(ptr, 16);

return 0;
}

---

When an array is passed as an argument, it decays to a pointer to its first element. Consequently, modifying the elements of the array passed modifies the elements of the array from the caller. In that sense, returning the array would be unnecessary.

Remove the line saying "return ptr" and you should be good to go. Of course, you are also not using the size, so that's not needed - it's a good thing to pass the size, but it makes no sense to pass it if all you do is ignore it.

--
Mats

you what? so i dont need to return it anyway? you saying to just use a void function or somthing because when the array data is modified in the function?


Oh poo ive realised i put void instead of having


int MixColumns(int ptr[], int size){......

Yes, your code, as it stands, updates the info inside the array.

--
Mats

Code:

---

line 57: error: expression must have arithmetic or enum type

  r[0] = ptr[0]*2 + ptr[12] + ptr[8] + ptr[4]*3;

                                                        ^

---

im getting a lot of these errors throughout the code on compliation.

Is there somthing im doing wrong to manipulate the array elements?

Quote:

---

Originally Posted by baffa

Code:

---

line 57: error: expression must have arithmetic or enum type

  r[0] = ptr[0]*2 + ptr[12] + ptr[8] + ptr[4]*3;

                                                        ^

---

im getting a lot of these errors throughout the code on compliation.

Is there somthing im doing wrong to manipulate the array elements?

---

Unless this is a 2-dimensional array you're passing, change the function to:

Code:

---

void MixColumns(int *ptr, int size){

---

You are passing an array of pointers. You probably want to change "int *ptr[]" to "int ptr[]".

woow that was awesome.....i only get this now any ideas? i dont what an lvalue is?...

Code:

---

error: expression must be a modifiable lvalue

  current_state = MixColumns(ptr);

---

MixColumns() is now declared as returning void, right? As such, you cannot assign its return value to current_state is there is no return value.

ye but what i wanted to do was then return the data in the mixcolumns function to the current_state column. sorry thats my fault for being a bit vague. I did wonder how having a void function would do that :P

ye i want to assign the array elements in the mixcolumns function to the current state array in main. How would i do that?

Quote:

---

ye i want to assign the array elements in the mixcolumns function to the current state array in main. How would i do that?

---

What is the ptr variable for? It looks like you want to write:

Code:

---

MixColumns(current_state);

---

I used ptr as the pointer to the array as I thought that i needed to use that to reference the array and return it.

can there be a case where i can have this in my main function?

Code:

---

current_state = MixColumns(current_state);

---

thats is ideally what i want but i dont know how i can return the amended array to update current_state.

Quote:

---

can there be a case where i can have this in my main function?

---

Yes, but as stated you do not need to return from MixColumns().

Quote:

---

Originally Posted by laserlight

When an array is passed as an argument, it decays to a pointer to its first element. Consequently, modifying the elements of the array passed modifies the elements of the array from the caller. In that sense, returning the array would be unnecessary.

---

I agree (of course) and I like the word "decay"! That's exactly what happens.
It should be pointed out (I'm sure it's in the FAQ) that it only happens to the first dimension of a multi-dimensional array. The other dimensional information is useable in the callee at compile-time. For example, the following works no matter what the size of the extra dimensions.

Code:

---

int addem3d(int a[][2][2], int size) {
    int sum = 0;
    for (int i = 0; i < size; ++i)
        for (int j = 0; j < sizeof(*a)/sizeof(**a); ++j)
            for (int k = 0; k < sizeof(**a)/sizeof(***a); ++k)
                sum += a[i][j][k];
    return sum;
}

---

The whole passing array is silly. You're just passing a pointer plain and simple. Always. There's no passing array, just passing a pointer. So if you think like that, there's no decaying in the first place.

Quote:

---

The whole passing array is silly. You're just passing a pointer plain and simple. Always. There's no passing array, just passing a pointer. So if you think like that, there's no decaying in the first place.

---

I am not sure about C, but the C++ Standard states quite clearly that an array to pointer conversion is performed. If you are not passing an array, such a conversion does not make sense. As such, I conclude that one is indeed passing an array, but this array is converted to a pointer to its first element.

I don't know why they're making such a fuss about it. Why be able to pass an array when you're just passing a pointer?
Anyway, that's how I see it, in my humble opinion.

Quote:

---

Why be able to pass an array when you're just passing a pointer?

---

Simply because you are not passing a pointer, unless what you pass really is a pointer to an element in the array. Consider:

Code:

---

#include <stddef.h>

void foo(int *y, size_t size);

int main(void)
{
    int x[10];
    foo(x, 10);
    return 0;
}

void foo(int *y, size_t size)
{
    // ...
}

---

Within main(), x is an array of 10 ints. Within foo(), y is a pointer to an element (the first, in this case) of an array of size (10, in this case) ints. But we call foo(x, 10), hence we are passing x, which is an array, not a pointer. Thus, array to pointer conversion is performed (i.e., the array decays to a pointer to its first element).

To claim that we are just passing a pointer is to insist that x is a pointer when it really is an array.

I could as well argue that an array is just a pointer. A pointer to a contiguous memory space with allocated space for 10 ints.
We can just as well do x[5] on a pointer as well as array, which would mean to me that an array is just a pointer. There's no bounds checking on either.
Therefore, an array is a pointer, so you are passing a pointer, not an array.
That's my take on the whole situation.

Quote:

---

I could as well argue that an array is just a pointer.

---

So you claim that sizeof on an array and sizeof on an equivalent pointer will always be the same?

No, but when it's an array, the compiler knows the size, because you defined it locally, thus the compiler can look back and find the size.
It's not really possible to pass an array in my opinion. If we could, then the compiler should be able to know the size of the array at all times.
It's similar, because when you do sizeof("My string"), it won't return the same as sizeof(cosnt char*), but "My string" is basically a const char*.
The standard could say what it wants, it's in no way wrong, but this is my belief on the whole.

Quote:

---

No, but when it's an array, the compiler knows the size, because you defined it locally, thus the compiler can look back and find the size.

---

As such, arrays and pointers are not the same. An array is not just a pointer. However...

Quote:

---

It's not really possible to pass an array in my opinion. If we could, then the compiler should be able to know the size of the array at all times.

---

I think you're looking at things under the hood, so to speak. If we look from the view point of C and C++ an array is not a pointer, even though that is what it really is when it comes down to it. So passing an array actually involves passing a pointer, but because (in this case) what we pass is not of a pointer type, we say that we pass an array and there is an array to pointer conversion.

My main objection to stating that "There's no passing array, just passing a pointer." is that it is misleading: if the caller passes a pointer, the caller has a pointer, so arrays are pointers. Yet from your own observation "when it's an array, the compiler knows the size, because you defined it locally", so there is the implication that arrays are not pointers. This would then be a contradiction, unless we talk in terms of array to pointer conversion.

Quote:

---

It's similar, because when you do sizeof("My string"), it won't return the same as sizeof(cosnt char*), but "My string" is basically a const char*.

---

No, "My string" is a const char[10], not a const char*.

When I think of arrays, I think of pointers. There may be some slight technical difference under the hood, but from my point of view, they act the same (except sizeof) so they are the same.

Quote:

---

Originally Posted by laserlight

I think you're looking at things under the hood, so to speak. If we look from the view point of C and C++ an array is not a pointer, even though that is what it really is when it comes down to it. So passing an array actually involves passing a pointer, but because (in this case) what we pass is not of a pointer type, we say that we pass an array and there is an array to pointer conversion.

My main objection to stating that "There's no passing array, just passing a pointer." is that it is misleading: if the caller passes a pointer, the caller has a pointer, so arrays are pointers. Yet from your own observation "when it's an array, the compiler knows the size, because you defined it locally", so there is the implication that arrays are not pointers. This would then be a contradiction, unless we talk in terms of array to pointer conversion.

---

So let's put it a little more clearly, perhaps. The array is a pointer, since you can easily do

Code:

---

char str[10];
char* pStr = str;

---

And if you would do sizeof(pStr), you would just get 4 (on x86), of course, because the compiler looks at the name as sees it as a pointer.
For sizeof(str), the compiler sees a pointer with which you have told it to allocate a number of elements, thus it can return the correct size.

I see it as [] is a special syntax for declaring a pointer to a memory space on the stack which holds space for n elements.

Quote:

---

No, "My string" is a const char[10], not a const char*.

---

Well, perhaps in language terms it is, but a string (C-style) is just a char* to me. But since you have specified how many characters are in the string, the compiler can deduce the size.

By not having an "array," just pointers, it's easy not to confuse arrays and pointers and how an array would decay to a pointer.
It's how I see it anyway.

Quote:

---

By not having an "array," just pointers, it's easy not to confuse arrays and pointers and how an array would decay to a pointer.
It's how I see it anyway.

---

I can see where you are coming from, i.e., you are saying that you find it simpler to just think of the array as a pointer, despite the (minor) language imposed differences.

Frankly, I do not really care either way, since these are just different ways of looking at the same thing. I do care that you were contradicting me to the point of calling my statement "silly" without stating that this was just how you viewed it, but now that it is out in the open I have nothing to add :)

Quote:

---

Originally Posted by laserlight

Frankly, I do not really care either way, since these are just different ways of looking at the same thing. I do care that you were contradicting me to the point of calling my statement "silly" without stating that this was just how you viewed it, but now that it is out in the open I have nothing to add :)

---

Ah, right, so when calling something silly without backing it up with why is a bad idea? :)
I also have a loop that uses goto to break out of it actually, with no breaks at all and lots of continue. It's a larger big loop. Perhaps it could be broken into smaller parts someday.