Like Tree3Likes
  • 1 Post By laserlight
  • 1 Post By anduril462
  • 1 Post By CommonTater

Pointer Asterisk Ownership Questions...

This is a discussion on Pointer Asterisk Ownership Questions... within the C Programming forums, part of the General Programming Boards category; Okay, I'm having trouble here with the "owner" of the asterisk - that is, what symbol it applies to... Here's ...

  1. #1
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196

    Pointer Asterisk Ownership Questions...

    Okay, I'm having trouble here with the "owner" of the asterisk - that is, what symbol it applies to...

    Here's why I'm confused.

    If you declare a char*, say: char* a; - I find that way more intuitive because you're NOT declaring a char type, it's a pointer, therefore I would believe that the asterisk should side with the type of pointer that it is, not with the variable...the only reason you even need to specify the type of the pointer is for arithmetic and some loose type checking...if you're not doing arithmetic on the pointer, you can use void pointers for everything...so why does it belong to the variable?

    But we know this isn't true, it belongs to the variable, which is why when you declare multiples, you have to specify each one, ie. char *a, *b; This rationale makes no sense to me, as I feel it should apply to the type, not the variable. It's only allocating 4 (generally, anyway) bytes on the stack for the pointer, not the sizeof the type.

    But whatever, I don't get that, but ok.

    But then when you typedef, something, ie.
    Code:
    typedef char CHAR, *PCHAR;
    It is suddenly not only an attribute of the type, but now it's BEFORE the type, where it was originally after...I would expect something more along the lines of:
    Code:
    typedef char CHAR, PCHAR*;
    But no.

    Then there's prototypes - just the prototype - in C, no variable name is required, so your prototypes can look like this:
    Code:
    functionA(char*, int*);
    Again, eluding to the concept that the asterisk (the property) applies to the type, not the variable.

    Can somebody explain this MESS to me? I just see so much inconsistency, and I never really cared about it, but now it's starting to bother me for some reason :-\.

    TIA.

    And plz don't tell me to search, all the searching I've done has only told me that the asterisk applies to the variable, not the type - which I know, but that's not answering my question.

  2. #2
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Short answer: Never typedef a pointer. No one likes that.

    Long answer: Typedef makes a new type. A type is basically the keyword you use to make an instance of that variable. In a declaration, * denotes a pointer. Thus:
    Code:
    int *x;
    x is a pointer to an int. The * binds to the variable it is beside, not the type.
    Code:
    int *x, *y, z;
    This makes two integer pointers named x and y, and one integer named z.

    They could have made it bind to the type, but that would prevent you from making the line above. If it bound to the type, x y and z would all have to be pointers.
    Code:
    typedef char * badtype;
    badtype x, *y;
    Now we have a pointer to a character as a type in x, and a pointer to that in y.


    Quzah.
    Hope is the first step on the road to disappointment.

  3. #3
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196
    Quote Originally Posted by quzah View Post
    Short answer: Never typedef a pointer. No one likes that.

    Long answer: Typedef makes a new type. A type is basically the keyword you use to make an instance of that variable. In a declaration, * denotes a pointer. Thus:
    Code:
    int *x;
    x is a pointer to an int. The * binds to the variable it is beside, not the type.
    Code:
    int *x, *y, z;
    This makes two integer pointers named x and y, and one integer named z.

    They could have made it bind to the type, but that would prevent you from making the line above. If it bound to the type, x y and z would all have to be pointers.
    Code:
    typedef char * badtype;
    badtype x, *y;
    Now we have a pointer to a character as a type in x, and a pointer to that in y.


    Quzah.
    Yeah, everything there I'm well aware of..

    I'm not asking "how to do it" - I'm well aware of how to use & declare pointers and typedefs, I even provided the examples. What I'm not aware of is the rationale behind both A) The inconsistency of the syntax, and B) The idea that the asterisk binds to the variable when it realistically shouldn't - it has nothing to do with the variable, you're declaring the type to be a pointer, it is affecting the type, not the variable. This is reflected, as I showed above, in both typedefs, as well as function prototypes, where the asterisk affects the type, NOT the variable - as it should.

    For all intents and purposes, I'm trying to figure out why variable declaration has a syntax that's not consistent with the rest of the pointer use, nor is intuitive to the action being performed.

    Also, for the "Never typedef a pointer. No one likes that." comment: It's done in industry all the time, especially when declaring the typedef wrap around structs. Things like
    Code:
    typedef FILE *FHANDLE;
    are also extremely common.

  4. #4
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,449
    Quote Originally Posted by Syndacate
    The idea that the asterisk binds to the variable when it realistically shouldn't - it has nothing to do with the variable, you're declaring the type to be a pointer, it is affecting the type, not the variable.
    I like the way Stroustrup explains this in his answer to Is ``int* p;'' right or is ``int *p;'' right?:
    Quote Originally Posted by Bjarne Stroustrup
    C emphasized expressions; declarations were often considered little more than a necessary evil.
    (...)
    A ``typical C programmer'' writes ``int *p;'' and explains it ``*p is what is the int'' emphasizing syntax, and may point to the C (and C++) declaration grammar to argue for the correctness of the style. Indeed, the * binds to the name p in the grammar.
    EDIT:
    Quote Originally Posted by Syndacate
    Also, for the "Never typedef a pointer. No one likes that." comment: It's done in industry all the time, especially when declaring the typedef wrap around structs.
    It is fine if the typedef is for an opaque pointer since the pointer would then never be dereferenced except within the library implementation. It is also fine for a function pointer. In C++, it would be fine for a pointer that serves to implement some iterator interface. But in many other cases, the typedef would simply be bad practice, even if you see it used in the "industry".
    Last edited by laserlight; 07-26-2011 at 01:04 AM.
    AndrewHunter likes this.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #5
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196
    Quote Originally Posted by laserlight View Post
    I like the way Stroustrup explains this in his answer to Is ``int* p;'' right or is ``int *p;'' right?:
    I'm not entirely following. These mechanisms (all of the above) were in place before Stroustrup even came up with C++. In the end I don't really care which side of the space they put the asterisk on, that's just a matter of style, I've seen some people put a space on either side of it *shrugs*.

    What bothers me is that it's binded to the variable - and it shouldn't be - and it's not in prototypes - only in the variable declaration. The pointer is affecting the type, and only the type. It is not changing the way the variable behaves in any way, only the type aspects of it.

    On most 32 bit systems, a pointer will be 4 bytes, I think most agree on that. Though if you have a 40 byte struct, that is VERY different than a pointer to said struct - that's 10x as much!

    Declaring 4 bytes versus 40 is a big deal, IMO.

    This is an issue that pre-dates Stroustrup, this is a Kernighan and Ritchie issue. It's just not a logical binding - at all. I also am missing the consistency. I was hoping there's some "expert rationale" behind it, but it doesn't seem there is .

  6. #6
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,444
    Quzah covered the variable declaration and the typedef pretty well. I'll get to the prototype in a minute, but a huge part is simply because it was designed that way. Like Quzah said, it could've been the other way, but it isn't.

    Quote Originally Posted by Syndacate View Post
    But then when you typedef, something, ie.
    Code:
    typedef char CHAR, *PCHAR;
    It is suddenly not only an attribute of the type, but now it's BEFORE the type, where it was originally after...I would expect something more along the lines of:
    Code:
    typedef char CHAR, PCHAR*;
    Your syntax is slightly off. There shouldn't be a comma there, which might be part of your association issues. And yes, it is before a type, but it's not before the type it's connected to. It actually is after the type, it's just after the old type name, not the new one. The correct syntax is:
    Code:
    typedef old type specifier new_type_name;
    Note that I left old type specifier with spaces to show you can have a multi-word type specifier, such as "struct foo_s", but the new_type_name must be a valid C identifier, like "foo_t". What you're really saying with the typedef is (pay attention to the colors):
    Code:
    typedef char * pchar;
    Yeah, that * stays on the left. The old type is a char pointer, or char *. The new name you want as a short hand is pchar. If you put it to the right of pchar, it just wouldn't make sense. Now, continuing on with pchar, we know that:
    Code:
    int x, y;
    // is the same as
    int x;
    int y;
    similarly:
    Code:
    pchar s, t;
    // is the same as
    pchar s;
    pchar t;
    So both s and t are of type pchar. That's the way the language was designed.

    Then there's prototypes - just the prototype - in C, no variable name is required, so your prototypes can look like this:
    Code:
    functionA(char*, int*);
    Again, eluding to the concept that the asterisk (the property) applies to the type, not the variable.
    Well, your misunderstanding may come from the asterisk eluding your understanding. But the lack of a parameter name doesn't really allude to the fact that the * should be bound more to the type than the variable name. Function parameters are different than regular variable declarations. Each one must specify a full type and be separated by commas. The name is mandatory in the declaration, but optional in prototypes because of what prototypes were designed for. C reads files top-down, an is only aware of things that it has already seen. So if you declare a function after you use it, or in another file to be linked in later, you need a prototype so the compiler can check the parameter count, parameter type and return type. The names of the variables don't matter in the prototype, it's just so the compiler can check if you're using it right. It doesn't care what you call it, as long as it's the right type.

    Can somebody explain this MESS to me? I just see so much inconsistency, and I never really cared about it, but now it's starting to bother me for some reason :-\.
    There's no inconsistency, except the one you made up. The * always goes with the variable name, even when it's "built in" to a typedef or the name is "invisible" in a prototype.

    And plz don't tell me to search, all the searching I've done has only told me that the asterisk applies to the variable, not the type - which I know, but that's not answering my question.
    Search! There, I told you...whaddaya gonna do about it? Yeah, that's what I thought.

    Quote Originally Posted by Syndacate View Post
    I'm not asking "how to do it" - I'm well aware of how to use & declare pointers and typedefs
    Not entirely true, considering your commas-in-typedefs issue above. Also, Quzah's examples showed you specific things you wouldn't be able to do if you had it your way. You should probably be a little less curt with those who are trying to help you.

    What I'm not aware of is the rationale behind both A) The inconsistency of the syntax
    It's not inconsistent. You have 3 gramatically separate elements. Just because all 3 things specify a type for something doesn't mean they must behave identically. The syntax for all variable declarations is consistent. So is all typedef syntax. So is all prototype syntax. But the 3 are different things, so they are each different from eachother.

    and B) The idea that the asterisk binds to the variable when it realistically shouldn't - it has nothing to do with the variable, you're declaring the type to be a pointer, it is affecting the type, not the variable. This is reflected, as I showed above, in both typedefs, as well as function prototypes, where the asterisk affects the type, NOT the variable - as it should.
    "as it should" really ought to be "like I want it to". If you feel that strongly about an arbitrary decision that has no bearing on the usefulness of the language, then programming isn't for you. If you think it cripples the C language, too bad, nobody's gonna change after 40 years, but you certainly could write the ISO committee if it makes you feel better. If it just plain bugs you, then there are a bunch of other languages besides C you can pick from that don't even use an asterisk or give you pointers to mess with, or types, or functions.

    Also, for the "Never typedef a pointer. No one likes that." comment: It's done in industry all the time, especially when declaring the typedef wrap around structs. Things like
    Code:
    typedef FILE *FHANDLE;
    are also extremely common.
    Like Quzah said, typedef'ing pointers is nasty, and nobody likes it (okay, a few people do, but most experienced, professional programmers avoid it). Yes, you see it in industry, but lots of bad practices occur in industry. Industy is not the gold standard. The reason it's disliked is that it makes it hard to determine just how many levels of indirection (pointerness) you have in a given variable/type -- clear, easily maintainable code is the goal, not saving characters in source files. The use is acceptable if the typedef'ed pointer points to a completely opaque type/struct.
    Last edited by anduril462; 07-26-2011 at 01:23 AM.
    AndrewHunter likes this.

  7. #7
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,638
    I think you answered your own question.

    Quote Originally Posted by Syndacate
    On most 32 bit systems, a pointer will be 4 bytes, I think most agree on that. Though if you have a 40 byte struct, that is VERY different than a pointer to said struct - that's 10x as much!
    Sometimes I think the only resource C and C++ truly handle is memory. How you do a file API and things like that aren't really all that important to the C language, (albeit if your discussing the C standard library it is ostensibly important) but you get to control memory pretty much built-in, and in C++ you can even do it without including any libraries.

    So if you mean to declare two ints it's one thing, if you mean a pointer and an int on the same line it's another. I don't see how it's a contradiction of the type system if what we're talking about is what's been done from the outset and no one is exactly hiding what the grammar is. I mean, this is only a problem because of how much you might want to do on one line.

  8. #8
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,449
    Quote Originally Posted by Syndacate
    I'm not entirely following. These mechanisms (all of the above) were in place before Stroustrup even came up with C++. In the end I don't really care which side of the space they put the asterisk on, that's just a matter of style, I've seen some people put a space on either side of it *shrugs*.
    I'm not following you either. Note that the link is because I am quoting Stroustrup, so I allowed you to more easily read the source of the quote. My answer has nothing to do with style otherwise.

    Quote Originally Posted by Syndacate
    What bothers me is that it's binded to the variable - and it shouldn't be - and it's not in prototypes - only in the variable declaration.
    The "shouldn't be" is subjective. Personally, I think that the asterisk should have been bound to the type name in the syntax, in view that it makes a declaration with initialition like this more consistent:
    Code:
    int* p = 0;
    If we write:
    Code:
    int *p = 0;
    and then use the argument that "*p is what is the int", it follows that we are initialising *p to 0, but that is not the case.

    Quote Originally Posted by Syndacate
    It's just not a logical binding - at all. I also am missing the consistency. I was hoping there's some "expert rationale" behind it
    Stroustrup has given a possible rationale, which I quoted. If you don't understand the rationale, that is because you are placing your emphasis on types rather than expressions. Fine, but then you just have to accept C's syntax for what it is.
    Last edited by laserlight; 07-26-2011 at 01:25 AM.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  9. #9
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Quote Originally Posted by Syndacate View Post
    What I'm not aware of is the rationale behind both A) The inconsistency of the syntax, and B) The idea that the asterisk binds to the variable when it realistically shouldn't - it has nothing to do with the variable, you're declaring the type to be a pointer, it is affecting the type, not the variable. This is reflected, as I showed above, in both typedefs, as well as function prototypes, where the asterisk affects the type, NOT the variable - as it should.
    It isn't inconsistent.

    In one example you have a type, and you make a pointer to that. In the other, you have a type, and you aren't making a pointer to that type.
    Code:
    int *p;]
    p is a pointer to an int.
    Code:
    typedef int * mytype;
    mytype p;
    That's not a pointer. That's an instance of mytype, and mytype just happens to be defined as a pointer to an int.

    But in both cases what you are declaring is completely different. In the first you are declaring that p is a pointer to type int and in the second you are saying p is an instance of type mytype (which just happens to be a pointer type, but that's irrelevant). You are making one a pointer to a type and one an instance to type.

    That's completely different in what you are declaring.


    Quzah.
    Hope is the first step on the road to disappointment.

  10. #10
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196
    There's too many responses for me to respond to right this moment (I have to go), but I'll respond tomorrow. Though one thing that quickly caught my eye was people complaining about commas in typedefs - saying it's wrong.
    Code:
    typedef char CHAR, *PCHAR;
    Is perfectly valid syntax as far as I know....gcc and CL accept it perfectly well.

    Although I do see what you guys are saying by looking at it from the perspective of "this is a pointer that points to type X", I never thought of looking at it like that before - Laserlight, I now see what Stroustrup was saying in that quote, I didn't quite get what you/him were getting at, before. Though still, I'd say that saying a symbol is something else is a characteristic of its type :-\. I guess the way I see it it, variable declaration is: <allocation size> <reference>.

    I'll have to get back to this thread tomorrow in more detail.

  11. #11
    Registered User
    Join Date
    Nov 2010
    Location
    Long Beach, CA
    Posts
    5,444
    For you to chew on tomorrow:

    The comma you've seen in a typedef isn't for separating old type from new type. It's for making multiple new types out of one old type:
    Code:
    typedef int       this_is_an_int, this_is_also_an_int;
    ...
    this_is_an_int     x = 42;
    this_is_also_an_int     y = 17;
    EDIT: Ahh, I managed to merge in my head the "char" and "CHAR" from your examples. Yep, they are correct.
    Last edited by anduril462; 07-26-2011 at 02:00 AM.

  12. #12
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    I see that C's favorite can of worms has been reopened...
    Personally I prefer the "compromise position"...

    Code:
    int * x;
    AndrewHunter likes this.

  13. #13
    Registered User
    Join Date
    Aug 2010
    Location
    Rochester, NY
    Posts
    196
    Quote Originally Posted by anduril462 View Post
    Quzah covered the variable declaration and the typedef pretty well. I'll get to the prototype in a minute, but a huge part is simply because it was designed that way. Like Quzah said, it could've been the other way, but it isn't.


    Your syntax is slightly off. There shouldn't be a comma there, which might be part of your association issues. And yes, it is before a type, but it's not before the type it's connected to. It actually is after the type, it's just after the old type name, not the new one. The correct syntax is:
    Code:
    typedef old type specifier new_type_name;
    You care to explain the above to me? The syntax I posted was correct as well. The example I used is a 100% valid C typedef. There "shouldn't be?" I ought to go on the same flame-fest you did about how you should write the ISO committee or quit using C.

    Note that I left old type specifier with spaces to show you can have a multi-word type specifier, such as "struct foo_s", but the new_type_name must be a valid C identifier, like "foo_t". What you're really saying with the typedef is (pay attention to the colors):
    Code:
    typedef char * pchar;
    Yeah, that * stays on the left. The old type is a char pointer, or char *. The new name you want as a short hand is pchar. If you put it to the right of pchar, it just wouldn't make sense. Now, continuing on with pchar, we know that:
    Code:
    int x, y;
    // is the same as
    int x;
    int y;
    similarly:
    Code:
    pchar s, t;
    // is the same as
    pchar s;
    pchar t;
    So both s and t are of type pchar. That's the way the language was designed.
    Ah, yes, after re-evaluating the typedef syntax, I see what you're saying. Can't b

    Quote Originally Posted by anduril462 View Post
    Well, your misunderstanding may come from the asterisk eluding your understanding. But the lack of a parameter name doesn't really allude to the fact that the * should be bound more to the type than the variable name. Function parameters are different than regular variable declarations. Each one must specify a full type and be separated by commas. The name is mandatory in the declaration, but optional in prototypes because of what prototypes were designed for. C reads files top-down, an is only aware of things that it has already seen. So if you declare a function after you use it, or in another file to be linked in later, you need a prototype so the compiler can check the parameter count, parameter type and return type. The names of the variables don't matter in the prototype, it's just so the compiler can check if you're using it right. It doesn't care what you call it, as long as it's the right type.
    Yeah, I get what the compiler does - that part makes more sense since it's required in the definition I suppose, as it forms the same format of "regular" variables - and thank you for correcting my spelling, I thought they were spelled the same.

    Quote Originally Posted by anduril462 View Post
    Search! There, I told you...whaddaya gonna do about it? Yeah, that's what I thought.
    It wasn't meant as a threat, I was asking that people wouldn't do so.

    Quote Originally Posted by anduril462 View Post
    Not entirely true, considering your commas-in-typedefs issue above. Also, Quzah's examples showed you specific things you wouldn't be able to do if you had it your way. You should probably be a little less curt with those who are trying to help you.
    I feel you interpreted some hostility where there wasn't any. I'm glad you understand the answer to my question enough to extrapolate something that wasn't obvious in his post. He was telling me how to do stuff which I already knew and that I wasn't asking - that was in fact the only thing that kept popping up while I was googling it. So yes, since you know the answer to my question, obviously you can manipulate the meaning of a post which doesn't explain it to do so. I could do so as well - but then again if I knew the answer to my question then I wouldn't be asking it.

    Yeah, his examples showed it - if they did, then mine did too - but none of that answered the question - it simply illustrated how to typedef and declare multiple variables with pointers, which I stated in my post wasn't the problem at all. I feel your extrapolation of an answer from that is a stretch to say the least. Here's a simplified example of what I see you saying:
    Q: Why do I need a stack pointer
    A1: int a;
    Q: What does that have to do with anything?
    A2: His answer CLEARLY illustrates the offset of your SP from the BP for the purpose of stack allocation, you wouldn't be able to do that without a stack pointer - how did you NOT get that? Are you stupid?

    I apologize if I appeared curt to some people, but I believe the initial answer given was to a different question, a common one, yes, but one that I explicitly said I was not asking.

    Quote Originally Posted by anduril462 View Post
    It's not inconsistent. You have 3 gramatically separate elements. Just because all 3 things specify a type for something doesn't mean they must behave identically. The syntax for all variable declarations is consistent. So is all typedef syntax. So is all prototype syntax. But the 3 are different things, so they are each different from eachother.
    Okay, fair enough.

    Quote Originally Posted by anduril462 View Post
    "as it should" really ought to be "like I want it to". If you feel that strongly about an arbitrary decision that has no bearing on the usefulness of the language, then programming isn't for you. If you think it cripples the C language, too bad, nobody's gonna change after 40 years, but you certainly could write the ISO committee if it makes you feel better. If it just plain bugs you, then there are a bunch of other languages besides C you can pick from that don't even use an asterisk or give you pointers to mess with, or types, or functions.
    Yeah, "as it should be" was too strong of a phrase. It had nothing to do with what I wanted, the ISO committee, my feelings on C, crippling of the C language (wtf?), etc. I just felt it manipulated the type, not the variable. Though after reading lazerlight's post I see how it applies more to the variable than the type.

    Though please don't put words in my mouth, I never said I felt strongly about it - in fact I said the exact opposite - that I haven't bothered to care for the longest time, I never said it cripples the C language, and I never said anybody should change anything.

    So yes, at the time, when I felt it applies more to the type than variable, it bugged me, unfortunately due to the nature of my work, whether I wanted to or not (and I don't) switching to any of those "bunch of other languages" is extremely unfeasible. You try developing a driver in Python - lmk how it works out for you.

    Quote Originally Posted by anduril462 View Post
    Like Quzah said, typedef'ing pointers is nasty, and nobody likes it (okay, a few people do, but most experienced, professional programmers avoid it). Yes, you see it in industry, but lots of bad practices occur in industry. Industy is not the gold standard. The reason it's disliked is that it makes it hard to determine just how many levels of indirection (pointerness) you have in a given variable/type -- clear, easily maintainable code is the goal, not saving characters in source files. The use is acceptable if the typedef'ed pointer points to a completely opaque type/struct.
    You're right, industry is not the gold standard, but I feel when things are done commonly enough in industry, it becomes a standard.

    I never said it was anything about saving characters in a source file. Though I have no issues with it being used as a pointer to a struct, with a 'P' clearly denoted in front of the type. Though you don't always have the choice to do what you want as far as the coding style goes....and the more professional the company, the less choice you have.

    Quote Originally Posted by whiteflags View Post
    I think you answered your own question.

    Sometimes I think the only resource C and C++ truly handle is memory. How you do a file API and things like that aren't really all that important to the C language, (albeit if your discussing the C standard library it is ostensibly important) but you get to control memory pretty much built-in, and in C++ you can even do it without including any libraries.

    So if you mean to declare two ints it's one thing, if you mean a pointer and an int on the same line it's another. I don't see how it's a contradiction of the type system if what we're talking about is what's been done from the outset and no one is exactly hiding what the grammar is. I mean, this is only a problem because of how much you might want to do on one line.
    I just felt it was a contradiction before I read lazerlight's post illustrating how another way of looking at it is the <type> <ptr to/variable name> opposed to <pointer of type> <variable name> as I saw it before.

    Quote Originally Posted by laserlight View Post
    I'm not following you either. Note that the link is because I am quoting Stroustrup, so I allowed you to more easily read the source of the quote. My answer has nothing to do with style otherwise.


    The "shouldn't be" is subjective. Personally, I think that the asterisk should have been bound to the type name in the syntax, in view that it makes a declaration with initialition like this more consistent:
    Code:
    int* p = 0;
    If we write:
    Code:
    int *p = 0;
    and then use the argument that "*p is what is the int", it follows that we are initialising *p to 0, but that is not the case.


    Stroustrup has given a possible rationale, which I quoted. If you don't understand the rationale, that is because you are placing your emphasis on types rather than expressions. Fine, but then you just have to accept C's syntax for what it is.
    Thanks for that explanation, that explained what you/him were getting at, that made much more sense - and you're right, I was placing much more emphasis on the type. It wasn't as much of a matter of accepting or declining C's syntax - I did that a long time ago, it was just a matter of trying to understand the rationale for binding it to the variable, as I felt it pertained much more to the type, though I see your explanation, and that makes sense - didn't even think of that approach to it, which was why it made absolutely no sense to me why it would be bound to the variable.

    Quote Originally Posted by quzah View Post
    It isn't inconsistent.

    In one example you have a type, and you make a pointer to that. In the other, you have a type, and you aren't making a pointer to that type.
    Code:
    int *p;]
    p is a pointer to an int.
    Code:
    typedef int * mytype;
    mytype p;
    That's not a pointer. That's an instance of mytype, and mytype just happens to be defined as a pointer to an int.

    But in both cases what you are declaring is completely different. In the first you are declaring that p is a pointer to type int and in the second you are saying p is an instance of type mytype (which just happens to be a pointer type, but that's irrelevant). You are making one a pointer to a type and one an instance to type.

    That's completely different in what you are declaring.


    Quzah.
    Yeah, now that I understand the logic behind it, what you're saying makes a lot of sense.

    I understood it as:
    - make a pointer of that type
    Not:
    - make a variable which is defined as a pointer to said type

    I apologize if I seemed curt/nasty/hostile/negative towards you in my earlier response. Though I honestly don't see how your original post answered my question, even now, after understanding the answer.

    Quote Originally Posted by anduril462 View Post
    For you to chew on tomorrow:

    The comma you've seen in a typedef isn't for separating old type from new type. It's for making multiple new types out of one old type:
    Code:
    typedef int       this_is_an_int, this_is_also_an_int;
    ...
    this_is_an_int     x = 42;
    this_is_also_an_int     y = 17;
    EDIT: Ahh, I managed to merge in my head the "char" and "CHAR" from your examples. Yep, they are correct.
    I believe you're confused. I never said it was for separating an old type from a new type, nor did I allude to that, nor did my examples display that. I understand and understood what the typedef syntax does. I simply used it as an example of what I was asking, I could have just as easily said instead:
    Code:
    typedef char *pChar;
    ...but I didn't.

    Not quite sure where you got hung up on me thinking the comma did something it doesn't, but I apologize for the confusion it created.

    Quote Originally Posted by CommonTater View Post
    I see that C's favorite can of worms has been reopened...
    Personally I prefer the "compromise position"...

    Code:
    int * x;
    I hate that way :-P.

    I can't care less which side it's up against, realistically, I just didn't get why it was associated with the variable, not the type. Not quite the same can of worms, I think.



    EDIT: @ anduril: After reading your posts again, I think I see what happened. I think you've never seen comma separated typedef syntax before, therefore got the wrong impression of me having the wrong syntax, and how to specify a typedef, which is why you told me it's wrong, and tailored your response as so.
    Last edited by Syndacate; 07-27-2011 at 01:56 AM. Reason: New theory.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. How to spawn a process and have it keep ownership
    By paraglidersd in forum C Programming
    Replies: 5
    Last Post: 07-14-2011, 02:37 PM
  2. first ownership of a mutex
    By radeberger in forum C++ Programming
    Replies: 10
    Last Post: 03-27-2009, 07:52 AM
  3. pointer initializatin - where to put the asterisk?
    By laczfinador in forum C Programming
    Replies: 9
    Last Post: 01-18-2009, 10:36 AM
  4. pointer with double asterisk
    By skringla in forum C Programming
    Replies: 10
    Last Post: 11-27-2008, 06:33 AM
  5. Ownership over a button
    By BraneMxm in forum C# Programming
    Replies: 4
    Last Post: 06-08-2007, 04:20 AM

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