how to define a function pointer variable witout typdef?

"sathyashrayan" <sa***********@REMOVETHISgmail.com> writes:

<Je***********@physik.fu-berlin.de> wrote in message
news:3f************@uni-berlin.de...
sathyashrayan <sa***********@removethisgmail.com> wrote:
> "baumann@pan" <ba*********@gmail.com> wrote in message
> news:11**********************@o13g2000cwo.googlegr oups.com...
>> typedef int (*pfunc)(int , int);
>> pfunc a_func;
>>
>> i know it's ok,
>>
>> but how can define a_func without typedef statement?

> int (*a_func)(int, int);
> But this is a declaration not a definition.

No, this creates a variable, named 'a_func', that can hold a pointer
to a function taking two int arguments and returning an int.

Is it the declaration 'a_func' satisfies the criteria of definition
when 'a_func' pointes with the properly defined function (as you
said)? Or I am missing some simple thing?

It's an object definition (it defines the pointer-to-function object
"a_func"). It's just not a function definition.

Roughly speaking, a definition is a declaration that creates the
entity being declared, whereas a declaration that isn't a definition
merely declares that the entity exists, but doesn't actually create
it. (All definitions are declarations.) For example:

int x; /* a definition; it creates x */
extern int y; /* not a definition; y is defined elsewhere */
void foo(void) { printf("Hello\n"); }
/* a definition of the function "foo" */
void bar(void); /* not a definition; bar is defined elsewhere */

Typedefs are a bit odd in that a typedef doesn't actually create a new
type, merely an alias for an existing type. But a typedef is a
definition because the thing it creates is the alias, not the type.

And now we wait for the experts to point out my errors.

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

Nov 14 '05 #10

baumann@pan wrote on 27/05/05 :

typedef int (*pfunc)(int , int);
pfunc a_func;

i know it's ok,
Yes, and encouraged to have readable sources...
but how can define a_func without typedef statement?

You can :

int (*pfunc)(int , int);

by why would you do that except to obscure the code ?

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Nov 14 '05 #11

sathyashrayan wrote on 27/05/05 :

int (*a_func)(int, int);
But this is a declaration not a definition.

It actually is a defintion of a non initialized pointer.

extern int (*a_func)(int, int);

would be a declaration

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

I once asked an expert COBOL programmer, how to
declare local variables in COBOL, the reply was:
"what is a local variable?"

Nov 14 '05 #12

sathyashrayan wrote on 28/05/05 :

int (*a_func)(int, int);

Is it the declaration 'a_func' satisfies the criteria of definition
when 'a_func' pointes with the properly defined function (as you said)? Or I
am missing some simple thing?

You are making a mixture here.

/* declaration of x */
extern int x;

/* definition of x with an undefined value */
int x;

/* definition of x with a defined value */
int x = 123;

An unitialized variable has a undefined value, but it occupies a region
of memory. The fact that the value is undefined doesn't turn the
variable to be undefined.

Sounds to be a common mistake...
No 'extern' to see seen in front of it, so it's a definition, not a
declaration.

I dont understand.

That's the point! extern is used to declare a public variable. Read
your C-book again.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

..sig under repair

Nov 14 '05 #13

pete

Emmanuel Delahaye wrote:

sathyashrayan wrote on 27/05/05 :
int (*a_func)(int, int);
But this is a declaration not a definition.

It actually is a defintion of a non initialized pointer.

extern int (*a_func)(int, int);

would be a declaration

But the defintion of a non initialized pointer,
is also a declaration.

N869
6.7 Declarations
Semantics
[#5]
A definition of an
identifier is a declaration for that identifier that:
-- for an object, causes storage to be reserved for that
object;
-- for a function, includes the function body;

--
pete

Nov 14 '05 #14

pete wrote on 28/05/05 :

Emmanuel Delahaye wrote:

sathyashrayan wrote on 27/05/05 :
int (*a_func)(int, int);
But this is a declaration not a definition.

It actually is a defintion of a non initialized pointer.

extern int (*a_func)(int, int);

would be a declaration

But the defintion of a non initialized pointer,
is also a declaration.

N869
6.7 Declarations
Semantics
[#5]
A definition of an
identifier is a declaration for that identifier that:
-- for an object, causes storage to be reserved for that
object;
-- for a function, includes the function body;

Yes the 'declaration' thing is embedded into the definition.

But a stand-alone declaration certainely is not a defintion.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"Mal nommer les choses c'est ajouter du malheur au
monde." -- Albert Camus.

Nov 14 '05 #15

Keith Thompson wrote:

[ much snippage ]

It's an object definition (it defines the pointer-to-function object
"a_func"). It's just not a function definition.

Roughly speaking, a definition is a declaration that creates the
entity being declared, whereas a declaration that isn't a definition
merely declares that the entity exists, but doesn't actually create
it. (All definitions are declarations.) For example:

int x; /* a definition; it creates x */
extern int y; /* not a definition; y is defined elsewhere */
void foo(void) { printf("Hello\n"); }
/* a definition of the function "foo" */
void bar(void); /* not a definition; bar is defined elsewhere */

Typedefs are a bit odd in that a typedef doesn't actually create a new
type, merely an alias for an existing type. But a typedef is a
definition because the thing it creates is the alias, not the type.

And now we wait for the experts to point out my errors.

I suppose a typedef is not a definition. This because it does not create
an object in memory. It's another case of C overloading the English
language. Odd, isn't it that '#define X 2' is not a definition either.

--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Nov 14 '05 #16

Joe Wright <jo********@comcast.net> writes:

Keith Thompson wrote:

[snip]

Typedefs are a bit odd in that a typedef doesn't actually create a
new type, merely an alias for an existing type. But a typedef is a
definition because the thing it creates is the alias, not the type.
And now we wait for the experts to point out my errors.

I suppose a typedef is not a definition. This because it does not
create an object in memory. It's another case of C overloading the
English language. Odd, isn't it that '#define X 2' is not a definition
either.

No, it doesn't create an object in memory. Neither does a function
definition. A definition, as I understand it, is a declaration that
creates the named entity, rather than merely referring to an entity
that's created elsewhere. The entity doesn't have to be an object.

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

Nov 14 '05 #17

pete

Keith Thompson wrote:

Joe Wright <jo********@comcast.net> writes:
Keith Thompson wrote:

[snip]
Typedefs are a bit odd in that a typedef doesn't actually create a
new type, merely an alias for an existing type. But a typedef is a
definition because the thing it creates is the alias, not the type.
And now we wait for the experts to point out my errors.

I suppose a typedef is not a definition. This because it does not
create an object in memory. It's another case of C overloading the
English language.
Odd, isn't it that '#define X 2' is not a definition
either.

No, it doesn't create an object in memory. Neither does a function
definition. A definition, as I understand it, is a declaration that
creates the named entity, rather than merely referring to an entity
that's created elsewhere. The entity doesn't have to be an object.

I only know that typedefs and enums are definitions
because it's been pointed out to me that the standard says so.

External typedefs and enums,
which are both declarations and definitions,
are not definitional enough to be considered as
"external definitions".

--
pete

Nov 14 '05 #18

Keith Thompson wrote:

Joe Wright <jo********@comcast.net> writes:
Keith Thompson wrote:

[snip]
Typedefs are a bit odd in that a typedef doesn't actually create a
new type, merely an alias for an existing type. But a typedef is a
definition because the thing it creates is the alias, not the type.
And now we wait for the experts to point out my errors.

I suppose a typedef is not a definition. This because it does not
create an object in memory. It's another case of C overloading the
English language. Odd, isn't it that '#define X 2' is not a definition
either.

No, it doesn't create an object in memory. Neither does a function
definition. A definition, as I understand it, is a declaration that
creates the named entity, rather than merely referring to an entity
that's created elsewhere. The entity doesn't have to be an object.

Nice side step. In what way is a typedef a declaration creating a named
entity?

--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Nov 14 '05 #19

pete wrote:

Keith Thompson wrote:
Joe Wright <jo********@comcast.net> writes:
Keith Thompson wrote:

[snip]
Typedefs are a bit odd in that a typedef doesn't actually create a
new type, merely an alias for an existing type. But a typedef is a
definition because the thing it creates is the alias, not the type.
And now we wait for the experts to point out my errors.
I suppose a typedef is not a definition. This because it does not
create an object in memory. It's another case of C overloading the
English language.
Odd, isn't it that '#define X 2' is not a definition
either.

No, it doesn't create an object in memory. Neither does a function
definition. A definition, as I understand it, is a declaration that
creates the named entity, rather than merely referring to an entity
that's created elsewhere. The entity doesn't have to be an object.

I only know that typedefs and enums are definitions
because it's been pointed out to me that the standard says so.

External typedefs and enums,
which are both declarations and definitions,
are not definitional enough to be considered as
"external definitions".

Show me. I have N869 and it makes no reference to typedef reserving
memory for anything. Of course, its very name suggests 'type definition'
in the natural language sense of defining 'last name' as 'surname'.

--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Nov 14 '05 #20

Joe Wright <jo********@comcast.net> writes:

Keith Thompson wrote:
Joe Wright <jo********@comcast.net> writes:
Keith Thompson wrote:

[snip]
Typedefs are a bit odd in that a typedef doesn't actually create a
new type, merely an alias for an existing type. But a typedef is a
definition because the thing it creates is the alias, not the type.
And now we wait for the experts to point out my errors.
I suppose a typedef is not a definition. This because it does not
create an object in memory. It's another case of C overloading the
English language. Odd, isn't it that '#define X 2' is not a definition
either.

No, it doesn't create an object in memory. Neither does a function
definition. A definition, as I understand it, is a declaration that
creates the named entity, rather than merely referring to an entity
that's created elsewhere. The entity doesn't have to be an object.

Nice side step. In what way is a typedef a declaration creating a
named entity?

The entity it creates is a named alias for an existing type. An
"entity", as I'm using the term, doesn't have to be something that
occupies memory space; it's just something that can be named.

Given:

typedef int foo_t;

"foo_t" is the name of an entity (the alias) that wouldn't exist
without the typedef. Without the typedef, there isn't anything called
"foo_t". (The type int does already exist, but that's not what's
being declared.) By contrast,

extern int foo;

is not a definition because the entity "foo" (which in this case is an
int object) exists with or without the declaration. (If an extern
declaration created a new name, I'd probably argue that it's a
definition that creates an alias for an existing object, but all it
does is refer to an existing object with an existing name.)

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

Nov 14 '05 #21

S.Tobias

Joe Wright <jo********@comcast.net> wrote:

pete wrote:
Keith Thompson wrote:
Joe Wright <jo********@comcast.net> writes:
Keith Thompson wrote:Typedefs are a bit odd in that a typedef doesn't actually create a
>new type, merely an alias for an existing type. But a typedef is a
>definition because the thing it creates is the alias, not the type.
>And now we wait for the experts to point out my errors. I suppose a typedef is not a definition. This because it does not
create an object in memory. It's another case of C overloading the
English language.
Odd, isn't it that '#define X 2' is not a definition
either. No, it doesn't create an object in memory. Neither does a function
definition. A definition, as I understand it, is a declaration that
creates the named entity, rather than merely referring to an entity
that's created elsewhere. The entity doesn't have to be an object.
I only know that typedefs and enums are definitions
because it's been pointed out to me that the standard says so.

External typedefs and enums,
which are both declarations and definitions,
are not definitional enough to be considered as
"external definitions".
Show me. I have N869 and it makes no reference to typedef reserving
memory for anything. Of course, its very name suggests 'type definition'
in the natural language sense of defining 'last name' as 'surname'.

(6.7 Declarations)
# 5 A declaration specifies the interpretation and attributes of a set of
# identifiers. A /definition/ of an identifier is a declaration for that
# identifier that:
# - for an object, causes storage to be reserved for that object;
# - for a function, includes the function body;98)
# - for an enumeration constant or typedef name, is the (only) declaration
# of the identifier.

I have recently asked in c.s.c (Subject: the term "definition")
the question why the C Std defines the term /definition/ this way,
but I haven't obtained any satisfactory explanation.

[note: C++ is completely different in this respect; notably
a typedef is a declaration, not a definition.]

Interesting thing to note though, is that there seems to be no
clear purpose for the term /definition/ in C language.
I tried to find some usage of the word that would make a difference
whether something is a definition or a (pure) declaration, especially
having typedef in mind, but I found none.
(I'm pretty sure there's none in the Language part, and less sure
about the Library part, where the verb "define" is used (in context
of reserved identifiers), but I think it is used colloquially and
often includes macro definitions; I must yet review that part again.)

[In C++ we have, at least, "One definition rule".]

Perhaps it's better to forget about the nuances created by the Standard
and use the words in ways that everybody understands.

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

Nov 14 '05 #22

S.Tobias

Keith Thompson <ks***@mib.org> wrote:

Joe Wright <jo********@comcast.net> writes:
Nice side step. In what way is a typedef a declaration creating a
named entity?

The entity it creates is a named alias for an existing type. An
"entity", as I'm using the term, doesn't have to be something that
occupies memory space; it's just something that can be named.
A typedef declaration just creates another identifier, with
all its consequences.
I'd say a typedef name is even less than an alias, more like
a macro definition:
typedef struct s s_t;
/* s_t is an incomplete type here */
struct s { /*...*/ }; /* creates new type, redeclares `s', implicitly
redeclares (redefines) s_t */
/* s_t is a (different) complete type now */
The meaning of a typedef name depends on the context (therefore we
cannot say that it aliases some _particular_ type).
Given: typedef int foo_t; "foo_t" is the name of an entity (the alias) that wouldn't exist
without the typedef. Without the typedef, there isn't anything called
"foo_t". (The type int does already exist, but that's not what's
being declared.) By contrast,

[snip]

But then why other declarations are not definitions?
`foo_t' is just another name for `int' type.
struct s;
creates new type and gives it a name `s' (in tag namespace).
Why doesn't this declaration _define_ the identifier `s'?

(Interestingly, `struct s;' does not "define a new type", but "declares
a new type", 6.7.2.3 p.5 and p.7; this is another mystery what
the difference is.)

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

Nov 14 '05 #23

"S.Tobias" <si***@FamOuS.BedBuG.pAlS.INVALID> writes:

Joe Wright <jo********@comcast.net> wrote:

[...]

Show me. I have N869 and it makes no reference to typedef reserving
memory for anything. Of course, its very name suggests 'type definition'
in the natural language sense of defining 'last name' as 'surname'.

(6.7 Declarations)
# 5 A declaration specifies the interpretation and attributes of a set of
# identifiers. A /definition/ of an identifier is a declaration for that
# identifier that:
# - for an object, causes storage to be reserved for that object;
# - for a function, includes the function body;98)
# - for an enumeration constant or typedef name, is the (only) declaration
# of the identifier.

I have recently asked in c.s.c (Subject: the term "definition")
the question why the C Std defines the term /definition/ this way,
but I haven't obtained any satisfactory explanation.

It seems fairly straightforward to me. A definition creates some
entity and associates a new name with it. For an object definition,
the entity is the object, and creation includes reserving storage for
it. For a function definition, the entity is a function. For a
typedef name, the entity is an alias (or whatever you want to call it)
for a type. For an enumeration constant, it's the enumerator.

In all these cases, the definition *introduces* the identifier and
associates it with the defined entity. Given any of

int foo;
void foo(void) { }
enum { foo };
typedef int foo;

there was nothing called "foo" before the definition. Given:

extern int bar;
void bar(void);

there has to be some pre-existing entity called "bar", whose
definition is elsewhere.

A definition defines (creates) something. A declaration that isn't a
definition merely declares something (i.e., asserts that it already
exists).

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

Nov 14 '05 #24

"S.Tobias" <si***@FamOuS.BedBuG.pAlS.INVALID> writes:

Keith Thompson <ks***@mib.org> wrote:
Joe Wright <jo********@comcast.net> writes:
> Nice side step. In what way is a typedef a declaration creating a
> named entity?

The entity it creates is a named alias for an existing type. An
"entity", as I'm using the term, doesn't have to be something that
occupies memory space; it's just something that can be named.

A typedef declaration just creates another identifier, with
all its consequences.

Yes, and anything that creates an identifier is a definition.
I'd say a typedef name is even less than an alias, more like
a macro definition:
typedef struct s s_t;
/* s_t is an incomplete type here */
struct s { /*...*/ }; /* creates new type, redeclares `s', implicitly
redeclares (redefines) s_t */
/* s_t is a (different) complete type now */
The meaning of a typedef name depends on the context (therefore we
cannot say that it aliases some _particular_ type).
It can only alias the type that is the completion of "struct s".

If you're familiar with Unix filesystem semantics, a typedef is
vaguely analogous to a symbolic link. Creating a symbolic link (with
"ln -s") corresponds to a typedef definition -- even if the target of
the symbolic link doesn't exist yet. Creating or changing the target
of the symlink doesn't re-create the symlink itself, it merely creates
or changes the distinct entity to which it refers. (That's probably
not a great analogy.)

The entity created by "typedef struct s s_t;" is a compile-time
*reference* to a type; the definition associates the identifier "s_t"
with that reference. Whether the referenced type is complete or
incomplete may change depending on other declarations, but the
reference exists as soon as the typedef definition itself is
processed.

[...]
But then why other declarations are not definitions?
`foo_t' is just another name for `int' type.
struct s;
creates new type and gives it a name `s' (in tag namespace).
Why doesn't this declaration _define_ the identifier `s'?

(Interestingly, `struct s;' does not "define a new type", but "declares
a new type", 6.7.2.3 p.5 and p.7; this is another mystery what
the difference is.)

I would say that "struct s;" doesn't define a type, but does define a
tag. I'm not sure whether the standard agrees with me.

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

Nov 14 '05 #25

baumann

another question,
how to write a function one of it's parameters is of of function
pointer without typdef?

ie.
func(int a, pfunc a_func_pointer)
{
}
is ok,

but without typedef , there is no pfunc, how can i write the function?

thanks

baumann@pan

Nov 14 '05 #26

ranjeet.gupta

Je***********@physik.fu-berlin.de wrote:

sathyashrayan <sa***********@removethisgmail.com> wrote:
"baumann@pan" <ba*********@gmail.com> wrote in message news:11**********************@o13g2000cwo.googlegr oups.com...
typedef int (*pfunc)(int , int);
pfunc a_func;

i know it's ok,

but how can define a_func without typedef statement?
int (*a_func)(int, int);
But this is a declaration not a definition.

No, this creates a variable, named 'a_func', that can hold a pointer
to a function taking two int arguments and returning an int. No
'extern' to see seen in front of it, so it's a definition, not a
declaration.

Dear Jens !!

what i know is
int *ptr;
this is declaration; ......

same is what is done with the above
int (*a_func)(int, int);
a_fucn is a pointer variable which holds the address of the
function which takes the two argument i.e both the int and
it returns the int.

so it means it is declaration, Now as you suggested if you have
the "extern" if this varaiable is defined outside the file scope,
then i have to define it overe there where I had declared it ??
making it defination ???

Please clarify.
Ranjeet
Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

Nov 14 '05 #27

Richard Bos

ra***********@gmail.com wrote:

Je***********@physik.fu-berlin.de wrote:
sathyashrayan <sa***********@removethisgmail.com> wrote:
int (*a_func)(int, int);
But this is a declaration not a definition.
No, this creates a variable, named 'a_func', that can hold a pointer
to a function taking two int arguments and returning an int. No
'extern' to see seen in front of it, so it's a definition, not a
declaration.

what i know is
int *ptr;
this is declaration; ......

Yes, _and_ a definition. It defines, and therefore also declares, a
pointer to int called ptr.
same is what is done with the above
int (*a_func)(int, int);
a_fucn is a pointer variable which holds the address of the
function which takes the two argument i.e both the int and
it returns the int.

so it means it is declaration,
_And_ definition.
Now as you suggested if you have
the "extern" if this varaiable is defined outside the file scope,
then i have to define it overe there where I had declared it ??

No. You have do define it somewhere in the program, once. You can then
declare it many times over, anywhere you want to use the pointer.

You want _one_ file in your program where you have an

int *ptr;

This defines the pointer, reserves memory for a single int *, _and_
declares it, so that it can be used in that file from that point.
In every other file where you want to use this pointer, you can then
_declare_ its existence and type using

extern int *ptr;

This will not reserve any memory; it just informs the compiler that
there is a definition for this object, somewhere in the program.

The same thing is true for other objects, and for functions. Define
once, declare as many times as you need it.

Richard

Nov 14 '05 #28

xcm

how to write a function one of it's parameters is of of function
pointer without typdef?

ie.
func(int a, pfunc a_func_pointer)
{
}
is ok,

but without typedef , there is no pfunc, how can i write the function?

#include<stdio.h>
int func(int a, int(*a_func_pointer)(const char*,...) )
{

if (a_func_pointer==printf) a_func_pointer("%s, a\n","hello",a);
}

Nov 14 '05 #29

Keith Thompson wrote:

"S.Tobias" <si***@FamOuS.BedBuG.pAlS.INVALID> writes:
Keith Thompson <ks***@mib.org> wrote:
Joe Wright <jo********@comcast.net> writes:

Nice side step. In what way is a typedef a declaration creating a
named entity?

The entity it creates is a named alias for an existing type. An
"entity", as I'm using the term, doesn't have to be something that
occupies memory space; it's just something that can be named.

A typedef declaration just creates another identifier, with
all its consequences.

Yes, and anything that creates an identifier is a definition.

I'd say a typedef name is even less than an alias, more like
a macro definition:
typedef struct s s_t;
/* s_t is an incomplete type here */
struct s { /*...*/ }; /* creates new type, redeclares `s', implicitly
redeclares (redefines) s_t */
/* s_t is a (different) complete type now */
The meaning of a typedef name depends on the context (therefore we
cannot say that it aliases some _particular_ type).

It can only alias the type that is the completion of "struct s".

If you're familiar with Unix filesystem semantics, a typedef is
vaguely analogous to a symbolic link. Creating a symbolic link (with
"ln -s") corresponds to a typedef definition -- even if the target of
the symbolic link doesn't exist yet. Creating or changing the target
of the symlink doesn't re-create the symlink itself, it merely creates
or changes the distinct entity to which it refers. (That's probably
not a great analogy.)

The entity created by "typedef struct s s_t;" is a compile-time
*reference* to a type; the definition associates the identifier "s_t"
with that reference. Whether the referenced type is complete or
incomplete may change depending on other declarations, but the
reference exists as soon as the typedef definition itself is
processed.

[...]

But then why other declarations are not definitions?
`foo_t' is just another name for `int' type.
struct s;
creates new type and gives it a name `s' (in tag namespace).
Why doesn't this declaration _define_ the identifier `s'?

(Interestingly, `struct s;' does not "define a new type", but "declares
a new type", 6.7.2.3 p.5 and p.7; this is another mystery what
the difference is.)

I would say that "struct s;" doesn't define a type, but does define a
tag. I'm not sure whether the standard agrees with me.

If we make the definition of definition so fuzzy we do not advance the
understanding of others on what we are talking about. Rather than
looking for all sorts of things that might be called definitions, I
choose to define definition itself as creating an object or function so
that I can look at a header (.h) and determine there are no definitions
there, only declarations. Yes Virginia, '#define X 2' is a declaration,
not a definition.

I'm also the quy who maintains that a pointer is an object, not an
address. I maintain that 'char *foo();' has type 'pointer to char' but
returns a value of that type, an address, not a pointer.

char *line;
line = foo();

The object 'line' is the pointer.

I'm not doing this to start another fight. I simply believe we should be
more exclusive than inclusive in the selection of terms used to describe
our precious C programming language. When we tell people "Well, a
pointer could be this, or that. Still it might be something else
depending on context." we are not helping.

--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Nov 14 '05 #30

Joe Wright <jo********@comcast.net> writes:

Keith Thompson wrote: [...] If we make the definition of definition so fuzzy we do not advance the
understanding of others on what we are talking about. Rather than
looking for all sorts of things that might be called definitions, I
choose to define definition itself as creating an object or function
so that I can look at a header (.h) and determine there are no
definitions there, only declarations. Yes Virginia, '#define X 2' is a
declaration, not a definition.
I'm actually trying to make the definition of "definition" as simple
as possible. A definition is a declaration that introduces an
identifier, creates an entity of some sort, and associates the
identifier with the entity. A declaration that is not a definition
refers to the name of an existing entity that's defined elsewhere.
There are entities other than objects and functions; I think that
limiting the meaning of "definition" to just those two things is
needlessly confusing.

And "#define X 2" is neither a declaration nor a definition. It's a
preprocessor directive, which ceases to exist by the time we get to
the compilation phase that deals with declarations.
I'm also the quy who maintains that a pointer is an object, not an
address. I maintain that 'char *foo();' has type 'pointer to char' but
returns a value of that type, an address, not a pointer.

char *line;
line = foo();

The object 'line' is the pointer.

I'm not doing this to start another fight. I simply believe we should
be more exclusive than inclusive in the selection of terms used to
describe our precious C programming language. When we tell people
"Well, a pointer could be this, or that. Still it might be something
else depending on context." we are not helping.

I actually like the idea of using the unqualified term "pointer" only
for an object of pointer type, and "address" only for a value of
pointer type. Unfortunately, the standard does not consistently use
this convention. For example, IIRC, it says that malloc() (on
success) returns a pointer to the allocated memory.

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

Nov 14 '05 #31

pete

Keith Thompson wrote:

"S.Tobias" <si***@FamOuS.BedBuG.pAlS.INVALID> writes:

I have recently asked in c.s.c (Subject: the term "definition")
the question why the C Std defines the term /definition/ this way,
but I haven't obtained any satisfactory explanation.

It seems fairly straightforward to me. A definition creates some
entity and associates a new name with it. For an object definition,
the entity is the object, and creation includes reserving storage for
it. For a function definition, the entity is a function. For a
typedef name, the entity is an alias (or whatever you want to call it)
for a type. For an enumeration constant, it's the enumerator.

In all these cases, the definition *introduces* the identifier and
associates it with the defined entity. Given any of

int foo;
void foo(void) { }
enum { foo };
typedef int foo;

there was nothing called "foo" before the definition. Given:

extern int bar;
void bar(void);

there has to be some pre-existing entity called "bar", whose
definition is elsewhere.

A definition defines (creates) something. A declaration that isn't a
definition merely declares something (i.e., asserts that it already
exists).

I think that a complete structure declaration:

struct list_node {
struct list_node *next;
void *data;
};

does as much creating and or defining, as a typedef does.

--
pete

Nov 14 '05 #32

Keith Thompson wrote:

Joe Wright <jo********@comcast.net> writes:
Keith Thompson wrote:

[...]
If we make the definition of definition so fuzzy we do not advance the
understanding of others on what we are talking about. Rather than
looking for all sorts of things that might be called definitions, I
choose to define definition itself as creating an object or function
so that I can look at a header (.h) and determine there are no
definitions there, only declarations. Yes Virginia, '#define X 2' is a
declaration, not a definition.

I'm actually trying to make the definition of "definition" as simple
as possible. A definition is a declaration that introduces an
identifier, creates an entity of some sort, and associates the
identifier with the entity. A declaration that is not a definition
refers to the name of an existing entity that's defined elsewhere.
There are entities other than objects and functions; I think that
limiting the meaning of "definition" to just those two things is
needlessly confusing.

And "#define X 2" is neither a declaration nor a definition. It's a
preprocessor directive, which ceases to exist by the time we get to
the compilation phase that deals with declarations.

I'm also the quy who maintains that a pointer is an object, not an
address. I maintain that 'char *foo();' has type 'pointer to char' but
returns a value of that type, an address, not a pointer.

char *line;
line = foo();

The object 'line' is the pointer.

I'm not doing this to start another fight. I simply believe we should
be more exclusive than inclusive in the selection of terms used to
describe our precious C programming language. When we tell people
"Well, a pointer could be this, or that. Still it might be something
else depending on context." we are not helping.

I actually like the idea of using the unqualified term "pointer" only
for an object of pointer type, and "address" only for a value of
pointer type. Unfortunately, the standard does not consistently use
this convention. For example, IIRC, it says that malloc() (on
success) returns a pointer to the allocated memory.

The Standard is not always right, even though it is always Standard.

--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Nov 14 '05 #33

pete <pf*****@mindspring.com> writes:

Keith Thompson wrote:

[...]

A definition defines (creates) something. A declaration that isn't a
definition merely declares something (i.e., asserts that it already
exists).

I think that a complete structure declaration:

struct list_node {
struct list_node *next;
void *data;
};

does as much creating and or defining, as a typedef does.

I agree. I would also consider this to include definitions of the
member names "next" and "data".

But now that I take a look at C99 6.7p5, I see that it restricts the
term "definition" to objects, functions, enumeration constants, and
typedef names.

I am, as always, disappointed to see that I'm right and the standard
is wrong. 8-)} >> 1

More seriously, I'll stand by my previous discussions about what a
"definition" *should* be, but I must acknowledge that the standard
doesn't use the term that way. In the future, I'll be careful to use
the term only in the way the standard does, or at least point out when
I'm being inconsistent.

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

Nov 14 '05 #34

S.Tobias

Keith Thompson <ks***@mib.org> wrote:

"S.Tobias" <si***@FamOuS.BedBuG.pAlS.INVALID> writes:
[snipped and re-ordered]

But then why other declarations are not definitions?
`foo_t' is just another name for `int' type.
struct s;
creates new type and gives it a name `s' (in tag namespace).
Why doesn't this declaration _define_ the identifier `s'?

(Interestingly, `struct s;' does not "define a new type", but "declares
a new type", 6.7.2.3 p.5 and p.7; this is another mystery what
the difference is.)

I would say that "struct s;" doesn't define a type, but does define a
tag. I'm not sure whether the standard agrees with me.
In the two declarations:
/* 1 */ typedef int foo_t;
/* 2 */ struct s;
(1) only makes a new name for an existing type, nothing substantially
new is created. (2) creates a *new* type (whether it has struct-body
or not) and gives it the name (tag) `s'. Of the two, IMHO, (2) deserves
more to be a "definition" of `s'.
(But also see below.)

In my last remark (between parens) I meant to say, that the Std chooses
to use the word "declare" to refer to type, whereas "declaration"
usually refers to identifiers. But maybe this is another issue.

The entity created by "typedef struct s s_t;" is a compile-time
*reference* to a type; the definition associates the identifier "s_t"
with that reference.

Here and elsewhere you put forward an interesting idea that a
/definition/ creates a new entity, and that a typedef actually
creates an entity (and therefore is a definition). I tried
to follow this trail.

C Std does not formally define what an "entity" is, but nevertheless
it gives clear hints:
(6.2.1)
# 1 An identifier can denote an object; a function; a tag or a
# member of a structure, union, or enumeration; a typedef name;
# a label name; a macro name; or a macro parameter. The same
# identifier can denote different entities at different points
# in the program. [...]
# 2 For each different entity that an identifier designates, [...]
Therefore an entity is something that an identifier may designate.

[ C++ has a (different) definition of an entity:
# 3 An /entity/ is a value, object, subobject, base class subobject,
# array element, variable, function, instance of a function,
# enumerator, type, class member, template, or namespace. ]

Note that typedef-name is an entity in C (but not in C++), which
is created by the typedef declaration. It looks as if:
[identifier] --designates--> [typedef-name] --denotes--> [type]
ie. the identifier does not directly denote a type , but designates
an intermediate abstract entity "typedef-name" created on the spot
(an identifier must designate something, and type is not an entity,
right?), which denotes a type.

I'm not sure if the above picture is correct (cf. 6.7.7p3), but
I don't see any other way to understand how anything can be
created in a typedef declaration.

[ In C++ a type is an entity, and the identifier, which *is*
a typedef-name, directly denotes a type. ]

Now, returning to the "definition": struct, union, enum members
are entities in C. If it were true that a definition is a declaration
that creates an entity, then declarations of struct members would
have to be their definitions as well. However, the Std only
explicitly includes enum members in a definition.

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

Nov 14 '05 #35

Richard Bos

Joe Wright <jo********@comcast.net> wrote:

Keith Thompson wrote:
I actually like the idea of using the unqualified term "pointer" only
for an object of pointer type, and "address" only for a value of
pointer type. Unfortunately, the standard does not consistently use
this convention. For example, IIRC, it says that malloc() (on
success) returns a pointer to the allocated memory.

The Standard is not always right, even though it is always Standard.

True in principle, but being the Standard, it is the one Standard we
have to follow. By using terminology that contradicts it, you are making
your writing less intelligible to anyone who is familiar with the
Standard.

Richard

Nov 14 '05 #36

john_bode

Emmanuel Delahaye wrote:

baumann@pan wrote on 27/05/05 :
typedef int (*pfunc)(int , int);
pfunc a_func;

i know it's ok,
Yes, and encouraged to have readable sources...
but how can define a_func without typedef statement?

You can :

int (*pfunc)(int , int);

by why would you do that except to obscure the code ?

The problem is that occasionally the typedef can do as much to obscure
the code as the original non-typedef'd version. For example, the
typedef name pfunc tells you nothing about the number and types of
function arguments expected. Not a problem if the typedef immediately
precedes the declaration, but if it appears in a header file somewhere
else, that's one more file you need to open or have a hardcopy handy to
know exactly what arguments are required.

My own rule of thumb is to never create a typedef name for an object
pointer type, unless that type is meant to be opaque and never
dereferenced directly. Similarly, I rarely create typedef names for
function pointers; it usually has to be some truly ugly case like

char *(*(*(*f)(char *name))[20])(FILE *in);

and even then I'm iffy (for the record, f is a pointer to a function
taking a single parameter of pointer to char and returning a pointer to
a 20-element array of pointers to functions taking a single parameter
of pointer to FILE and returning a pointer to char).

typedef char *(*getline_func_ptr)(FILE *in);
typedef getline_func_ptr (*getline_func_array_ptr)[20];
typedef getline_func_array_ptr
(*find_getline_func_array_ptr_by_name_func_ptr)(ch ar *name);

So now you have

find_getline_func_array_ptr_by_name_func_ptr f;

So yeah, the code *looks* cleaner, but by that declaration alone, can
you tell me what f expects as an argument, or what the return type
really looks like? If all the typedefs appear right above the
declaration, great. Otherwise you have to dig for something that tells
you what the typedef name means, what f takes as arguments, and how to
use the return value. And coming up with a reasonably descriptive
typedef name that doesn't take more than 80 characters isn't all that
easy sometimes, either. So you wind up writing a short novel of
comments describing the typedef name every time you use it. OTOH, if
you don't use a typedef, all that information is there in compact form.
I'll use typedef names for struct or union types all the time, though.
Go figure.
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Nov 14 '05 #37

Richard Bos wrote:

Joe Wright <jo********@comcast.net> wrote:

Keith Thompson wrote:
I actually like the idea of using the unqualified term "pointer" only
for an object of pointer type, and "address" only for a value of
pointer type. Unfortunately, the standard does not consistently use
this convention. For example, IIRC, it says that malloc() (on
success) returns a pointer to the allocated memory.

The Standard is not always right, even though it is always Standard.

True in principle, but being the Standard, it is the one Standard we
have to follow. By using terminology that contradicts it, you are making
your writing less intelligible to anyone who is familiar with the
Standard.

Richard

The point of using 'pointer' as the object and 'address' as the value is
to make my explanations more intelligible. Using the terms
interchangeably fosters confusion. The Standard gets this wrong.

--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Nov 14 '05 #38