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?
As others have pointed out before, the issue is char* c, d; vs. char *c, *d; The C++ grammar says that a declaration has the form decl-specifier-seq init-declarator-list; char is the decl-specifier, and what follows is one or more declarators (with optional initializers). *c is a declarator, and *d (or plain d) is another one. So, if you write char* c then you're needlessly confusing your (and your reader's) mental image of the C++ grammar.
-
Why 68? Well, it was a fun language, especially for its time. But the language did't define a concrete syntax at all (there was an Algol68 with keywords in German - fully conformant to the Algol68 standard), so you couldn't use it to settle any concrete syntax arguments. Switching to C# is really a far better solution: Make everything pointers, so that you never say that it is a pointer. If it is an object, then a name of that object is a pointer to it. No way to avoid. That makes it so much simpler, never having to worry about this being a struct, that being a pointer to a struct and something else being a pointer to a pointer to an array of pointers to a struct...
-
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?
Actually, the reason is that 'char*' is not a type. A '*' belongs to the variable. In other words, this is valid C code:
char *pch, ch;
ch = 'A';
pch = &ch;I'm a pure C programmer. I don't know how it works for C++ though.
-
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 K&R answer is probably good enough. But I also taught it as the algebraic expression, that * = 1/& (or * is the inversion of &). Therefore declaring "char *c" says "*c" is a character, and &(*c) => Pointer, but & and * cancel. Therefore c is a pointer to a character. So, if you view it as *c is a the char in question, I think it explains that approach pretty clearly. Having learned C a VERY long time ago, I have always used, and mostly saw "char *c" or "char c[]"! the scary part in the old days was explaining how: 13[c] = 'x'; would be handled, as it DID compile! and according to the answer definition of [] at the time, it was converted to: *(13+c) = 'x'; and therefore was the same as c[13] = 'x';
-
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 *cbetter aligns with C/C++ philosophy, butchar* cis safer. The syntaxchar *csays*c(cdereferenced) is achar, which makesca pointer tochar. However, teaching/learning this syntax/philosophy can be hard when people are just getting introduced to pointers. Also, the declarationchar *c, dmakescachar*, butdachar. This confuses beginners who are used to declarations such asint a, bwhich makes bothaandbints. Thus, the declarationchar* cis preferred: easier to learn and safer. -
char *cbetter aligns with C/C++ philosophy, butchar* cis safer. The syntaxchar *csays*c(cdereferenced) is achar, which makesca pointer tochar. However, teaching/learning this syntax/philosophy can be hard when people are just getting introduced to pointers. Also, the declarationchar *c, dmakescachar*, butdachar. This confuses beginners who are used to declarations such asint a, bwhich makes bothaandbints. Thus, the declarationchar* cis preferred: easier to learn and safer.nullusDefectus wrote:
Also, the declaration
char *c, dmakescachar*, butdachar. This confuses beginners who are used to declarations such asint a, bwhich makes bothaandbints. Thus, the declarationchar* cis preferred: easier to learn and safer.Your claim and conclusion are backwards! It's writing
char* c, d;that confuses beginners for the exact reason that you give. Writingchar *c, d;is the correct way to teach, learn, and remind yourself and readers of your code that the*applies toconly. Given the language grammar...simple-declaration ::= decl-specifier-seq init-declarator-list(optional) ;
Note the space ---^... writing...
char *c;
---^... also demonstrates that you know what you're doing. This is how you explain it to beginners and they will remember... ;)
-
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 always the * next to the variable since you can convert most types into a pointer with the * modifier. Otherwise, this looks inconsistent:
char *p0;
char *p1, *p2;Uwe Baemayr Senior Software Developer Micro Focus
-
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
My 2 cents, I prefer
char* c;
too, as I've learned years ago. To quote Wikipedia and what I've learned (Pointers section) : "A pointer is a data type that contains the address of a storage location of a variable of a particular type." Nevertheless, this same Wikipedia section points out that writing it is a matter of style :
char* c;
char * c;
or
char *c;
All right for everyone :) Not mentioning the confusing writing for arrays of pointers... So the type of "char*" is a "pointer on a char". The type of "int*" is a "pointer on an int". And so on...
-
My 2 cents, I prefer
char* c;
too, as I've learned years ago. To quote Wikipedia and what I've learned (Pointers section) : "A pointer is a data type that contains the address of a storage location of a variable of a particular type." Nevertheless, this same Wikipedia section points out that writing it is a matter of style :
char* c;
char * c;
or
char *c;
All right for everyone :) Not mentioning the confusing writing for arrays of pointers... So the type of "char*" is a "pointer on a char". The type of "int*" is a "pointer on an int". And so on...
Member 10753505 wrote:
arrays
int x[2];
= 1[x];is perfectly valid and utterly disgusting in C/C++.
Software Zen:
delete this; -
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?
* `char* c` is preferred for C++. See (1). * `char *a, *b, *c;` is sloppy - separate each declaration. See (2) * For those arguing that pointers are not types, I would say that this amounts to arguing semantics (syntax?) at best. The C++ Standard (3) frequently talks about pointers as types. Moreover, operators dealing with the type system, such as `typeid`, `decltype` deal with pointers as types. The entire _goal_ of smart pointers is to give types that can be transparently treated like pointers (along with additional behavior - object lifecycle mgmt., typically). Overloading, resolution, etc., all deal in "types" and pointers is part-and-parcel to this. * (Practical usefulness) The "right to left" reading gives the intuitive type of a name. This works better than the "whitespace association" model. Consider:
int* const volatile p1; // p1 is a volatile const pointer to an int
int *const volatile p2; // (*const volatile p2) is an int?* I'm declaring the name `a` to be a pointer to a `MyObject`, I'm not declaring the `MyObject` itself, I'm just declaring the _pointer_. To the point of my second bullet above, `MyObject a, *b` is nasty, because for a C++ programmer, the first variable is declaring an object, the second is declaring just a pointer. If the context of this is declaring local/global variables, the `a` involves a (potentially non-trivial) constructor, which entails who knows what. `b` is simply telling the compiler to reserve some bytes for a pointer. (Something similar can be said where these are fields of a class/struct/union.) These are wildly different things in C++. 1. [Stroustrup: C++ Style and Technique FAQ](http://www.stroustrup.com/bs\_faq2.html#whitespace) 2. [CppCoreGuidelines/CppCoreGuidelines.md at master · isocpp/CppCoreGuidelines · GitHub](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Res-name-one) 3. [Working Draft, Standard for Programming Language C++](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf)
-
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 didn't realize most preferred 'char* c' as opposed to 'char *c'. My initial intro to C was K&R so I started out with the former, but long ago switched to the latter, it just feels better somehow. I will say this in regards to 'char *c', though I realize this is wholly a religious debate and do not wish to antagonize, but it makes this look better: 'char *a, *b, *c;' Full disclosure, I use the 'goto' statement too.
-
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.
(Just a thought) "*" works like a "modifier" (in this case); so there "should" be a space ? (e.g. char * e); But does it then become an "operator" ? While "_e" is a valid name; as a name, "*e" is NOT valid. (What would a "cross-reference" listing say about "names" and "type"). If we keep the same "characters", the one that feels "more satisfying" (to me) is:
*char e;
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
My 2 cents, I prefer
char* c;
too, as I've learned years ago. To quote Wikipedia and what I've learned (Pointers section) : "A pointer is a data type that contains the address of a storage location of a variable of a particular type." Nevertheless, this same Wikipedia section points out that writing it is a matter of style :
char* c;
char * c;
or
char *c;
All right for everyone :) Not mentioning the confusing writing for arrays of pointers... So the type of "char*" is a "pointer on a char". The type of "int*" is a "pointer on an int". And so on...
Meh. They are technically a data type but they need to lean on someone else to have meaning in their lives. They're like the really needy data type the other data types only play with because he has cool toys.
cheers Chris Maunder
-
Why 68? Well, it was a fun language, especially for its time. But the language did't define a concrete syntax at all (there was an Algol68 with keywords in German - fully conformant to the Algol68 standard), so you couldn't use it to settle any concrete syntax arguments. Switching to C# is really a far better solution: Make everything pointers, so that you never say that it is a pointer. If it is an object, then a name of that object is a pointer to it. No way to avoid. That makes it so much simpler, never having to worry about this being a struct, that being a pointer to a struct and something else being a pointer to a pointer to an array of pointers to a struct...
Thank you for your reply. I was a programmer years ago, and don't know C# too well. I'd be interested to know how, in C#, you would do this ... REF INT ri; INT i1, i2; BOOL condition; ... ( condition | ri := i1 | ri := i2 ); ri := 1; ... It's probably blindingly obvious, but, as I say, I'm not conversant with 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?
-
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?
.jpg wrote:
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?
My guess is that most C programmers hail from the K&R (Kernighan and Ritchie) days and I believe that char *c is the form they would have used. (I lost my dear old K&R years ago). Beyond that, it's probably just personal habit.
If you think hiring a professional is expensive, wait until you hire an amateur! - Red Adair
-
To remind users that
char* a , bmay not do what they intend.Which is why I never use comma separated variable declarations.
char* a , b, c[12], *d[5]; // ugly and prone to misinterpretation
char* a; // no ambiguities here!
char b;
char c[12];
char* d[5]; -
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?
My $0.02. In general variables are declared as:
type varname;
So ask the questions: What is the type of varname? What is the varname?
char c; // char is the type. c is var name
char* c; // char* is the type. c is the var namedouble d; // double is type. d is var name
float f; // float is type. f is var namedouble* d; // double* is type. d is var name
float* f; // float* is type. f is var nameUltimately, BOTH ARE CORRECT. As long as all devs in a team/organization use the same code format style guide, IT DOESN'T MATTER. Just be consistent.
-
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 both the C and C++ grammars work. The asterisk binds to the thing being declared, not the type. A declaration like
int* a, b;
is parsed as
int (*a), b;
Declarations in C (and simple declarations in C++) are a sequence of declaration specifiers followed by one or more (optionally initialized) declarators. The declarator is what specifies the name along with the the pointer-ness, array-ness, and/or function-ness of the thing being declared. Given a sequence of declaration specifiers
D1, then the following are all true:D *p; // p is a pointer to D
D a[N]; // a is an array of D
D f(); // f is a function returning DD *ap[N]; // ap is an array of pointers to D
D *fp(); // fp is a function returning a pointer to DD (*pa)[N]; // pa is a pointer to an array of D
D (*pf)(); // pf is a pointer to a function returning DD (*fpa())[N]; // fpa is a function that returns a pointer to an array of D
D (*apf[N])(); // apf is an array of pointers to functions returning D// even more complex combinations are possible!!!
The things following
Dare the declarators.*pis a declarator, as isa[N], as is*ap[N], as is(*pa)[N]. Since both[]and()operators have higher precedence than unary*, an expression like*a[N]parses as*(a[N]). To declare a pointer to an array or a pointer to a function, you must explicitly group the*operator with the thing that points to the array or function. This is why the common convention (at least among C programmers) ischar *c;and notchar* c;. I understand where thetype* nameandtype& nameconventions came from in C++, and when I write C++ I follow that convention. But I feel dirty every time I do it.
1. Declaration specifiers include storage class specifiers like
static,auto, andtypedef, type specifiers likeint,double,struct foo, and type qualifiers likeconstorvolatile