typedef and pointers.

[srikar2097]

I came across this this piece of code while trying to understand
someone elses code.

#include <stdio.h>

int main()
{
typedef long LG, *LGP;
extern LGP lptr;
return 0;
}

Here LG is a typedef for "long" and LGP is a pointer to a "long". My
doubt here is what is the purpose of having a pointer to a "long" i.e.
a data type. it is not a variable right? I know technically this is
correct. But my doubt is more functional (use of this) than syntactic.

Thanks...

 

[viza]

I came across this this piece of code while trying to understand someone
elses code.

#include <stdio.h>

int main()
{
typedef long LG, *LGP;
extern LGP lptr;
return 0;
}

Here LG is a typedef for "long" and LGP is a pointer to a "long". My
doubt here is what is the purpose of having a pointer to a "long" i.e. a
data type. it is not a variable right?

LG and LGP are types, lptr is a variable. It has type "pointer to
long". It can be used to point to a variable of type long":

LG foo= 42;
lptr= & foo;

HTH
viza

 

[srikar2097]

I get it now, so lptr becomes a pointer of type long. Is that it?
But why would anyone want to do it this way? Does it have any
advantage?

To change it a bit -

long foo = 42;
long *lptr = &foo;

doesn't this suffice?

 

[Ben Bacarisse]

[Don't top post.]

I get it now, so lptr becomes a pointer of type long. Is that it?
But why would anyone want to do it this way? Does it have any
advantage?

If you mean "why use typedefs for such simple types?" then the answer
is probably just bad programming style. Sometimes you see code that
can be changed to work with some configurable integer type (int or
long int or long long int for example) but then I'd expect a better
name:

typedef long long int integer_type; /* Change this is you need to */

An argument can be made that hiding the fact that a type is a pointer
by using a typedef is always wrong. Some people would permit it if
the type were being used as an opaque type:

typedef struct network_interface *net_interface;

To change it a bit -

long foo = 42;
long *lptr = &foo;

doesn't this suffice?

Yes, that is quite enough.

 

[James Kuyper]

I get it now, so lptr becomes a pointer of type long. Is that it?
But why would anyone want to do it this way? Does it have any
advantage?

To change it a bit -

long foo = 42;
long *lptr = &foo;

doesn't this suffice?

Sure, but the people who use this approach consider it convenient to be
able to write LGP rather than long*. However, if you consider the need
to use the shift key, most of the convenience argument disappears. A
more important problem is that this typedef hides the pointer nature of
the variable, which is considered by many people to be dangerous. I
wouldn't use this typedef.

 

[Fred]

Sure, but the people who use this approach consider it convenient to be
able to write LGP rather than long*. However, if you consider the need
to use the shift key, most of the convenience argument disappears. A
more important problem is that this typedef hides the pointer nature of
the variable, which is considered by many people to be dangerous. I
wouldn't use this typedef.

maybe the program needs different types under different circumstances
or on different platforms. Using a typedef then makes it simple to
change between types, changing only one line instead of everywhere
that type is used.

#ifdef CIRCUMSTANCE_ONE
typedef long LG, *LGP;
#else
typedef long long LG, *LGP;
#endif

 

[Richard Bos]

[ Please do not top-post. Corrected. ]

I get it now, so lptr becomes a pointer of type long. Is that it?
But why would anyone want to do it this way? Does it have any
advantage?

No. Basically, the person who wrote that code had probably been reading
a bit too much Microsoft system code. Their headers abound with such
silliness. It's the habit of someone who has heard of abstract data
types and the separation of interface and implementation, but has not
the faintest idea what he is actually doing, let alone what he's
supposed to be doing.

Richard

 

[John Bode]

I get it now, so lptr becomes a pointer of type long. Is that it?
But why would anyone want to do it this way? Does it have any
advantage?

To change it a bit -

long foo = 42;
long *lptr = &foo;

doesn't this suffice?

IME, people who use such a typedef are the kind of people who get bit
by the

long* p1, p2;

mistake a lot (thinking that p2 is also being declared a pointer, even
though it isn't).

Personally, I've found that hiding the pointerness of a type behind a
typedef causes more problems than it solves.

 

[jameskuyper]

Fred wrote:
....

maybe the program needs different types under different circumstances
or on different platforms. Using a typedef then makes it simple to
change between types, changing only one line instead of everywhere
that type is used.

#ifdef CIRCUMSTANCE_ONE
typedef long LG, *LGP;
#else
typedef long long LG, *LGP;
#endif

With a different name, that might be plausible, and perfectly
legitimate use of a typedef. However, the name looks like an
abbreviation for LonG Pointer, which doesn't sound like something that
would be used in that way.

 

[srikar2097]

Thanks you guys!! I am learning a lot here.

Srikar

 

[David Thompson]

John Bode wrote:
Generally.

Another problem is that you then need a typedef for a const T* as
well, for functions that don't modify the pointed-to object.

typedef int foo, *foo_ptr, const* const_foo_ptr;

Even worse; you need a whole second declaration:
typedef int foo, *ptr_foo; typedef const foo *ptrc_foo;
/* using an alternate naming style for variety */
although it could be macro-generated using ## pasting.

Since the latter typedef is usually left off, it discourages
const-correctness, because it causes callers to be inconsistent:

void modify( foo_ptr );
void examine( const foo* );

Concur. (Except modify probably ought to have some additional
arguments, and examine usually ought to return something.)

Of course, among people who don't like bothering with const
correctness anyway this isn't considered a problem. <G?>