|
How the hell you can break such a rule? Please refracte (does this word really exists?) all your source code ...please!!! 
[Edit]
Btw, I don't think Lopidar is right. Started with Modula and read a lot from "Niklaus Wirth" theories, also I did a lot of Compiler implementations 
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
0x01AA wrote: Please refracte
The correct word would be "refactor". But at my age I may not have enough time to get it all done. 
|
|
|
|
|
So I Need to write: Do refactor your code?
Quote: But at my age I may not have enough time to get it all done
Stop thinking like this!! You have all the time
It does not solve my Problem, but it answers my question
modified 19-Jan-21 21:04pm.
|
|
|
|
|
(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
modified 29-May-18 13:11pm.
|
|
|
|
|
char *c was the old K&R way.
Yes char* c looks better.
modified 27-May-18 15:17pm.
|
|
|
|
|
I prefer "char* c". Long ago I used the other form but an article I read long ago convinced me that the 'type' should be emphasized as different from the variable.
|
|
|
|
|
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.
|
|
|
|
|
To remind users that
char* a , b
may not do what they intend.
|
|
|
|
|
|
Which is why I never use comma separated variable declarations.
char* a , b, c[12], *d[5];
char* a;
char b;
char c[12];
char* d[5];
www.pointwise.com
|
|
|
|
|
Nor do I. I'm of the opinion that doing so should at least raise a warning.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
OK, fair enough.
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.
|
|
|
|
|
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];
0[x] = 1[x]; is perfectly valid and utterly disgusting in C/C++.
Software Zen: delete this;
|
|
|
|
|
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
|
|
|
|
|
Chris Maunder wrote: void pointers make me sad.
cheers
Chris Maunder
So appearently, you haven't seen any void pointers lately
|
|
|
|
|
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)?
|
|
|
|
|
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;
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
