The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I've always liked option 3: char * c. It avoids the problems char* c, d; can cause but still keeps it separate from the name. * is just like const or any other modifier. You wouldn't write constchar* c so why mash them together just because it's a single character (and allowed)?
Because that's how the compiler parses it. The * binds to the variable not the type.
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).
"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.
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...
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 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.
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 bints.
Thus, the declaration char* c is preferred: easier to learn and safer.
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++.
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
the type of p is "pointer to char" or char *, but that type is obtained by the combination of the type specifier char and the pointer declarator*p. Sure, you can write it as char* p;, but it will be parsed as char (*p);.
T *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))
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"
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.
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
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.
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
modified 30-May-18 12:28pm.
Last Visit: 29-Sep-20 10:47 Last Update: 29-Sep-20 10:47