Why does most C/C++ developer prefers char *c instead of char* c?

[Kirk 10389821]

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';

[nullusDefectus]

char *c better aligns with C/C++ philosophy, but char* c is safer. The syntax char *c says *c (c dereferenced) is a char, which makes c a pointer to char. However, teaching/learning this syntax/philosophy can be hard when people are just getting introduced to pointers. Also, the declaration char *c, d makes c a char*, but d a char. This confuses beginners who are used to declarations such as int a, b which makes both a and b ints. Thus, the declaration char* c is preferred: easier to learn and safer.

[Hans Salvisberg]

nullusDefectus wrote:

Also, the declaration char *c, d makes c a char*, but d a char. This confuses beginners who are used to declarations such as int a, b which makes both a and b ints. Thus, the declaration char* c is 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. Writing char *c, d; is the correct way to teach, learn, and remind yourself and readers of your code that the * applies to c only. 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... ;)

[ZimFromIRK]

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

[PhM33]

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

[Gary Wheeler]

Member 10753505 wrote:

arrays

int x[2];

= 1[x];

is perfectly valid and utterly disgusting in C/C++.

Software Zen: delete this;

[SeattleC]

char *c; matches the structure of the C grammar. If you declare three pointers, the declaration looks like char *c, *d, *e; But people think of the '\*' as belonging with the type, so they write char* c;

[Jesse Connell]

* `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)

[PNutHed]

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.

[Lost User]

(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

[Chris Maunder]

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

[SawDid]

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#

[englebart]

Consider also multi level pointers: char **ppCh; char *c[]; etc.

[ClockMeister]

.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

[david garlisch]

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];

www.pointwise.com

[david garlisch]

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 name

double d; // double is type. d is var name
float f; // float is type. f is var name

double* d; // double* is type. d is var name
float* f; // float* is type. f is var name

Ultimately, 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.

www.pointwise.com

[jfbode1029]

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 D

D *ap[N]; // ap is an array of pointers to D
D *fp(); // fp is a function returning a pointer to D

D (*pa)[N]; // pa is a pointer to an array of D
D (*pf)(); // pf is a pointer to a function returning D

D (*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 D are the declarators. *p is a declarator, as is a[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) is char *c; and not char* c;. I understand where the type* name and type& name conventions 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, and typedef, type specifiers like int, double, struct foo, and type qualifiers like const or volatile

[PIEBALDconsult]

Nor do I. I'm of the opinion that doing so should at least raise a warning.

[PIEBALDconsult]

I still prefer Borland C/C++ when I write C; I don't recall being forced one way or the other, but I'll try it later. None of the following compilers complained about char* a , b:

HP C V7.3-009 on OpenVMS Alpha V8.3
Borland C++ 5.5 for Win32 Copyright (c) 1993, 2000 Borland
gcc version 3.2 (mingw special 20020817-1)
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86

I expected HP C to complain because I compiled with CHECK messages enabled:

          CHECK           Messages reporting code or practices that,
                          although correct and perhaps portable, are
                          sometimes considered ill-advised because
                          they can be confusing or fragile to
                          maintain.  For example, assignment as the
                          test expression in an "if" statement.

[Chad3F]

To me, char* c looks badly formatted, same as if someone did x+ 3. :wtf: Traditionally, I would use char *c, but after using java for several years, I prefer to use char * c now.