All in - pointer declaration

0x01AA

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... :(

Greg Utas

This doesn't bother me, because I never do this kind of thing.

Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.

Ravi Bhavnani

Me too. Although since I no longer develop in C++, I use:

MyType p;

:) /ravi

My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

jschell

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.

trønderen

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

trønderen

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!

Gary R Wheeler

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;

Greg Utas

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.

Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.

honey the codewitch

constexpr static const int life_the_universe_and_everything = 42;

:-\

To err is human. Fortune favors the monsters.

Gary R Wheeler

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 the typedef overusers also tend to cast those types, often using language syntax, to other typedef's they've forgotten.

Software Zen: delete this;

Mircea Neacsu

Didn't expect less: west coast, shall be west const ;P

Mircea

jmaida

Thanx for this introduction to computer language pointer constructs specifically related to C. True C++, C# are involved. The string of discussion was quite interesting.

"A little time, a little trouble, your better day" Badfinger

den2k88

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 for Type** p. Only sometimes I mix them around if there are readability reasons, for example Type** *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).