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?
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.
-
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?
If you always puts your declarations on separate lines (or separated by ';') it doesn't matter. But if you do -- be aware. Say that you have; char* c; char* d; char* e; and, for some reason, probably even a good one, decides to put them on one line ... in a bit of hurry so that you ends up with; char* c,d,e; But if you had char *c; char *d; char *e; there is a pretty good chance you would end up with; char *c, *d, *e; This is also the reason for the typedef's of pointers, eg. typedef char * char_p; char_p c; char_p d; char_p e; would be char_p c, d, e; rgds /Jonas ps. char* c, d, e; --> char* c; char d; char e;
-
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.
Great answer. When I define a pointer I'm using `char *p;` because this is pointer. It stores an address and points a `char` value in this address. So, '*' is serving as a pointing device for (p) address register, (I think) it must be declared with address register.
-
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
Great answer. When I define a pointer I'm using char *p; because this is pointer. It stores an address and points a char value in this address. So, '*' is serving as a pointing device for p address register, (I think) it must be declared with address register.
-
If you always puts your declarations on separate lines (or separated by ';') it doesn't matter. But if you do -- be aware. Say that you have; char* c; char* d; char* e; and, for some reason, probably even a good one, decides to put them on one line ... in a bit of hurry so that you ends up with; char* c,d,e; But if you had char *c; char *d; char *e; there is a pretty good chance you would end up with; char *c, *d, *e; This is also the reason for the typedef's of pointers, eg. typedef char * char_p; char_p c; char_p d; char_p e; would be char_p c, d, e; rgds /Jonas ps. char* c, d, e; --> char* c; char d; char e;
-
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?
As an aside, in the last century the leading PC C++ compiler vendor was not Microsoft but Borland. One day they got too big for their boots and issued a proclamation which dictated that all users of their IDE must code in their prescribed style - which included suffixing the "*" to the type instead of K&R's prefixing "*" to the variable name. It was at this point that I stopped using Borland. For the sake of consistency, I can't resist also applying the K&R style to references too; although I'm clearly flying in the face of convention from the majority of code examples that I see in books and on-line.
-
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.