Thread: Returning Array

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.

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.

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.

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.

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...

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.

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*.

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.

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.

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

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.