What do you think about the difference between the following declarations? Which do you prefer?
int* p;
int *p;
It's often said the first is C++ style and the second is C style. I prefer C but conceptually the first declaration makes a lot more sense to me. You're defining a variable p of type int*. p is an int*. You dereference it, *p, when you want the int. Makes sense. The second example to me seems like gobbledygook, but it's the way the C authors thought of it, because of this bullshit:
int *p, *q;
So what the fuck is the deal? Can someone who uses "int *p" syntax explain to me what goes through your head when you write that garbage?
OP here again, for the "int *p" crowd, how do you deal with const and restrict? Would you write "int *restrict p"? This looks fucking stupid to me. I write "int* restrict p", which makes sense.
>>82
Yes, that is exactly how I write that. I guess if you understand the "you read type declarations from right to left" thing and still think int *p is ugly, there's no more discussion we can have. To me, int *p is intuitive from how I read type definitions. To you, not. That's that.
Name:
Anonymous2009-10-30 1:50
>>84
No, this is bullshit. Why is the positive of the space intuitive? You can't even explain it.
>>82
I use Sepples, so I don't use const/restrict with respect to the variable declarations. I might use a const int *, but never an int const *. There's just no need to make such a distinction anymore.
Name:
Anonymous2009-10-30 1:54
OK guys, let's just admit that Java had things right on this syntax issue.
int[] dicks;
makes sense.
int dicks[];
does not.
Name:
Anonymous2009-10-30 1:55
Hello dinosaurs. Its hard to believe, but modern languages actually don't use * anymore. * makes things more complicated, when you can make the computer do it for you (Python, Java, C#). Also, * takes time to run, and when you use a language that doesn't use *, that means your program runs faster.
Name:
Anonymous2009-10-30 2:39
>>89 is right. Think of all those multiplications that you're making the processor do.
>>92
No, I am not thick. You are arguing for the position of the asterisk *purely because of the grammar* of variable declarations; not what they semantically mean.
Name:
Anonymous2009-10-30 9:27
I also want to say, stop being a dick. We've said over and over that you *shouldn't* use multiple declarations in C++ style, and you keep bringing it back up as an example of why the style is bad.
C > Sepples.
∴ C style declarations > Sepples style declarations.
</thread>
now get out. all of you.
this thread is just the same handful of posts being repeated over and over and over.
I find C++ style easier to understand conceptually, but I only use C style when coding C.
Name:
Anonymous2009-10-30 9:56
In D, int * is the type, so int *a, b; means b is also a pointer.
(Which also means it should be written as int*)
Really it's how C should have been to begin with.
int a, *b, **c, ***d; is how it should be.
the asterisks ARE NOT part of the type. what fucking moron came up with that idea?
each asterisk represents a layer of indirection, not a goddamn data type. they are not part of the type and should not be thought of as such.
also: int *a; //declare
*a; //dereference
in this way you declare them the same as how you get the value that it points to.
>>110
At least with glibc and a dynamically linked file, the next arg after envp is dynamic linker information. /* contents of 'ld' array from int main(int argc, char **argv, char **envp, char **ld) */
ld[0] = "ELF"
ld[1] = "/lib/libc.so.6"
ld[2] = ""
ld[3] = ""
ld[4] = ""
ld[5] = ""
If the program was statically linked, this ld parameter will be NULL.
(Of course, this is treading well into implementation-defined territory, so YMMV.)
>>115 here. I was playing with the "next" arg after that, it's quite weird. Seems to be a pointer to pointer to pointer to nothing: #include <stdio.h>
int main(int argc, char **argv, char **envp, char **ld, void ***what) {
printf("%p\n", **what);
return 0;
}
This produces (nil); statically linked, what itself is (nil).