Why does most C/C++ developer prefers char *c instead of char* c?
-
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 -
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];Nor do I. I'm of the opinion that doing so should at least raise a warning.
-
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.
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 80x86I 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. -
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)
There are indeed pointer types, but there are no pointer type specifiers. The pointer-ness of something is specified by a combination of the type specifier(s) and the declarator. For a pointer like
char *p;
the type of
pis "pointer tochar" orchar *, but that type is obtained by the combination of the type specifiercharand the pointer declarator*p. Sure, you can write it aschar* p;, but it will be parsed aschar (*p);. Something likeT *p1, *p2, *p3;
should be perfectly understandable to anyone who understands C and C++ declaration syntax, but nobody does because it's not taught properly for some bizarre reason. It's such a fundamental part of the language, but it's invariably glossed over in every introductory text so as not to scare off beginners. So people inevitably bluescreen the first time they see something like a pointer to an array or a pointer to a function because the simplistic-to-the-point-of-being-wrong version of C declaration syntax they were taught doesn't account for it. Yes, pointers are scary and difficult to understand at first. They're also a fundamental part of C programming (less so C++, but still important). C (and C++) declaration syntax needs to be taught properly and completely. But since it isn't, we need to come up with a bunch of coding standards to make up for it. So, no more than one declaration per line, because it's too hard to explain how
char* a, b;really works. Once you understand the rules, pointer declarations (including pointers to arrays, pointers to functions, pointers to arrays of functions returning pointers to arrays of pointers to int) make perfect sense. But apparently nobody understands the rules, so the language looks arbitrary and capricious. -
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
-
Not always : a void pointer lives its own live and you can made point it on every type or on... nothing ! :)
void pointers make me sad.
cheers Chris Maunder
-
There are indeed pointer types, but there are no pointer type specifiers. The pointer-ness of something is specified by a combination of the type specifier(s) and the declarator. For a pointer like
char *p;
the type of
pis "pointer tochar" orchar *, but that type is obtained by the combination of the type specifiercharand the pointer declarator*p. Sure, you can write it aschar* p;, but it will be parsed aschar (*p);. Something likeT *p1, *p2, *p3;
should be perfectly understandable to anyone who understands C and C++ declaration syntax, but nobody does because it's not taught properly for some bizarre reason. It's such a fundamental part of the language, but it's invariably glossed over in every introductory text so as not to scare off beginners. So people inevitably bluescreen the first time they see something like a pointer to an array or a pointer to a function because the simplistic-to-the-point-of-being-wrong version of C declaration syntax they were taught doesn't account for it. Yes, pointers are scary and difficult to understand at first. They're also a fundamental part of C programming (less so C++, but still important). C (and C++) declaration syntax needs to be taught properly and completely. But since it isn't, we need to come up with a bunch of coding standards to make up for it. So, no more than one declaration per line, because it's too hard to explain how
char* a, b;really works. Once you understand the rules, pointer declarations (including pointers to arrays, pointers to functions, pointers to arrays of functions returning pointers to arrays of pointers to int) make perfect sense. But apparently nobody understands the rules, so the language looks arbitrary and capricious.I've noticed you italicized a lot of things relating to "understanding" how the language works. Many who do understand it feel the declaration syntax sucks inherited from C is a PITA. If only programmers were taught declaration syntax, they'd come across this and the intention would be clear:
int (*f(int x))[3]
{
// ...
}Also, I think my argument is somewhat supported by:
using T = char*;
T a, b;Yes, I understand the grammar, and yes, I understand how this is different vis-a-vis grammar, but I'm not arguing about the grammar, I'm arguing about what _style_ is more "C++-esque". Here, T is the type specifier with no pointer declarator. The _type_ is actually now `char*` So when declaring these two names, they have the same types. That's the more natural use case one would expect from a programming language. Clearly, this is a matter of taste, but again, I'll point out that Bjarne Stroustrup is clearly on my side of this disagreement. Here's a funny quote from one of the links I included in my first post: "The flip side of this is that you have to deal with old mistakes and with compatibility problems. For example, I consider the C declarator syntax an experiment that failed" From this interview: [Slashdot | Interviews | C++ Answers From Bjarne Stroustrup](http://www.stroustrup.com/slashdot\_interview.html)
-
void pointers make me sad.
cheers Chris Maunder
-
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 of this: char *c, *p, a, *b, d; or a better way to write that: char *c = nullptr, *p = nullptr, a = 5, *b = nullptr, d = 10; (it took out my tabs...)
-
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.
Lopatir wrote:
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++.
Far as I can recall it was a columnist in the C++ Programmers Journal. I suspect that they did in fact have a passing familiarity with the language. And since at least two columnists in that magazine participated in the C++ ANSI committee I suspect that their opinion on that subject of C++ would have carried more weight than any other random developer. They provided a rational for why that form was more appropriate which, far as I can recall, was not grounded solely in the semantics in the language but more in common usage of type specifiers. But I could certainly be mistaken about what they actually said. Not to mention of course "The Annotated C++ Reference Manual" written by Ellis and Stroustrup which in section 4.7 has the following code examples.
void f(char* cptr, void* vptr)
...
int* p1 =
...
char* cptr;
int* iptr;
void* vptr;So seems like the creator of the language prefers that form as well. My original usage was grounded in the form you are championing but that was based on K&R. I found the article I read persuasive enough that I started using the other form.