All in - pointer declaration
-
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
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!
-
Type *p;
or
Type* p;
or even
Type * p;
Me personally, I do whatever is the current company naming conventions.
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
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 asTypePtrand you are using pointer-dereferencing with those values, thetypedefobfuscates the original type. And before anyone pops up with "but what about...", I thinktypedef BaseType* OpaqueTypeis perfectly fine, when you're not using values ofOpaqueTypeas pointers.Software Zen:
delete this; -
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 asTypePtrand you are using pointer-dereferencing with those values, thetypedefobfuscates the original type. And before anyone pops up with "but what about...", I thinktypedef BaseType* OpaqueTypeis perfectly fine, when you're not using values ofOpaqueTypeas 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 isconst, notType. This can be confusing, so I avoid it.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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
constexpr static const int life_the_universe_and_everything = 42;
:-\
To err is human. Fortune favors the monsters.
-
A problem with
typedef Type* TypePtr;
is that if you declare
const TypePtr p;
it is
p(the pointer itself) that isconst, notType. This can be confusing, so I avoid it.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Good point. To my thinking
const-ness, like pointer-ness, are properties of the variable and not the type. Part of my dislike for that sort of thing is people use some kind of naming convention (xxxPtr, xxxCPtr,...) that indicates the variant of the type. It pollutes the name space with additional identifiers you need to recognize. This replaces fundamental language syntax which is consistent by definition with arbitrary naming that may or may not be consistent. I've also noticed that thetypedefoverusers also tend to cast those types, often using language syntax, to othertypedef's they've forgotten.Software Zen:
delete this; -
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 ;P
Mircea
-
Type *p;
or
Type* p;
or even
Type * p;
Me personally, I do whatever is the current company naming conventions.
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
-
Type *p;
or
Type* p;
or even
Type * p;
Me personally, I do whatever is the current company naming conventions.
There is only one Vera Farmiga and Salma Hayek is her prophet! Advertise here – minimum three posts per day are guaranteed.
I never met any convention that specifies pointer declarations so I use
Type* p;
I learnt with
Type *p;but I always found it more complex to understand: after all that identifier holds a pointer to p, so it's type is pointer. Same forType** p. Only sometimes I mix them around if there are readability reasons, for exampleType** *p;can be in my opinion more readable if p holds a pointer to a matrix (i.e. if you need to return a matrix allocated by the callee, switch the matrix to send to the callee based on something, etc).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
-
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
typedeclaration.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 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.
Working with autogenerated code from both MATLAB ans AutoSAR really teaches how much
typedefanddefinecomplicate 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
-
Working with autogenerated code from both MATLAB ans AutoSAR really teaches how much
typedefanddefinecomplicate 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 ?
-
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
-
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 !
-
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
-
Good point. To my thinking
const-ness, like pointer-ness, are properties of the variable and not the type. Part of my dislike for that sort of thing is people use some kind of naming convention (xxxPtr, xxxCPtr,...) that indicates the variant of the type. It pollutes the name space with additional identifiers you need to recognize. This replaces fundamental language syntax which is consistent by definition with arbitrary naming that may or may not be consistent. I've also noticed that thetypedefoverusers also tend to cast those types, often using language syntax, to othertypedef's they've forgotten.Software Zen:
delete this;I often define a
typedeffor a template instantiation, to keep the type succinct:typedef std::unique_ptr ClassPtr;
typedef std::vector ClassPtrVector;And then there are things like
typedef int main_t; // returned by main()
typedef int signal_t; // a POSIX signal
typedef uint16_t ipport_t; // an IP port numberwhich do a much better job than simple
inttypes when documenting, or searching for, data and functions that deal with these things.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
(Lights his torch.)
-
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.
