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.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.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
Simply because you are not passing a pointer, unless what you pass really is a pointer to an element in the array. Consider:Why be able to pass an array when you're just passing a pointer?
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).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) { // ... }
To claim that we are just passing a pointer is to insist that x is a pointer when it really is an array.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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.
So you claim that sizeof on an array and sizeof on an equivalent pointer will always be the same?I could as well argue that an array is just a pointer.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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.
As such, arrays and pointers are not the same. An array is not just a pointer. However...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.
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.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.
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.
No, "My string" is a const char[10], not a const char*.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*.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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.
So let's put it a little more clearly, perhaps. The array is a pointer, since you can easily do
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.Code:char str[10]; char* pStr = str;
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.
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.No, "My string" is a const char[10], not a const char*.
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.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.
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
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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.