Thread: Pointer Asterisk Ownership Questions...

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.

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?:

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:

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

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.

Originally Posted by Syndacate

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.

Originally Posted by Syndacate

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.

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.

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.

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.

Originally Posted by Syndacate

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.

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.

Originally Posted by anduril462

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

Originally Posted by anduril462

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.

Originally Posted by anduril462

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.

Originally Posted by anduril462

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.

Originally Posted by anduril462

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.

Originally Posted by anduril462

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

Originally Posted by anduril462

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.

Originally Posted by whiteflags

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.

Originally Posted by laserlight

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.

Originally Posted by quzah

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.

Originally Posted by anduril462

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.

Originally Posted by CommonTater

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.