Why does most C/C++ developer prefers char *c instead of char* c?
-
char is a type and c is a name, to me, it always make more sense to put the name alone and have the type together, like "char* c", I can tell immediately that it is a pointer to a char, so its always goes like [type] [name]. But in contrast, most C/C++ code I found prefer the other way around, like "char *c". Is there any specific reasons why this is so?
I also prefer char* c as char* is a type, in this case a pointer to a char.
Everyone has a photographic memory; some just don't have film. Steven Wright
-
char is a type and c is a name, to me, it always make more sense to put the name alone and have the type together, like "char* c", I can tell immediately that it is a pointer to a char, so its always goes like [type] [name]. But in contrast, most C/C++ code I found prefer the other way around, like "char *c". Is there any specific reasons why this is so?
Goes back to K&R, they invented the thing and people followed their style. also in C you cant declare arrays that way:
char c[]; /* compiles just fine */
char[] d; /* error */
// so followig the same
Tis the style of this language, inasmuch to continue that style far more logical to write */
char *e;1. and so "char* c" is stylistically wrong in both C & C++. (And older compilers will correctly flag that as an error.) 2. In C "char *" is not a type, it's a pointer to a type. Yup, pointers are not types, they are pointers. ... cats, dogs and cows are types of animal, beef is not an animal but it does 'refer' to one
Signature ready for installation. Please Reboot now.
-
Goes back to K&R, they invented the thing and people followed their style. also in C you cant declare arrays that way:
char c[]; /* compiles just fine */
char[] d; /* error */
// so followig the same
Tis the style of this language, inasmuch to continue that style far more logical to write */
char *e;1. and so "char* c" is stylistically wrong in both C & C++. (And older compilers will correctly flag that as an error.) 2. In C "char *" is not a type, it's a pointer to a type. Yup, pointers are not types, they are pointers. ... cats, dogs and cows are types of animal, beef is not an animal but it does 'refer' to one
Signature ready for installation. Please Reboot now.
I would say "*" is a type modifier :-D [Edit]
Quote:
In C "char *" is not a type
Really? Ok I don't know C, but I think this is also allowed in C
typedef char@ theCharPointerType;@ instead of *, because * seems to be a Problem in cp And if the above is ok in C, how can you state that a pointer to char is not a type?It does not solve my Problem, but it answers my question
-
char is a type and c is a name, to me, it always make more sense to put the name alone and have the type together, like "char* c", I can tell immediately that it is a pointer to a char, so its always goes like [type] [name]. But in contrast, most C/C++ code I found prefer the other way around, like "char *c". Is there any specific reasons why this is so?
char *c was the old K&R way. Yes char* c looks better.
-
I would say "*" is a type modifier :-D [Edit]
Quote:
In C "char *" is not a type
Really? Ok I don't know C, but I think this is also allowed in C
typedef char@ theCharPointerType;@ instead of *, because * seems to be a Problem in cp And if the above is ok in C, how can you state that a pointer to char is not a type?It does not solve my Problem, but it answers my question
cant be a type modifier either, char *c --> * means pointer, "char" is is the default 'pointed to' modifier for that declaration. In the language definition it's valid to cast a * to address any [other] type. If the type was considered "char*" or in fact if "char" had anything to do with 'the type' then casting pointers to address other type would become wrong. hence:
char* c" /* is wrong, "char*" is NOT the type because there is no such thing, it's wrong, plain wrong! */
char *c /* is the proper form */Signature ready for installation. Please Reboot now.
-
cant be a type modifier either, char *c --> * means pointer, "char" is is the default 'pointed to' modifier for that declaration. In the language definition it's valid to cast a * to address any [other] type. If the type was considered "char*" or in fact if "char" had anything to do with 'the type' then casting pointers to address other type would become wrong. hence:
char* c" /* is wrong, "char*" is NOT the type because there is no such thing, it's wrong, plain wrong! */
char *c /* is the proper form */Signature ready for installation. Please Reboot now.
-
I would say "*" is a type modifier :-D [Edit]
Quote:
In C "char *" is not a type
Really? Ok I don't know C, but I think this is also allowed in C
typedef char@ theCharPointerType;@ instead of *, because * seems to be a Problem in cp And if the above is ok in C, how can you state that a pointer to char is not a type?It does not solve my Problem, but it answers my question
Lopatir is correct. The way to read the declaration
char *c
is: c (the name of the variable) is a pointer (the * prefix) to a character (the type) where the pointer property actually belongs to the variable, not the type. Having said that I always write:
char* c
;)
-
Lopatir is correct. The way to read the declaration
char *c
is: c (the name of the variable) is a pointer (the * prefix) to a character (the type) where the pointer property actually belongs to the variable, not the type. Having said that I always write:
char* c
;)
How the hell you can break such a rule? Please refracte (does this word really exists?) all your source code ...please!!! :laugh: [Edit] Btw, I don't think Lopidar is right. Started with Modula and read a lot from "Niklaus Wirth" theories, also I did a lot of Compiler implementations ;)
It does not solve my Problem, but it answers my question
-
How the hell you can break such a rule? Please refracte (does this word really exists?) all your source code ...please!!! :laugh: [Edit] Btw, I don't think Lopidar is right. Started with Modula and read a lot from "Niklaus Wirth" theories, also I did a lot of Compiler implementations ;)
It does not solve my Problem, but it answers my question
-
0x01AA wrote:
Please refracte
The correct word would be "refactor". But at my age I may not have enough time to get it all done. :((
-
char is a type and c is a name, to me, it always make more sense to put the name alone and have the type together, like "char* c", I can tell immediately that it is a pointer to a char, so its always goes like [type] [name]. But in contrast, most C/C++ code I found prefer the other way around, like "char *c". Is there any specific reasons why this is so?
-
char is a type and c is a name, to me, it always make more sense to put the name alone and have the type together, like "char* c", I can tell immediately that it is a pointer to a char, so its always goes like [type] [name]. But in contrast, most C/C++ code I found prefer the other way around, like "char *c". Is there any specific reasons why this is so?
To remind users that
char* a , bmay not do what they intend. -
char is a type and c is a name, to me, it always make more sense to put the name alone and have the type together, like "char* c", I can tell immediately that it is a pointer to a char, so its always goes like [type] [name]. But in contrast, most C/C++ code I found prefer the other way around, like "char *c". Is there any specific reasons why this is so?
the variable is the type, and the type stays the type. The * goes with the variable because you're modifying defining how the variable will be using the type. You're not, as it were, modifying the type.
cheers Chris Maunder
-
I prefer "char* c". Long ago I used the other form but an article I read long ago convinced me that the 'type' should be emphasized as different from the variable.
how do you do: "char c[]" ?? "char[] c" wont compile, so that "type/name" logic is already broken for C/C++. The article you read was written by someone that either referred to a different programming language, or doesn't understand the C/C++ language definitions; char* is not a type in C/C++. For real fun, have you considered "char *c[]" ... writing that the wrong way as "char* c[]" obviously looks, reads and is just plain wrong because that would read as an "array of pointers" when what I wanted was a "pointer to an array." Personal style is OK, but justifying it as proper with a mistake isn't. In short: if you prefer the look of "char* c" carry on, just remember it's a pointer, not a type.
Signature ready for installation. Please Reboot now.
-
the variable is the type, and the type stays the type. The * goes with the variable because you're modifying defining how the variable will be using the type. You're not, as it were, modifying the type.
cheers Chris Maunder
Chris Maunder wrote:
the variable is the type, and the type stays the type. The * goes with the variable because you're modifying defining how the variable will be using accessing the type value. You're not, as it were, modifying the type.
Signature ready for installation. Please Reboot now.
-
char is a type and c is a name, to me, it always make more sense to put the name alone and have the type together, like "char* c", I can tell immediately that it is a pointer to a char, so its always goes like [type] [name]. But in contrast, most C/C++ code I found prefer the other way around, like "char *c". Is there any specific reasons why this is so?
I've always liked option 3:
char * c. It avoids the problemschar* c, d;can cause but still keeps it separate from the name.*is just likeconstor any other modifier. You wouldn't writeconstchar* cso why mash them together just because it's a single character (and allowed)? -
Chris Maunder wrote:
the variable is the type, and the type stays the type. The * goes with the variable because you're modifying defining how the variable will be using accessing the type value. You're not, as it were, modifying the type.
Signature ready for installation. Please Reboot now.
OK, fair enough.
cheers Chris Maunder
-
To remind users that
char* a , bmay not do what they intend. -
char is a type and c is a name, to me, it always make more sense to put the name alone and have the type together, like "char* c", I can tell immediately that it is a pointer to a char, so its always goes like [type] [name]. But in contrast, most C/C++ code I found prefer the other way around, like "char *c". Is there any specific reasons why this is so?
When doing more than one variable declaration makes sense to put the * correctly, or you do not get what you expect. When writing: char* a,b,c; you get the equivalent of: char *a,b,c; and you would probably expect: char *a,*b,*c;
-
char is a type and c is a name, to me, it always make more sense to put the name alone and have the type together, like "char* c", I can tell immediately that it is a pointer to a char, so its always goes like [type] [name]. But in contrast, most C/C++ code I found prefer the other way around, like "char *c". Is there any specific reasons why this is so?
Because that's how the compiler parses it. The * binds to the variable not the type. Think about char* a, b; This suggests that b is also a char *, but actually it is only a char. Much clearer when you write char *a, b; (Not that I would advocate doing either - even better to have two separate declarations - but it illustrates the point).
Ian Brockbank "Legacy systems are systems that are not protected with a suite of tests. ... You are building legacy code every time you build software without associated tests." - Mary and Tom Poppendieck, Implementing Lean Software Development.