Why does most C/C++ developer prefers char *c instead of char* c?
-
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.