Take the following two declarations "int arr[3]" and "int *ptr".
Both require different storage, but in usage both are identical. This behaviour is known, and it is not the consistency I am talking about.
Take the following two declarations:
void funcarr(int a, int arr[3], int c)
{ printf("%d\n", &c-&a); }
void funcptr(int a, int *ptr, int c)
{ printf("%d\n", &c-&a); }
For funcarr, all three arguments are intended to be call by value. So I would expect the stack to contain
a,arr[0],arr[1],arr[2],c
but it does not. The stack contains
a,&arr[0],c
This is *NOT* consistent, and gives a false impression that the elements of arr[] will not change within the lifetime of the function.
Who failed, so I knows whose ass to kick.
Name:
Anonymous2012-05-10 1:45
dennis ritchie, but he's dead lol. do you wanna kick his corpse?
>>14
In all my years of writing C this is the only point of contention I can see, and it does not affect me much because I always use structure pointers. The same issue comes up with returning structures and structure assignment.
From an implementation perspective it would be simpler to make the programmer do it themselves instead of essentially generating a hidden memcpy(). The latter seems like something closer to C++'s temporary object and hidden constructor/destructor calls.
Name:
Anonymous2012-05-10 7:13
>>2
dmr has said that the array / pointer interchangeability in function prototypes was inherited from BCPL, and that in retrospect keeping it around was probably a bad idea. His paper on the development of the C language calls it "a living fossil".
Name:
Anonymous2012-05-10 8:21
>>1 Both require different storage, but in usage both are identical.
No, they are not.
I see you're one of those faggots who are too stupid to figure out why their programs are being killed for producing segfaults.
>>5 If you expect a C array to be call-by-value then you are a moron and shouldn't be programming C anyway.
Call-by-value is the *only* thing C has. If you think that pointers are pass-by-reference, then please go back to scrubbing toilets, you mental midget. Now only if you'd know what the value of an array is...
Name:
Anonymous2012-05-10 12:46
protip: an array is not a type
Name:
Anonymous2012-05-10 14:54
C doesn't have first-class arrays. The names of arrays "decay" to pointers to their first elements. If you want to pass the contents of a fixed-length array by value, you need to put it inside a struct. Fortran, PL/I and ALGOL (all older than C) have first-class arrays and slices. These languages do not provide raw access to memory, so array bounds are stored as part of a hidden "descriptor" and passed to all functions that use the array. The "spirit of C" is not to hide anything from the programmer, so a C array is just a block of memory suitable for that data type. This is one of the reasons why C programs have so many buffer overflows.
It's an aggregate type which requires a base type to aggregate on. The same for pointers and structures.
Name:
Anonymous2012-05-11 7:49
>>24 We learn new things everyday
you can declare structs without fields so no base types
pointers do not require a base type since the base type does not affect it's behavior, it's just for warning issues, an address is an address
arrays default to allocation and a pointer type, it doesn't make sense to use an array in declaration of a parameter unless you want to stress out that it is isn't a pointer to something but actually an array of something: char ** argv vs char * argv[]
tl;dr: array declaration is pointer declaration with explicit space allocation
>>25 an address is an address
Someone hasn't read the CStandard and thinks x86 is all that's out there.
tl;dr: array declaration is pointer declaration with explicit space allocation
That makes as much sense as saying that int declaration is pointer declaration with explicit space allocation and automatic dereferencing. It's only partially correct and not meaningful.
Here's the most obvious demonstration of the difference between arrays and pointers:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
int ar[10];
int *pt = malloc(10 * sizeof(int));
>>25 you can declare structs without fields so no base types
No, that would be equivalent to a base type of void, like a function with no parameters.
pointers do not require a base type since the base type does not affect it's behavior an address is an address
These are in direct contradiction to each other. If you think only in terms of elements then the former is true but the latter is not, in the context of pointer arithmetic. Similarly if you think in terms of byte (or however wide the memory happens to be) addresses, then the former is false but the latter is true.
Name:
Anonymous2012-05-12 7:18
>>29
Silly Cudder, since the whitespace is part of your name, would you prefer if people referred to you as "Cudder "? So like, "Silly Cudder enjoys videos of Asian girls in panties" becomes "Silly Cudder enjoys videos of Asian girls in panties", note the double whitespace after "Cudder" in the latter version.
Name:
Anonymous2012-05-12 11:33
>>28
A vast majority of the ANSI/ISO C compiler will statically allocate memory for the pointer. However, depending on the type of linkage, the object itself may or many not get created at runtime.
>>18
This is pretty much the correct answer, although it's due to backwards compatibility with B, not BCPL.
B was the predecessor to C and it didn't have record types (or any types other than ints and arrays.) When you declared an array, e.g. a[5], the compiler created space for six ints: five for the array contents, and one as a pointer to the start of the array. The identifier for an array represented a real pointer in memory. You could actually re-seat the internal storage of arrays in B:
a[5];
b[5];
b = a;
So it made sense that arrays are passed to a functions by reference, because you're not passing the array contents; you're passing the value of the array pointer itself, same as what happens when you assign to an array.
The problem is once they introduced structs, there was no obvious way to initialize the pointer to an array in a struct.
struct foo {
a[5];
};
If this actually contains six ints, one of which is a pointer to the array, where do we set it? If I malloc() some memory and cast it to a struct foo*, that pointer doesn't get set. So they changed it: the identifier for an array when used in an expression just generates the pointer to the array on the fly. It could no longer be assigned to (because it no longer has storage), but to remain backwards compatible with the existing body of B code, it would still be passed as pointer when used as a function argument.
You could actually re-seat the internal storage of arrays in B:
a[5];
b[5];
b = a;
a[5] and b[5] are *not* arrays, but elements of an array. The distinction is pretty important because one in an umodifiable lvalue while the other one isn'.t
Name:
Anonymous2012-05-12 23:47
>>33 So it made sense that arrays are passed to a functions by reference
Also, C is pass *by value*, not pass *by reference*.
Name:
Anonymous2012-05-13 1:04
>>34
No, you misunderstood. The a[5] and b[5] above were declarations of arrays. It would be like writing this in C:
int a[5];
int b[5];
B didn't have type declarations however because it only had one type. Everything was an int. This is why ANSI C has default int.
>>35
Yes, and you're passing by value the pointer to the array. In other words you're passing the array by reference. Way to be uselessly pedantic.
Name:
Anonymous2012-05-13 1:14
>>35
I just want to rage a bit more about how goddamn fucking stupid your post is. The sentence you cut in half in your quote literally continues "you're passing the value of the array pointer itself".
Your comment is bad and you should feel bad. You are absolute filth, the poison that permeates any decent discussion in programming. You look at an entire comment and pull one sentence fragment out of context, making some trivial pedantic correction to try to appear superior, resulting in zero meaningful contribution to the discussion at hand. Fuck you. Get out.
Name:
Anonymous2012-05-13 10:39
>>36 No, you misunderstood. The a[5] and b[5] above were declarations of arrays. It would be like writing this in C:
That's not correct you idiot. Sometime like a[5] is an array element. Something like
int a[5]
declares a to be array of 5 integers. Yes, and you're passing by value the pointer to the array. In other words you're passing the array by reference. Way to be uselessly pedantic.
I'm not being pedantic. A pointer in C and a reference in a language C++ are two distinct beasts. The fact that you mix them up leads me to believe that you've never written any kind of actual code.
Name:
Anonymous2012-05-13 10:43
>>37
Now let me quote K & R you fucking stupid shit...
"In C, all function arguments are passsed "by value". This means that the called function is given the values of its arguments in temporary variables rather than the originals. This leads to some different properties than are seen with "call by reference" languages..."
Now shut up and learn somethihng you god damn piece of shit.
>>38
Please learn more programming languages. Pass-by-value and pass-by-reference are broader concepts than int foo(int x); and int bar(int &y);. The meaning is the same in all programming languages even though there happen to be a language construct with the same name in C++.
Name:
Anonymous2012-05-13 13:38
>>40
No they aren't. If C had "pass-by-reference", then you could stuff stuff like insert a node at the head of a linked linked without using any kind of indirection.
>>47
Sounds like a bad Newgrounds point-and-click game.
Name:
Anonymous2012-05-13 19:16
>>1
void funcarr(int a, int arr[3], int c)
{ printf("%d\n", &c-&a); }
void funcptr(int a, int *ptr, int c)
{ printf("%d\n", &c-&a); }
//This is *NOT* consistent
//Who failed, so I knows whose ass to kick.
maybe you should consider suicide
Name:
Anonymous2012-05-13 21:34
the only person at fault is yourself for writing shoddy and inconsistent code
decide a programming style and stick to it
Name:
Anonymous2012-05-13 21:35
>50
how about i stick my dick inside your ass, see how that feels
Name:
Anonymous2012-05-14 0:44
>>38
You still don't fucking get it. The code fragment in >>33 is B, not C. The naked statement "a[5];" declares an array of five ints. "int" was not a keyword in B, because it was the only type; everything was an int.
Also, who the fuck mentioned C++? I'm not talking about C++ reference types. I'm talking about THE ACTUAL FUCKING MEANING OF THE WORD REFERENCE. If you pass the value of a pointer to an array, semantically you are passing the array by reference.
Yes the language passes the pointer by value, congratulations you fucking get that. Now think: WHY are we passing the value of a pointer? Oh, because we want to be able to REFER to the array contents in the function; we want a REFERENCE to the array, so we pass the POINTER BY VALUE.
Look up a dictionary some time you complete goddamn fucking moron.
>>38,41-42
The terms pass-by-value and pass-by-reference existed long before C++ or even C were created. They have long been used in programming language research to specify the semantics of a function call. Imagine a programming language that isn't C and where there are no pointers and you stumble upon a function call that looks like this:
f(x)
If x is passed by reference, it means that f operates on the same value. So if f modifies the structure of its argument in any way, the changes can be seen in x after the function returns.
On the other hand, if x is passed by value, then no matter what f does to its argument, you'll notice no change in the value of x.
If an argument is never modified within a function, there is no semantic difference between the two, and either can be used. Whether or not the compiler always makes a copy when a function is pass-by-value is an implementation detail.
However, there are pointers in C, so I understand that you are confused. Yes, everything is pass-by-value in C. Yet, when a parameter is a pointer, you sometimes say that the argument is passed-by-reference. But you might also pass a function a pointer to a struct and still say it's semantically call-by-value if the function doesn't modify the struct (and this is what const parameters are used for). So pointers can be used on a higher level to implement both pass-by-reference and pass-by-value. Your confusion stems from the fact that in C, the way parameters are passed is made explicit and you might have to take a step back to see the semantics. It might not be seen if you look too closely at the code (and more so if you think of programming as syntax).
>>44-45
And I'll have you know that my code has been burned to ROM and shipped on consumer devices all over the world. The devices are vibrators, one of which accidentally got your mother pregnant with you (oh wow, it's the 12th anniversery already).
Name:
Anonymous2012-05-14 2:36
Pass-by-name is superior, you're all mad and jelly after reading this post.
Name:
Anonymous2012-05-14 4:37
pass-by-my-dubz
Name:
Anonymous2012-05-14 19:40
>>50
It has nothing to do with style. This is actually one place where C is quite inconsistent, and for the oldest reason in the book: backwards compatibility.
>>57 begin
integer i;
real procedure sum (i, lo, hi, term);
value lo, hi;
integer i, lo, hi;
real term;
comment term is passed by-name, and so is i;
begin
real temp;
temp := 0;
for i := lo step 1 until hi do
temp := temp + term;
sum := temp
end;
comment note the correspondence between the mathematical notation and the call to sum;
print (sum (i, 1, 100, 1/i))
end
C++ is shit, undefined
LISP is shit, parenthesized
Python is shit, FIOCified
Java is shit, objectified
COBOL is shit, enterprised
Malbolge is shit, obfuscified
BASIC is shit, labelized
PHP is shit, MYSQL CONNECTION ERRORfied