difference between static int a and int static a?

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

Quote:

---

Originally Posted by matsp

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

---

But not to be confused with: const int* vs. int* const which are quite different.

Quote:

---

Originally Posted by cpjust

But not to be confused with: const int* vs. int* const which are quite different.

---

Yes, if you start mixing in pointers and/or references, you'd better get the const on the correct side of the * or &, or you get "something other than what you wanted".

--
Mats

Quote:

---

Originally Posted by cpjust

But not to be confused with: const int* vs. int* const which are quite different.

---

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:

Code:

---

int *x;

---

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.

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.

Quote:

---

Originally Posted by brewbuck

Code:

---

int *x;

---

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.

---

Excuse me for asking, but how is there any difference between those two interpretations?

It's like the difference between these:

Code:

---

int *x;
int* x;

---

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 . . . .)

This

Code:

---

int* x, y;

---

makes y look like a pointer, except it's not. You could, of course, use a typedef to make things easier.

Code:

---

typedef int *int_p;
int_p x, y;

---

But I'm getting off topic . . . .

Quote:

---

Originally Posted by robwhit

Excuse me for asking, but how is there any difference between those two interpretations?

---

Expanding on what dwks said already... Consider:

Code:

---

int *x, y;

---

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.

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.

Quote:

---

Originally Posted by Elysia

My philosophy is that int* is a pointer-type variable pointing to it, 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.

---

Me too.

Quote:

---

Originally Posted by Elysia

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!)

---

If int* was a type, then the following declaration would declare two int pointers:

Code:

---

int* x, y;

---

Except that it doesn't. Which proves that "int*" is not a type. Philosophies notwithstanding, the grammar is perfectly clear on this point.

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.)

Quote:

---

Originally Posted by Elysia

I will still say int* is a type.

---

There is such a type as "pointer to int," yes. You can create it specifically with:

Code:

---

typedef int *intptr;

---

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.

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.

Quote:

---

Originally Posted by brewbuck

In fact, the fragments "const int*" and "int* const" are essentially meaningless because the name the star binds to has been left out.

---

I wouldn't call them meaningless. You don't need to specify a parameter name in a function prototype, only the type is required:

Code:

---

void func( int, int*, int** );

---

Quote:

---

Originally Posted by cpjust

I wouldn't call them meaningless. You don't need to specify a parameter name in a function prototype, only the type is required:

Code:

---

void func( int, int*, int** );

---

---

The name is still there, it simply exists in the form of an epsilon, i.e. "nothingness." Known as a "trace" in some linguistic theories. And implemented so in the grammar.

But this is getting to be just nonsense.