difference between static int a and int static a?

This is a discussion on difference between static int a and int static a? within the C Programming forums, part of the General Programming Boards category; hi all, what is the difference between static int a and int static a ? thanks...

  1. #1
    Registered User
    Join Date
    May 2007
    Location
    China
    Posts
    37

    difference between static int a and int static a?

    hi all,
    what is the difference between static int a and int static a?
    thanks

  2. #2
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,013
    There's no such thing as int static AFAIK. Only static int.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #3
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  4. #4
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by matsp View Post
    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.

  5. #5
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by cpjust View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #6
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,273
    Quote Originally Posted by cpjust View Post
    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.

  7. #7
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    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.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  8. #8
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    Quote Originally Posted by brewbuck View Post
    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?

  9. #9
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,048
    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 . . . .
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  10. #10
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,273
    Quote Originally Posted by robwhit View Post
    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.

  11. #11
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    Oh, I see. I thought you were saying something that referred to a statement with only one declarator.

    Thanks.

  12. #12
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,013
    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.
    Last edited by Elysia; 12-06-2007 at 02:00 PM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #13
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Elysia View Post
    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.

  14. #14
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,273
    Quote Originally Posted by Elysia View Post
    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.

  15. #15
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,013
    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 Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21