|
I use C and try to be consistent
Type *p;
example
typedef struct
{
char form[LINE_SIZE]; // command form */
int narg; // number of arguments */
char error; // error code */
} LANG;
LANG *LP;
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
|
I agree, but as mentioned in my post below... a thing I don't do but is very common:
const char
*a= "a",
*b= "b";
tells us, in this case we are something wrong... 
|
|
|
|
|
This doesn't bother me, because I never do this kind of thing.
|
|
|
|
|
Type* p;
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
type *p;
Because
type* p, q
doesn't do what it looks like it does. Of course, that kicks off the argument about multiple variables per type declaration.
Keep Calm and Carry On
|
|
|
|
|
k5054 wrote: Of course, that kicks off the argument about multiple variables per type declaration.
Not an argument: don't do that.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
I prefer
Type* p;
And this only because my compiler gives a wrning when I don't use a parameter in a method:
void Method(char x, char* y)
To get rid of the warning I need to do e.g.this
void Method(char x, char* /*y*/)
On the other hand if I would do something like this (what I'm not doing ...)
const char *a= "a", *b= "b";
Then I get angry because the language itself is not what I would name 'consistent' 
|
|
|
|
|
type* (pointer is part of type)
Now moving on: do you do "west const" or "east const"?
Standard C++[^]
(surely a lot of people - me included - don't want to do productive work today)
Mircea
modified 12-Dec-22 13:58pm.
|
|
|
|
|
If pointer is part of the type, make it! Make a typedef and use that when declaring variables.
type* x, y; - is y of a pointer type? You know that it isn't. Lots of problems have been caused by making it appear as if x and y have the same type. (Thankfully, the compiler will catch most such wrongful assumptions.) If you change it to
type y, *x; - is now the type definition for variable x split into two parts, separated by a variable declaration?
If you make a typedef, you have a clear, all-in-one-place type definition, not cluttered up by variables. And you would avoid the risk of someone assuming, in the first example, that x and y are of the same type.
|
|
|
|
|
trønderen wrote: Make a typedef and use that when declaring variables.
Amen!
Edit:
This is one of the (many) early failings of "C". When I write "C" I try to avoid mixing pointer to type and type declarations on the same line and try to keep pointer declarations on their own line.
When I do "C++" I'm mostly using stuff like
std::unique_ptr<something> a, b;
If I see two naked pointers in the same declaration, that is most likely a code smell.
Mircea
modified 12-Dec-22 13:21pm.
|
|
|
|
|
I generally agree with you, but I am not all in on that agreement, if that makes sense.
Here's why: You have to look up a typedef to know what it is, and typedefs everywhere make it harder to know what's going on until you can adopt the fundamental lexicon that your typedefs essentially create.
That said, everything you wrote is valid. I just think there are places where it might be overkill.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Most programmers of *nix/C upbringing insist that #define constants are named in UPPER_CASE so that you can easily see from the name that it is a constant. Strangely enough, the majority of that very same group detests Hungarian blurb, even though the argument for the blurb is very much the same. Why isn't the conclusion identical? Well, the answer is not invented here ...
I dislike both strongly. They seem fine for release 1.0. Then, as we experienced in one project, several of those static configuration parameters, #defines, were in release 2.0 made dynamically configurable, runtime modifiable. In those days we didn't have an IDE that could automatically rename a symbol throughout the project; it had to be done manually in every single file, and there were quite a few of them; it took some effort. So for quite some time, we had a number of all-uppercase variables. We experienced "Constants ain't. Variables won't." long before it became a standard rule.
That project made me ask myself: Why really did I have to know at all times whether that value is constant or variable? Did it really affect my use of it? Should it? Constant-ness is sort of a "nice to know", but when it turns into a "need to know", you should stop and ask yourself: Do I really need to know?
We had a very similar experience when porting code from 16 bits Windows 95 to 32 bits Windows XP, in the days when everyone spoke Hungarian. Lots of variable were expanded in size, and the renaming of them put on the todo list.
Again, I asked myself (and my coworkers): Is it really significant, as seen from a problem solution point of view, whether this counter is 16 or 32 bits? Isn't it quite obvious that this other value is a string, both from is (blurbless) name and its use? Especially when moving code between different architectures, any blurb reflecting implementation (such as word length) is meaningless. For any semantics based blurb, you really don't gain much until you include, say, the struct type name in extenso - it obviously is a struct; you don't need a blurb for that!
I have learned to program very much with disregard to the type definition; I don't have to look it up to see if it is a short, an int, a long or a longlong - it is large enough for its use. The float has sufficient precision for its use. If you are in doubt whether a value is a count (some sort of integer) or a measurement (some sort of float), then you should spend some time on understanding the solution at a conceptual level, not at the implementation type level!
And boy, do I miss working with languages providing a decent type system! Not even in C# is there a proper 'enum' definition - yes, there is something called enum, which is just a thin veil over integers. 50+ years old Pascal had proper enums. Proper subranges. Going on to 40+ years old CHILL, where you could define distinct, say, integer types, so that you didn't inadvertently add AppleCount to ClassSize. Some languages allowed types associating a unit (or more precisely: A set of units) with values of that type; I only read about those, but sure would like to have it available.
Stated briefly: The type system is a grossly neglected area in almost all languages born after the breakthrough of C.
|
|
|
|
|
Working with autogenerated code from both MATLAB ans AutoSAR really teaches how much typedef and define complicate the code. Sometimes you have seven or eight redefinitions - it's Hell on Earth.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
AutoSAR ? You doing automotive development ?
|
|
|
|
|
Yep, though I'm not touching AutoSAR since a couple of years - I moved to lower level peripherals that run on TLE987x and similar.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Now this is interesting, since I am working on that exact Infineon family as well !
|
|
|
|
|
It's the golden standard, it's HV driver protections are second to none and the RTE is flawless.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
constexpr static const int life_the_universe_and_everything = 42;
To err is human. Fortune favors the monsters.
|
|
|
|
|
Didn't expect less: west coast, shall be west const 
Mircea
|
|
|
|
|
Single Step Debugger wrote: Type* p;
As I recall it there was a column from I believe the 'C++ Users Journal' which pointed out that the following...
int i;
Is the same as
<type> <variable>
So thus a pointer should be laid out as specified in the same way. That is if one needs a rationalization for it.
|
|
|
|
|
Yeah, but in
int x, *y;
is the * part of the type declaration or the variable declaration? If it is part of the type declaration, then type of y is declared in two parts, with an interspersed (and rather irrelevant) variable declaration.
Is that very rational? It is valid C!
|
|
|
|
|
The discussion is subjective as was the opinion of the columnist to which I referred. But as an authoritative opinion (as a columnist) the argument did provide a specific rationalization.
trønderen wrote: int x, *y;
I don't code using that form. And I very, very seldom see it used or even a case where it might be used. So as a rationalization for doing it all the time it does not seem to be very valid.
|
|
|
|
|
I've always preferred "Type *p" over "Type* p". To my mind the "pointer-ness" is a property of the variable and not the type.
Of course, I've also hated this: typedef Type* TypePtr. If values are declared as TypePtr and you are using pointer-dereferencing with those values, the typedef obfuscates the original type.
And before anyone pops up with "but what about...", I think typedef BaseType* OpaqueType is perfectly fine, when you're not using values of OpaqueType as pointers.
Software Zen: delete this;
|
|
|
|
|
A problem with
typedef Type* TypePtr; is that if you declare
const TypePtr p; it is p (the pointer itself) that is const, not Type. This can be confusing, so I avoid it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
