Need funcion to return char[]?
I mentioned this in another thread, and this is a common tripping point, but an array isn't really a variable, its just a trick to look like one. At the end of the day, an array is just syntactic sugar over a continuous block of memory.
That's incorrect. An array is a type that's distinct from the concept of a continuous block of memory. In particular, dynamic arrays returned by new or malloc (and other functions) represent continuous blocks of memory, but are not of array type. Arrays are just a somewhat inconsistant feature of C/C++. It's not sugar.
But it's true that arrays behave differently from other variable types.
What do you suppose an array is then, if not a continuous block of memory?
That's incorrect. An array is a type that's distinct from the concept of a continuous block of memory. In particular, dynamic arrays returned by new or malloc (and other functions) represent continuous blocks of memory, but are not of array type. Arrays are just a somewhat inconsistant feature of C/C++. It's not sugar.I mentioned this in another thread, and this is a common tripping point, but an array isn't really a variable, its just a trick to look like one. At the end of the day, an array is just syntactic sugar over a continuous block of memory.
But it's true that arrays behave differently from other variable types.
What do you suppose an array is then, if not a continuous block of memory?
That's incorrect. An array is a type that's distinct from the concept of a continuous block of memory. In particular, dynamic arrays returned by new or malloc (and other functions) represent continuous blocks of memory, but are not of array type. Arrays are just a somewhat inconsistant feature of C/C++. It's not sugar.I mentioned this in another thread, and this is a common tripping point, but an array isn't really a variable, its just a trick to look like one. At the end of the day, an array is just syntactic sugar over a continuous block of memory.
But it's true that arrays behave differently from other variable types.
It's a type.
An array represents a monotonous aggregate of types in continious memory, but it is a type in its own right, and destinct from several other ways the same concept could be expressed.
Oh thanks. Upon closer inspection, I realized your first post already said an array is a type. I guess I was paying more attention to the "...distinct from the concept of..." part.
It's a type.
What do you suppose an array is then, if not a continuous block of memory?
That's incorrect. An array is a type that's distinct from the concept of a continuous block of memory. In particular, dynamic arrays returned by new or malloc (and other functions) represent continuous blocks of memory, but are not of array type. Arrays are just a somewhat inconsistant feature of C/C++. It's not sugar.I mentioned this in another thread, and this is a common tripping point, but an array isn't really a variable, its just a trick to look like one. At the end of the day, an array is just syntactic sugar over a continuous block of memory.
But it's true that arrays behave differently from other variable types.
An array represents a monotonous aggregate of types in continious memory, but it is a type in its own right, and destinct from several other ways the same concept could be expressed.
I would say an array is a type, an array variable is a variable, and is also a contiguous block of memory.
One of the few situations where a programmer will see an actual difference is references.
void func( int(&a)[10] ) { ... }
This will take an actual array, it must contain ints and it must be size 10. The last part is what often makes it useless in practice compared to "(int* a, size_t num)".
I mentioned this in another thread, and this is a common tripping point, but an array isn't really a variable, its just a trick to look like one. At the end of the day, an array is just syntactic sugar over a continuous block of memory.
That's incorrect. An array is a type that's distinct from the concept of a continuous block of memory. In particular, dynamic arrays returned by new or malloc (and other functions) represent continuous blocks of memory, but are not of array type. Arrays are just a somewhat inconsistant feature of C/C++. It's not sugar.
But it's true that arrays behave differently from other variable types.
Exactly what distinction exists about arrays that does not amount to syntactic sugar? I can use array subscript notation to navigate through newed/malloced memory, and I can use pointer arith to navigate static/stack based arrays. As far as I'm aware, all of the inconsistencies of array notation in C\C++ are a result of the fact that, under the covers, arrays are just pointers to a block of data, however that data is allocated, and array subscript notation is just another form of dereferencing that pointer.
There's a subtle difference between a variable being a block of memory and a variable being a pointer to a block of memory, which is best illustrated by looking at the assembly generated when you access the two. Consider this code:under the covers, arrays are just pointers to a block of data
void foo(int);
int main(int, char **) {
int a[5];
foo(a[1]);
}
The relevant bits of the assembly of the function call look like this under MSVC x64:
mov ecx, DWORD PTR a$[rsp+4]
call ?foo@@YAXH@Z ; foo
Change the array to a pointer and the generated assembly changes:
mov rax, QWORD PTR a$[rsp]
mov ecx, DWORD PTR [rax+4]
call ?foo@@YAXH@Z ; foo
With the variable declared as an array, you can get the address of the array member by adding to the stack pointer. With the variable declared as a pointer, you need to load the value of the pointer and then get the address of the member. Under the hood, arrays and pointers behave somewhat differently. Of course C does your best to confuse you about the difference between pointers and arrays by doing things like implicit decay and argument type transformation, which C++ unfortunately inherits.
Thanks for the example SiCrane. That's definitely more than syntactic sugar. I'm curious to know though if that is per the C spec, or a compiler optimization.