> -----Original Message-----
> From: Mark Nudelman [mailto:[EMAIL PROTECTED]]
>
>
> Aaron Ardiri wrote:
> > typedef struct
> > {
> > int a;
> > } MyStruct, *MyStructPtr;
>
> At the risk of starting a religious war, I have to ask: why do people
> (including the writers of the Palm header files) create typedefs for
> pointers? I find it simpler, cleaner and easier to read if I just say
> MyStruct *p;
> rather than
> MyStructPtr p;
> In the latter case, it's not as clear that the thing you're
> defining is
> a pointer; the type name is longer and not as transparently related to
> the base type MyStruct; and there are twice as many typedefs floating
> around. I can understand doing something like this if you're defining
> an opaque type that isn't meant to be dereferenced (or, heaven forbid,
> you're working on some horrible segmented architecture where
> you've got
> to distinguish between near/far pointers), but I've seen
> people do this
> for ordinary pointers that are meant to be dereferenced. Why?
To be honest I've never understood it either.
There are times when you are using complex
pointer-to-pointer-to-pointer schemes where typedefing
makes things a bit clearer as to which level you are
dealing with.
imo the worst thing about it is that it completely changes
the "const" semantics in a way that most people don't
twig to:
const char *p; // pointer to (char data that can not be changed)
const CharPtr p; // (pointer that can not be changed) to char
data
--
-Richard M. Hartman
[EMAIL PROTECTED]
186,000 mi./sec ... not just a good idea, it's the LAW!
