hi all,
what is the difference between static int a and int static a?
thanks :)
Printable View
hi all,
what is the difference between static int a and int static a?
thanks :)
There's no such thing as int static AFAIK. Only static int.
Whilst style dictates that you should use "static int", it's (apparently) valid to type "int static" - at least "gcc -Wall" doesn't complain about it. And from looking at the code, it does what you expect. I guess it's the same as "const int" or "int const".
--
Mats
That's because the '*' is a different kind of entity. "static" and "int" are a storage class specifier and a type specifier, respectively. They bind to the declared entity. Whereas '*' is an actual part of the declared entity.
In fact, the fragments "const int*" and "int* const" are essentially meaningless because the name the star binds to has been left out. Think of it this way:
This is not saying "x is a pointer to int." What it's really saying is, "*x is an int." Which of course implies that x itself must be a pointer to int. The star cannot be separated from the name. This is why I prefer the practice of attaching the star directly to the variable name instead of leaving a space. The star is NOT a type modifier.Code:int *x;
It's like using "unsigned int" or "int unsigned" or "long unsigned int long", I suppose. :) Type specifiers (like int and unsigned) and storage class specifiers (like static and extern) can go in any order.
There's no difference between static int a and int static a, it's just a matter of style and convention.
It's like the difference between these:
I always put the asterisk next to the variable name, as brewbuck does, because otherwise it's confusing when you declare multiple variables at once. (It's true that some people don't recommend this . . . .)Code:int *x;
int* x;
This
makes y look like a pointer, except it's not. You could, of course, use a typedef to make things easier.Code:int* x, y;
But I'm getting off topic . . . .Code:typedef int *int_p;
int_p x, y;
Expanding on what dwks said already... Consider:
This is, conceptually, declaring two integers: *x and y. If *x is an int, then x must be pointer to int. What it is NOT doing is declaring both to be pointer to int. It is easier to understand WHY it is this way if you think of it in the way I've outlined here.Code:int *x, y;
Writing the star directly next to the type can trigger the misconception that the star is binding to the type specifier and therefore affecting each declarator in the declaration. But the reality is it binds to the DECLARATOR, not the type specifier, and so it only affects the declarator directly to its right.
Writing the star directly adjacent to the declarator makes it more clear that it does in fact bind rightward, not leftward.
Oh, I see. I thought you were saying something that referred to a statement with only one declarator.
Thanks.
My philosophy is that int* is a pointer-type variable pointing to int, so I always place them next to the type, (int* is a type, just like int!) and I never ever do int* n, n2 - when there's a pointer declaration, I always place it on a row of its own. Avoids confusion.
Irrelevant. I find int* to be a type, whatever anyone might say. We can argue all we want about it, but the question is if anyone is truly correct.
Your example won't work, of course, since the second will be a normal int, but even if the language says so, I will still say int* is a type. It's the best understanding of pointers from my point of view. It makes them understandable.
(Plus the fact that any pointer is 4 bytes on x86, that kinda also adds to my interpretation of pointers; doesn't matter if it's char* or UINT64*, it's still 4 bytes, which is also why I consider them a type of their own.)
There is such a type as "pointer to int," yes. You can create it specifically with:
Now, intptr actually IS a typename for "pointer to int". Of course I am not claiming that int pointers do not exist, just that the code fragment "int*" does not refer to the type "pointer to integer." It doesn't refer to a type at all. It is like a sentence fragment -- pretty much meaningless on its own. It simply ain't a type, way down at the very basic (syntactic) level.Code:typedef int *intptr;
What the syntax says, I couldn't care less.
If a pointer points to int, then it must be a type of int*. Why? Because I can't use char* to point to an integer (without a cast, of course). And that tells me that int* and char* are different types. If there would be no types, then we'd be using void* all the time, but we don't.
Feel free to blame my method of interpreting the language, but this is how I see it, this is how I do it and it works fine.
I'm not sure how the C/C++ standard defines a "type", but by using my own common sense as well as the compile errors you get if you pass the wrong type to a function, I would say that int, int*, int**, const int*, int* const... are all different types.
I wouldn't call them meaningless. You don't need to specify a parameter name in a function prototype, only the type is required:Quote:
Originally Posted by brewbuck
Code:void func( int, int*, int** );