By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,803 Members | 1,574 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,803 IT Pros & Developers. It's quick & easy.

regarding typedef

P: n/a
Hi,

You all know typedef

typedef struct g
{
int a;
int b;
} google;

typedef google (*google)

google fl1;

fl1->a=10;
fl1->b=20;

see struct google was just a structure and was not a pointer
by using typedef we can change its name.

so after typedef google (*google); , why google variables are acting
like pointers.

Please help me in this.

thanks

lee

Mar 25 '06 #1
Share this Question
Share on Google+
14 Replies


P: n/a
ya*******@ausi.com opined:
Hi,

You all know typedef

typedef struct g
{
int a;
int b;
} google;

typedef google (*google)

google fl1;

fl1->a=10;
fl1->b=20;

see struct google was just a structure and was not a pointer
by using typedef we can change its name.

so after typedef google (*google); , why google variables are acting
like pointers.


After that, `google` variables can't act like anything, as that line is
illegal. You can't re-use names like that. Try:

typedef struct g
{
int a;
int b;
} goog;

typedef goog* google;

google fl1;

Also, your use of parentheses is misleading. Have a look above, and
into your textbook. It declares a type that is a pointer to a `struct`
of type `goog`. All should be clear now.

--
BR, Vladimir

*** NEWSFLASH ***
Russian tanks steamrolling through New Jersey!!!!
Details at eleven!

Mar 25 '06 #2

P: n/a
On 2006-03-25, Vladimir S. Oka <no****@btopenworld.com> wrote:
ya*******@ausi.com opined:
typedef struct g { int a; int b; } google;
typedef google (*google)
google fl1;
fl1->a=10;
fl1->b=20;

see struct google was just a structure and was not a pointer by using
typedef we can change its name.

so after typedef google (*google); , why google variables are acting
like pointers.
After that, `google` variables can't act like anything, as that line
is illegal. You can't re-use names like that. Try:

typedef struct g
{
int a;
int b;
} * google;

I think is closer to what he intends.
Also, your use of parentheses is misleading.


Why? That's where the parentheses would go, if you were to put them
anywhere.
Mar 25 '06 #3

P: n/a
Jordan Abel opined:
On 2006-03-25, Vladimir S. Oka <no****@btopenworld.com> wrote:
ya*******@ausi.com opined:
typedef struct g { int a; int b; } google;
typedef google (*google)
google fl1;
fl1->a=10;
fl1->b=20;

see struct google was just a structure and was not a pointer by
using typedef we can change its name.

so after typedef google (*google); , why google variables are
acting like pointers.


After that, `google` variables can't act like anything, as that line
is illegal. You can't re-use names like that. Try:

typedef struct g
{
int a;
int b;
}

* google;

I think is closer to what he intends.
Also, your use of parentheses is misleading.


Why? That's where the parentheses would go, if you were to put them
anywhere.


Quite right, on both counts. I blame it on too many googles in the OP.

--
BR, Vladimir

The climate of Bombay is such that its inhabitants have to live
elsewhere.

Mar 25 '06 #4

P: n/a
ya*******@ausi.com wrote:
Hi,

You all know typedef

typedef struct g
{
int a;
int b;
} google;

typedef google (*google)

google fl1;

fl1->a=10;
fl1->b=20;

see struct google was just a structure and was not a pointer
by using typedef we can change its name.

so after typedef google (*google); , why google variables are acting
like pointers.

Please help me in this.


Apart from what the others say also read the following thread:
http://groups.google.com/group/comp....35ae36c1b46ac4

Mar 25 '06 #5

P: n/a
<ya*******@ausi.com> wrote:
You all know typedef

typedef struct g
{
int a;
int b;
} google;

typedef google (*google)

google fl1;

fl1->a=10;
fl1->b=20;

see struct google was just a structure and was not a pointer
by using typedef we can change its name.

so after typedef google (*google); , why google variables are acting
like pointers.

Please help me in this.


You haven't taken the most elementary steps to help yourself.

It is a good idea, particularly when you are in unfamiliar waters, to give
different names to different things. It helps the thinking process
enormously.
Mar 25 '06 #6

P: n/a
Hi,

Following thing is confusing to me..
Its not clear to me..
typedef int (*MyFunctionP)();

typedef struct
{
MyFunctionP myFuncP;
void *mdlDescP;
} neutral;
I am typedefing the int to a pointer to a function.
How can a int is involving with a function..
what is happening here.. please tell me.

thanks
lee.
osmium wrote:
<ya*******@ausi.com> wrote:
You all know typedef

typedef struct g
{
int a;
int b;
} google;

typedef google (*google)

google fl1;

fl1->a=10;
fl1->b=20;

see struct google was just a structure and was not a pointer
by using typedef we can change its name.

so after typedef google (*google); , why google variables are acting
like pointers.

Please help me in this.


You haven't taken the most elementary steps to help yourself.

It is a good idea, particularly when you are in unfamiliar waters, to give
different names to different things. It helps the thinking process
enormously.


Mar 27 '06 #7

P: n/a
ya*******@ausi.com writes:
Following thing is confusing to me..
Its not clear to me..
typedef int (*MyFunctionP)();

typedef struct
{
MyFunctionP myFuncP;
void *mdlDescP;
} neutral;
I am typedefing the int to a pointer to a function.
How can a int is involving with a function..
what is happening here.. please tell me.


Please don't top-post. See <http://www.caliburn.nl/topposting.html>.

The declaration doesn't typedef "int" to anything. It creates a
typedef called "MyFunctionP", which becomes an alias for the type
"int (*)()", or "pointer to function returning int".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Mar 27 '06 #8

P: n/a
On 2006-03-27, ya*******@ausi.com <ya*******@ausi.com> wrote:
Hi,

Following thing is confusing to me..
Its not clear to me..

typedef int (*MyFunctionP)();

typedef struct
{
MyFunctionP myFuncP;
void *mdlDescP;
} neutral;
I am typedefing the int to a pointer to a function.
It looks like that, but actually you're typedeffing MyFunctionP to be a
pointer to a function returning int.
How can a int is involving with a function..
what is happening here.. please tell me.


It's just rather difficult syntax. I've never met anyone who didn't find
function types in C a bit hard to read.

Think about this:

Some people write:

int* p;

which you can read as "p is a pointer to int", as if int* were a type.

Another style is:

int *p;

which you can read as "p is a pointer, and *p is an int".

Well you can read this:

int (*fn)(int) = f;

as "fn is a pointer, and *fn is a function that takes an int and return
an int"

typedefs work just like declarations. Practical advice for function
pointers is always typedef them and if you can't remember the syntax
copy one from somewhere (you'll usually find one in man qsort).

I'd appreciate a better explanation of function type syntax myself. I
think I've just got used to them rather than ever understood them.
Mar 27 '06 #9

P: n/a
In article <sl*********************@bowser.marioworld>
Ben C <sp******@spam.eggs> wrote:
... you can read this:

int (*fn)(int) = f;

as "fn is a pointer, and *fn is a function that takes an int and return
an int". ...
I'd appreciate a better explanation of function type syntax myself. I
think I've just got used to them rather than ever understood them.


The above is exactly the right description.

Dennis has said that the rule for C is "declaration mirrors use".
If one uses (*p)[3] to access one "double" object, then:

double (*p)[N];

is probably the actual declaration (and N is at least 4), giving
p the type "pointer to array N of double". Thus *p has type
"array N of double", and (*p)[3] has type "double".

Of course, (*p) and (p[0]) do the same thing in actual code, so
it is possible to write p[0][3] instead of (*p)[3]. But that
would imply a declaration like:

double p[M][N];

for some integral constants M > 0 and N > 3. Hence, "declaration
mirrors use" only if you happen to use the same format as the
declaration. This also causes confusion with function pointers:

#include <math.h>
...
double result, argument;
double (*fp)(double);

if (use_sine)
fp = sin;
else /* use cosine */
fp = cos;
...
result = (*fp)(argument);

As with arrays and pointers, function names "decay" to pointers to
those functions in most contexts. Here (*fp) "follows the pointer"
in "fp" to the appropriate function (sin or cos), then "un-follows"
it (via "decay") to get the pointer, and only then does the call,
using the pointer. So we can drop the asterisk, and write:

result = fp(argument);

This is the same technique (though a different end-point, as it
were) that we use when we write:

double some_table[SOME_SIZE];
double *dp;
...
dp = some_table;

instead of "dp = &some_table[0]".

Probably the most confusing of all C's type syntaxes is that for
casts (and, correspondingly, unnamed prototype arguments). To form
a proper cast, start by writing a declaration for a variable of
the given type. Let us tackle a tough one: a pointer to a function
that handles a signal. ANSI/ISO C says that a signal function
receives one "int" (the signal number) and returns "void". So the
function itself might look like:

void handle_signal(int sig) {
... some code here ...
}

A pointer to such a function has type:

pointer to function (int) returning void

which is declared as:

void (*fp)(int);

To turn this into a cast, start with the declaration and remove
the name:

void (*)(int)

Then just add parentheses around the whole thing, giving:

(void (*)(int))

Of course, you have to cast some actual value, such as 0. Add
parentheses to that "just in case", and you get a typical definition
for SIG_DFL:

#define SIG_DFL ((void (*)(int))0)

In a function prototype, the arguments can have names, or omit them:

double cos(double argument);
double sin(double);

In an implementation header -- one provided by an implementor -- the
implementor has to be careful not to use a user's name. Imagine
the troubles that occur if the user writes, for instance:

#define i "me, myself"
#include <stdlib.h>

and <stdlib.h> says something like:

int abs(int i);

which then expands to:

int abs(int "me, myself");

Hence, if you look at actual implementor's headers, they tend to use
either:

int abs(int); /* no identifier = no chance for the user to #define it */

or:

int abs(int __i); /* __ prefix is reserved, keep your hands off! */

So consider signal(), again. Its first argument is an "int",
the signal number; its second argument is a pointer to a signal
function.

We already came up with the spelling for the type "pointer to
function taking one int and returning void":

void (*)(int)

So signal's two arguments, using no names, are:

____ int, void (*)(int) ____

(where ____ represents the blanks to fill in later).

However, signal's return value has the same type as its second
argument: "pointer to function taking one int and returning void".
To spell *that*, without using a typedef, we have to declare
signal as:

void (*signal( ____ ))(int);

where ____ represents "the arguments to the actual function" (again,
"blanks to fill in later"). The parentheses around (*signal( ____ ))
are required to force the "*" to bind to the "signal(int)" part,
and not to the "void" part.

Finally, we can drop in the arguments, which we already worked out:

void (*signal(int, void (*)(int)))(int);

and we have a correct prototype for signal(), using no names. If
we are playing implementor -- writing <signal.h> -- and choose to
put in names, we have to use our (implementor) reserved names with
double underscores or similar, and write:

void (*signal(int __sig, void (*__func)(int)))(int);

As an ordinary (non-implementor) C programmer, of course, we would
have to *avoid* the double-underscore names.

This is a lot easier with a typedef, in part because signal's second
parameter -- "pointer to function taking int and returning void"
-- has the *same* type as its return value. So one typedef,
for "pointer to function taking int and returning void", removes
all the hair:

typedef void (*signal_function_pointer)(int);

signal_function_pointer signal(int sig, signal_function_pointer func);

Of course, if we put on our Implementor Hats and write a *new*
<signal.h>, we find that we cannot define the name
"signal_function_pointer". (It is reserved to the user. User gets
the non-"__" names, implementor gets the "__" names, and the two
never collide.) So we either write the hairy version, or typedef
a double-underscore name.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Mar 27 '06 #10

P: n/a
On 2006-03-27, Chris Torek <no****@torek.net> wrote:
In article <sl*********************@bowser.marioworld>
Ben C <sp******@spam.eggs> wrote:
... you can read this:

int (*fn)(int) = f;

as "fn is a pointer, and *fn is a function that takes an int and return
an int". ...
I'd appreciate a better explanation of function type syntax myself. I
think I've just got used to them rather than ever understood them.


The above is exactly the right description.

Dennis has said that the rule for C is "declaration mirrors use".
[...]


Brilliant explanation, thank you very much.
Mar 27 '06 #11

P: n/a
Best explanation :)

Mar 29 '06 #12

P: n/a
Best explanation :)

Mar 29 '06 #13

P: n/a
fr*******@yahoo.com opined:
Best explanation :)


What is? Read:

<http://cfaj.freeshell.org/google/>
<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>

--
BR, Vladimir

If Patrick Henry thought that taxation without representation was bad,
he should see how bad it is with representation.

Mar 29 '06 #14

P: n/a
fr*******@yahoo.com wrote:

Best explanation :)


Please read the following before posting any more useless context
free messages.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Mar 29 '06 #15

This discussion thread is closed

Replies have been disabled for this discussion.