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?
Name:
Anonymous2009-10-29 0:27
You're defining a variable named *p as an int, what's so hard to understand about that.
int *p - p is a pointer to an integer
int* p - p has type "integer pointer"
Either way is fine and if you care about this you should go and kill yourself.
Name:
Anonymous2009-10-29 0:54
When one is first learning C, the initial impulse is to attempt to read type information from left to right. This tutorial should disabuse you of that notion.
The type information for a variable is best kept nearest to the actual token--thus int *p rather than int* p. The * modifies and describes p, not the int. For me, at least, that is the reason.
>>6 All together you say a is an array of size 3 pointers to int.
That's a fucking awful way to say it. How about a is a three-element array of int pointers ?
The method is good, however.
Name:
Anonymous2009-10-29 1:31
int *p; /* description of what 'p' does in this function */
int *q; /* description of what 'q' does in this function */
Never declare more than one variable in the same declaration. Especially if you're also initializing them.
>>18
That would be void.h my good sir http://dis.4chan.org/read/prog/1250330533>>12 use one include file for everything. #include "void.h" //handles all the common functions,#defines,#ifdefs and #includes
Name:
Anonymous2009-10-29 6:25
def foo(**kwargs):
WHERE IS YOUR GOD NOW???
Name:
Anonymous2009-10-29 6:31
>>20
I'm >>14 and i use C#. Only int* x; makes sense, why the hell is int *x allowed? Why duplicate syntax?
Name:
Anonymous2009-10-29 6:31
Does anyone know how to sum two numbers in a 2 slot int memory space, using pointer arithmetic?
>>25
This must be related to the other trolling thread about Lisp, but 200MB could be actual figures if you actually had bignums that require so much space. The ANSI CL standard requires bignum support and implementations support it well. Numbers can be upgraded/downgraded from/to fixnums ( similar to ints in C, but with some differences) automatically.
If you were to do a (+ arg1 ... argn) and the result would be greater than MOST-POSITIVE-FIXNUM it would get automatically upgraded to a bignum.
int********** p. Enjoy your pointer dereferencing.
Name:
Anonymous2009-10-29 9:18
>>14,21
lulz, look at the little .NET rookie being confused out of his little wits by the semantics of the real C. (Note that I do not call it "C/C++" because "C/C++" is not a language, as he and other blub coders believe)
>>30
There's no need to get so agitated. It makes you look like YHBT.
Name:
Anonymous2009-10-29 11:17
>>30
You're an idiot; >>14,21 is right. C# is the next level of C/C++ (C -> C++ -> C#). It uses the idea of classes (OOP), and int* means a class of type integer pointer. It's newer and they fixed the mistake found in C (int *p), which is an int type of the name *p.
>>37
I was a little disappointed in that post, since you could have capitalized on your first troll much better that you did, but you still have some hopes for the future.
When I see "int *p;" i think "when i dereference p I get an int" or more generally "p gets dereferenced to an int"
Analogously "int factorial(int)" means "factorial gets evaluated with the arguments (int) and becomes int"
And by the same reasoning something like "int *(*q)[5](char *)" (which would confuse 99% of the "HURR, int* p" people) means "when I dereference q I get an array of 5 functions which when evaluated with an 'char *' argument, I will be left with a pointer to an int"
Name:
Anonymous2009-10-29 15:59
int* 4 lyfe.
Name:
Anonymous2009-10-29 16:01
>>35 C is about reification of memory layout, register specifics etc.
Please stop using words you don't know the meaning of. Thank you.
By the way! This is a nice explanation, but shit like this: int *func_returning_ptr_to_int();
Makes me FUQIN RAGE! You forgot your void, moron! It is C, not C++! You never, ever, ever declare a function with empty arglist, that's just asking for a well-deserved trouble, bitch!
Also, he could have mentioned whence the "look right, then look left" rule comes: it's because the only two operators allowed in declarations are '*' and '[]', and '[]' has higher precedence and goes to the right.
>>44
Get with the times, using the empty lists to specify no arguments is valid C99.
Name:
Anonymous2009-10-29 16:30
>>45
your moran >>46
You missed the point. Empty arglist is the original way for doing varargs and so calling a function thus declared with any number of any parameters is valid C99, and even -Wall won't say anything.
>>44 You never, ever, ever declare a function with empty arglist, that's just asking for a well-deserved trouble, bitch!
What trouble could that possibly cause? pls explain
Name:
Anonymous2009-10-29 18:06
>>50 - >>47
The trouble? I had a function with one argument, I got rid of it, patched the calls I knew of and it compiled with no errors or warnings. That's what static typing is for: you refactor, recompile and if it goes through, then you have this warm fuzzy feeling that you didn't break anything, right? Not in this case though.
Bonus OMG WTF IS HAPPENING points for trying to import this function from a dynamically linked library, not being sure that there aren't name clashes, changing the signature and... well, you don't want to experience this, that's why you should ALWAYS WRITE FUQIN (void)!!1
Name:
Expert C/C++ Programmer2009-10-29 18:08
>>50
It leaves the argument list unspecified. To actually make it explicit that your function takes no args, you should instead write foo(void).
int main(int argc, char **argv)
{
printf("I'd rather be surfing\n");
/* Unrelated, but some tutorials say that it's okay to write void main(),
which lets you leave out the return statement. Don't do that, either. */
return 0;
}
int i_am_bleeding(int this_function, int actually_takes, int several_arguments, int you_talentless_hack)
{
if (you_actually_knew(C)) {
you_would_already_understand_this();
}
return to("/b/", PLEASE);
}
Name:
Anonymous2009-10-29 18:22
>>53 int main(int argc, char** argv) { return 0; }
The left-to-right-readable separated type concept is cleaner and easier to read, but that's not how C does it, and you're doing everyone a disservice if you try to pretend it is. It breaks completely for anything more complicated than pointers.
C defines 'em as it dereferences 'em, and if ya fancy yerself to be a C pror'mmer, that's the way ye'll do it and ye'll like it!
Name:
Anonymous2009-10-29 18:44
★That was VIP quality!★
Name:
Anonymous2009-10-29 18:50
>>37 You have been told?
Must resist the urge to scream at you for being an idiot, and resultantly BT.
>>38 >>58
ok, so i googled it and found out it meant you have been trolled. and guess which site was number 1? enyclopedia dramatica (a site run by 4chan). obviously no one else uses it that way. it should be YHBTr at least to avoid confusion.
i honestly dont get why you have to use secret acronyms. anonymous web board were invented so they would be all inclusive, making up acronyms makes it exclusive because i dont know what you mean. this is the reason i left reddit, and anonymous boards are supposed to avoid that
I honestly dont get why you have to use secret acronyms.
YHBT is a very old and well known acronym and could hardly be classified as secret. making up acronyms makes it exclusive because i dont know what you mean
Firstly, making up acronyms is fun and has led to many interesting diversions of topic on /prog/
Secondly, it is traditional to lurk and become acquainted with a board's culture (memes,acronyms,use of text for artistic purposes, taboo themes) before posting and the current trend of just ignoring all the board culture and expecting everyboard to behave the same is the reason that the majority of 4chans boards have went down the shitter. this is the reason i left reddit, and anonymous boards are supposed to avoid that
While I'm glad you've came to your senses about reddit and similar sites (I'm guessing from the way you post you've read shii's essay?), it is, unfortunately, folly to assume that these ideals still hold (see /b/ for details)
>>2 >>33
OP here, and that's the problem, you haven't defined anything named *p. *p is a compound expression. You've defined p.
You certainly haven't defined any int; the int it points to need not even exist.
>>4
Obviously I know variable declarations are read right-to-left. It doesn't magically explain why the space is in that arbitrary position. What about "p is a pointer to an int" says that the space goes between the * and int? It's not the "to a", because then why would you write "int **p"?
However if you write "int* p", then it does make sense, because in "p is a..." the "is" is the explanation for the space; it separates the name you're defining from its complete type.
>>3
What the fuck is your post supposed to mean? Do you mean "int* p, q;" is confusing? When you know the standards there's nothing confusing about it, but writing that on purpose in my opinion is deliberately misleading; it's like using the wrong indentation. I'm obviously not suggesting you use the C++ style in defining multiple variables in the same declaration; you are pretty much forced to declare them separately in this case, otherwise the declaration looks wrong (as in >>10).
Did you mean "int* p,q" would be confusing if it worked as you would expect from the spacing? Because if it did, there would be nothing confusing about it (and even less so when you add type modifiers; if it worked this way, stupid expressions like "const int* p, *const q = r;" would actually be invalid. As much as I like C, this is another good reason why the C convention is fucking stupid.)
>>16
Um, this has the exact same problem. Did you know the style "typedef int *PINT" is pervasive throughout the Win32 headers?
>>21
It's not duplicate syntax; it's just whitespace. You can write int*x if you want to.
>>23
Yes, the convention makes this possible, but the compound declaration rules were made because the convention existed in the first place. What was the reasoning behind them then?
>>30
Are you going to explain then why "int *p" makes sense? Because I have yet to see a rational explanation for it.
>>65
Which essay are you thinking off? How to be a hacker (or whatever it's called)?
I thought he meant this http://wakaba.c3.cx/shii/shiichan (I think there is a longer one, but I can't really remember)
>>60
fuck you, lazy faggot.
YHBT & IHBT are very very common.
we have much more esoteric ones, ones that you will only ever see on /prog/ such as SPAWHBTC and NYJMUA.
but regardless of how secret their meaning seems to outsiders, it can easily be found out by just lurking or with a little googlefu. IHBT
Name:
Anonymous2009-10-29 20:22
OP here again, I didn't notice there was a page two...
>>41 When I see "int *p;" i think "when i dereference p I get an int" or more generally "p gets dereferenced to an int"
This is the best explanation I've seen, but it still seems silly to me. Isn't this hard to visualize when you have to do pointer arithmetic? Why not abstract away the dereferencing of it?
It also breaks down if you write "int **p". Do you think "When I dereference p I get something that when I dereference it I get an int"? That seems a very convoluted way of understanding p.
>>56
The complexity is irrelevant; it doesn't break at all unless you try to define multiple variables in one declaration.
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).
If the calling convention is cdecl, the number of parameters that are passed is irrelevant, as the caller does the cleanup, and the callee can just look up as many parameters up the stack as needed. Other conventions such as stdcall aren't as friendly with variable numbers of arguments. The fact is that as long as main's calling convention is cdecl and you use the parameters you're receiving in the correct way(assuming certain parameters), you'll be perfectly fine. Some uses may not be "comforming" to the standard, but in implementation-specific cases, it will work perfectly.
Well, technically, it probably should be int *p, because the dereferencing operator (aka the pointer asterisk) is not part of the type, but a per-variable specifier. Think of it like an initialization:
// a and b should both be initialized to 1
// The WRONG way:
//int a, b = 1;
// The RIGHT way:
int a = 1, b = 1;
So basically, you're specifying that both of the variables are pointers, but individually. It's more intuitive for multi-variable declarations as well, which is why it is seen more in C, because the common style for structs uses multi-var declarations wherever it can.
But personally, I prefer int* a. And I'm impartial between char** argv and char *argv[], but the latter just seems unwieldy.
>>128
If you think of it that way, then you're wrong.
Whereas initialization looks like char *a = "something";, later on if you want to assign to a, you don't write *a = "something else";, you write a = "something else";.
Name:
Anonymous2009-10-30 18:59
>>130
that's only because a string literal is an array of characters. you're assigning the address to a not the actual value.
try modifying the values that a points to.
for instance a[0] = 'b'; SEGFAULT.
all pointers are represented inside the machine exactly the same. void *;
char *;
int ******************;
struct whatever ******************************;
all exactly the same internal representation.
the type is what the pointer points to, each asterisk is a just representation of a layer of indirection - it's there to make the code easier to read for the programmer; the machine couldn't care less about it.
>>131
He was referring to the fact you modify a pointer without the asterisk, I believe. (IHBT)
Name:
Anonymous2009-10-30 20:28
what it basically boils to down to is nubbins seem to thing that * in this context means ZOMG POINTER, but it actually means "dereference" and so char *p is define dereferenced p as char.