Pointer to function inside struct

[dmjcunha]

If I have on a header file:

struct structure1 {
int a;
int b; };

struct structure2 {
struct structure1 *(*create)(int k, int j);
...; }; |
|
\/
should I read this as a pointer to function create returning pointer to structure1?

And more, how should I implement the function? Should it follow exactly the same naming as in the declaration? Something else?

That's because I'm searching in the directory source tree for this same name declaration "struct structure1 *(*create)(int k, int j)" in *.c files and cannot find anything...

Please, some help. Thank's.

 

[Eric Sosman]

If I have on a header file:

struct structure1 {
int a;
int b; };

struct structure2 {
struct structure1 *(*create)(int k, int j);
...; }; |
|
\/
should I read this as a pointer to function create returning pointer to structure1?

Almost. It's a pointer that can point at a function of
two `int' arguments returning a `struct structure1 *' -- thus
far, you're right. But `create' is only the name of the field
in the `struct structure2', just as `a' and `b' name fields of
`struct structure1'. The functions that the `create' field
can point at will all have the same "signature" -- they'll all
take two `int' arguments and return a `struct structure1 *' --
but they can have any names at all.

And more, how should I implement the function? Should it follow exactly the same naming as in the declaration? Something else?

Here are two functions that a `create' field might point at:

struct structure2 * make(int x, int y) {
struct structure2 *ptr = malloc(sizeof *ptr);
if (ptr != NULL) {
ptr->a = x;
ptr->b = y;
}
return ptr;
}

struct structure2 * bake(int foo, int bar) {
struct structure2 *p = malloc(sizeof *p);
if (p) {
p->a = foo / bar;
p->b = foo % bar;
}
return p;
}

Both these functions might exist in your program, and the `create'
field of a `struct structure2' could point at either:

struct structure2 buzz;
struct structure2 bomb;
buzz.create = make;
bomb.create = bake;

Later, you could call whatever the `create' field points at,
without needing to know exactly what function that is:

struct structure2 beep;
...
struct structure1 *grog = beep.create(42, 27);

That's because I'm searching in the directory source tree for this same name declaration "struct structure1 *(*create)(int k, int j)" in *.c files and cannot find anything...

A target function *might* be named `create', but it might
be named `make' or `bake' or `zaphodBeeblebrox'. What you need
to search for is the place where the `create' field is initialized
or assigned to, and see what function names are used.

 

[Noob]

If I have on a header file:

struct structure1 {
int a;
int b; };

struct structure2 {
struct structure1 *(*create)(int k, int j);
...; };

I always use a typedef for function pointers.

typedef struct structure1 *func_t(int k, int j);
struct structure2 {
func_t *create;
};

struct structure1 *foobar(int k, int j)
{
return NULL;
}

struct structure2 xyz;
xyz.create = foobar;

 

[Tim Rentsch]

If I have on a header file:

struct structure1 {
int a;
int b; };

struct structure2 {
struct structure1 *(*create)(int k, int j);
...; }; |
|
\/
should I read this as a pointer to function create returning pointer to structure1?

Almost. It's a pointer that can point at a function of
two `int' arguments returning a `struct structure1 *' -- thus
far, you're right. But `create' is only the name of the field
in the `struct structure2', just as `a' and `b' name fields of
`struct structure1'. The functions that the `create' field
can point at will all have the same "signature" -- they'll all
take two `int' arguments and return a `struct structure1 *' --
but they can have any names at all. [snip]

The last sentence is wrong in a couple of different ways. In C
the term is type, not signature; the various target functions
will have the same type (provided they have been suitably
declared, which they may not have been, and indeed they might not
even be written in C; even so the appropriate term is type).
Furthermore, the sentence above misuses the term "signature" to
mean _only_ the type, which isn't how it is generally used.
Different functions, even if they have the same type, will not
have the same 'type signature'

http://en.wikipedia.org/wiki/Type_signature

Personally I think 'type signature' is kind of a stupid term,
because basically it means the same thing as "declaration".
But people want to sound smart so they say 'type signature'
instead of 'declaration'. However, if one is going to use
the term, at least use it correctly: appropriate targets
for the above pointer-to-function will all have compatible
types, but they will not have the same type signature.

 

[glen herrmannsfeldt]

(snip, someone wrote)

The last sentence is wrong in a couple of different ways. In C
the term is type, not signature; the various target functions
will have the same type (provided they have been suitably
declared, which they may not have been, and indeed they might not
even be written in C; even so the appropriate term is type).
Furthermore, the sentence above misuses the term "signature" to
mean _only_ the type, which isn't how it is generally used.
Different functions, even if they have the same type, will not
have the same 'type signature'

Personally I think 'type signature' is kind of a stupid term,
because basically it means the same thing as "declaration".
But people want to sound smart so they say 'type signature'
instead of 'declaration'. However, if one is going to use
the term, at least use it correctly: appropriate targets
for the above pointer-to-function will all have compatible
types, but they will not have the same type signature.

I don't especially like it either.

Still, in Java the signature does not include the return type.
I am not sure about other languages.

-- glen

 

[BartC]

`struct structure1'. The functions that the `create' field
can point at will all have the same "signature" -- they'll all
take two `int' arguments and return a `struct structure1 *' --
but they can have any names at all. [snip]

The last sentence is wrong in a couple of different ways. In C
the term is type, not signature; the various target functions
will have the same type (provided they have been suitably
declared, which they may not have been, and indeed they might not
even be written in C; even so the appropriate term is type).
Furthermore, the sentence above misuses the term "signature" to
mean _only_ the type, which isn't how it is generally used.
Different functions, even if they have the same type, will not
have the same 'type signature'

http://en.wikipedia.org/wiki/Type_signature

That article says the signature includes the name of the function. That's
wrong. And not very useful. (It suggests a function is only compatible with
itself...)

Personally I think 'type signature' is kind of a stupid term,
because basically it means the same thing as "declaration".
But people want to sound smart so they say 'type signature'
instead of 'declaration'. However, if one is going to use
the term, at least use it correctly: appropriate targets
for the above pointer-to-function will all have compatible
types, but they will not have the same type signature.

There are two attributes of a function: its signature (the set of
parameters, plus the return type), and its type (what value it yields when
a call to it is used in an expression, which is the same as its return
type).

So signature and type can mean two different things.

Two functions can be compatible if they have the same signature (you can
substitute the name of one, with the name of the other, and it should still
be valid type-wise). And when you have function pointers, there is no name
of the function to consider, only signature (which in C you might call the
'type' just before you call it, and then have another type as its result).

A declaration isn't quite the same as a signature either, but you can define
a signature using a declaration. It would be like saying a type is the same
as a declaration too.

 

[Stephen Sprunk]

That article says the signature includes the name of the function.
That's wrong. And not very useful. (It suggests a function is only
compatible with itself...)

If an article needs improvement, it's generally faster to do so yourself
than to complain about it to others.

(You don't even need to create an account, though IMHO there are a good
reasons to do so.)

S

 

[Tim Rentsch]

`struct structure1'. The functions that the `create' field
can point at will all have the same "signature" -- they'll all
take two `int' arguments and return a `struct structure1 *' --
but they can have any names at all. [snip]

The last sentence is wrong in a couple of different ways. In C
the term is type, not signature; the various target functions
will have the same type (provided they have been suitably
declared, which they may not have been, and indeed they might not
even be written in C; even so the appropriate term is type).
Furthermore, the sentence above misuses the term "signature" to
mean _only_ the type, which isn't how it is generally used.
Different functions, even if they have the same type, will not
have the same 'type signature'

http://en.wikipedia.org/wiki/Type_signature

That article says the signature includes the name of the
function. That's wrong. [snip]

No, it isn't. Try looking up what a signature is in, for
example, the C++ language definition document or the Java
language definition document.

There are two attributes of a function: its signature (the set
of parameters, plus the return type),

Again, this usage is out of step with how the term is used
in languages that have an official definition.

and its type (what value it yields when a call to it is used in
an expression, which is the same as its return type).

And this is wrong for C. In C the type of a function also gives
a specification for the types of the function parameters. That
may be a partial specification rather than a full specification,
but a function type always includes some information about what
parameter typings are allowed.

So signature and type can mean two different things.

They do mean different things, because a signature includes
the name of the function, method, or constructor in question.

Two functions can be compatible if they have the same signature
(you can substitute the name of one, with the name of the other,
and it should still be valid type-wise). And when you have
function pointers, there is no name of the function to consider,
only signature (which in C you might call the 'type' just before
you call it, and then have another type as its result).

In C the type of a function includes both the type of its result
and the types of its parameters. If the distinction is important
we might say "fully specified type" rather than just "type", but
these days developers almost always write function declarations
using prototypes, so in most cases there is no difference. Some
people misuse the term "signature" to mean essentially the same
thing as "fully specified type", but (a) there's no reason to do
so, since "type" or "fully specified type" works just fine, and
(b) the term "signature" is not defined (indeed, the word never
appears) in the Standard, and other languages that use the term
define it differently.

A declaration isn't quite the same as a signature either,

The term "signature" means different things in different languages,
but AFAIAA all languages that use the term (ie, as part of their
official definition) include some kind of name information along
with type information. Furthermore my comment was about the term
"type signature", as explained in the Wikipedia article. That
definition is pretty close to what most languages would call a
declaration, the main differences being (a) declarations often
include some additional keywords or punctuation so that they may be
identified as declarations in the program, and (b) declarations
may be given for both non-functions and functions, whereas "type
signature" applies only to function or function-like entities.
The two terms clearly aren't the same, but there is an obvious
mapping between them which is (for functions) basically an
isomorphism.

but you can define a signature using a declaration.

Here again you're assuming that your personal usage corresponds
to how the term is used in other languages. It doesn't. In C++,
for example, a declaration by itself is not enough to infer a
function signature, which also includes the namespace(s) in which
the function is defined.

It would be like saying a type is the same as a declaration
too.

Only if one mistakenly assumes that the terms "signature" or "type
signature" are basically synonymous with "fully specified type",
which they are not.

 

[James Kuyper]

That article says the signature includes the name of the function. That's
wrong. And not very useful. (It suggests a function is only compatible with
itself...)

The concept of a function signature plays no part in C's definition of
function compatibility, so the participation of a function's name in
it's signature is no barrier to compatibility.
I'm only familiar with one language which does use the concept of
signatures (which is a measure of my ignorance, not an assertion that
there are few such languages) - that language is C++. It quite clearly
defines the signature as including the name (sections 1.3.17-22, in the
latest draft I have copy of, dated 2012-01-16). This conflicts with what
I thought "signature" meant, but I searched for text making use of that
term, and didn't find any such text where the fact that the signature
includes the function name would be a problem. In particular, I didn't
see any problems it might cause for compatibility. I might have missing
something.

 

[Seebs]

No, it isn't. Try looking up what a signature is in, for
example, the C++ language definition document or the Java
language definition document.

This is interesting. I've often seen "signature" used to refer to the
function's type, as in "you need a function matching the signature of..."

Again, this usage is out of step with how the term is used
in languages that have an official definition.

I don't have specs for them, but I am not sure that this is persuasive
in a discussion of C, and even in C++, I see plenty of examples of people
using the term in the sense of "type of arguments and return".

I suspect that what's happened here is that the concept of "a signature which
is compatible with the signature of X" or something similar got compressed and
extra words dropped. So in practice, it appears that people frequently talk of
two signatures "matching" even if one or more of the names involved are
different.

-s

 

[Tim Rentsch]

This is interesting. I've often seen "signature" used to refer
to the function's type, as in "you need a function matching the
signature of..."

Yes; it is, regrettably, a common misusage.

I don't have specs for them, but I am not sure that this is
persuasive in a discussion of C, and even in C++, I see plenty
of examples of people using the term in the sense of "type of
arguments and return".

I see plenty of examples in comp.lang.c where people make
mistaken claims about what ISO C allows or doesn't. That
doesn't mean the claims are right.

Perhaps more to the point, the purpose of my comments is to say
(a) the term "signature" has no official definition in the ISO C
standard, (b) in languages where it does have an official
definition, it means something significantly different from how
people often use it here, (c) it's confusing to use a "common"
term to mean something different from what it officially means,
and (d) as far as C goes there is no reason to do so since C
defines "type" to mean basically the same thing that people mean
when they say "signature". And I think it's a bad idea for
another reason, namely, sloppy language promotes sloppy thinking.
I think it's worthwhile to discourage both. Are these comments
all ones you agree with? If not, with which ones do you not
agree?

I suspect that what's happened here is that the concept of "a
signature which is compatible with the signature of X" or
something similar got compressed and extra words dropped. So
in practice, it appears that people frequently talk of two
signatures "matching" even if one or more of the names involved
are different.

AFAIK the term 'signature' was first used in the programming
language Russell, where it meant something different still, and
certainly did not mean 'type', because Russell also used the term
'type' and that was clearly distinct from signatures (among other
things, types existed at runtime, whereas signatures existed
purely at compile time). (IIRC signatures in Russell were rather
elaborate compound entities, and included names of operations.)

As far as what may have happened, to me it seems more likely
that people picked up the term without really understanding what
it meant in the original context, and started using it without
knowing what it was supposed to mean, because it sounds more
cool and more sophisticated than a short word like type. And
unfortunately that misunderstanding has gotten propogated by the
term being repeated by further people who mimicked what they
heard without bothering to go back and try to find out where
the term may have come from. Sometimes that's good for natural
language; for technical language it usually isn't.

 

[glen herrmannsfeldt]

(snip)

AFAIK the term 'signature' was first used in the programming
language Russell, where it meant something different still, and
certainly did not mean 'type', because Russell also used the term
'type' and that was clearly distinct from signatures (among other
things, types existed at runtime, whereas signatures existed
purely at compile time). (IIRC signatures in Russell were rather
elaborate compound entities, and included names of operations.)

As far as what may have happened, to me it seems more likely
that people picked up the term without really understanding what
it meant in the original context, and started using it without
knowing what it was supposed to mean, because it sounds more
cool and more sophisticated than a short word like type. And
unfortunately that misunderstanding has gotten propogated by the
term being repeated by further people who mimicked what they
heard without bothering to go back and try to find out where
the term may have come from. Sometimes that's good for natural
language; for technical language it usually isn't.

I suppose, but it seems to me that, at least in some languages,
it is meant to be the unambiguously unique indication of which
routine to call. We also hope that our written signatures
are unambiguously unique, so it makes some sense.

-- glen

 

[Seebs]

Yes; it is, regrettably, a common misusage.

If it's sufficiently common, I'd argue that the formal definitions are
probably wrong.

I see plenty of examples in comp.lang.c where people make
mistaken claims about what ISO C allows or doesn't. That
doesn't mean the claims are right.

Fair enough...

Perhaps more to the point, the purpose of my comments is to say
(a) the term "signature" has no official definition in the ISO C
standard,

This would argue that no definition of it contradicts the spec.

(b) in languages where it does have an official
definition, it means something significantly different from how
people often use it here,

Is that *always* true or just true of those particular languages?

Come to think of it: I'm pretty sure Haskell uses the distinction that
"type signature" refers to the pattern of types associated with a given
function.

And I've spotted a significant difference, looking at usages in other
languages: A "type signature" may express information which is not really
there in the code. For instance, Lua doesn't really have variable typing
like C does, but an API spec may give information about the types accepted and
returned anyway -- and call that a type signature.

(c) it's confusing to use a "common"
term to mean something different from what it officially means,
and

True, but my view would be that there's no official meaning in C.

(d) as far as C goes there is no reason to do so since C
defines "type" to mean basically the same thing that people mean
when they say "signature".

While this is arguably true, it seems to me that there's a significant
connotational difference here. Connotations aren't always in the formal spec,
but are part of how people keep things disentangled.

*thinks*

Okay, my vague sense of the usage difference: A type is just the pattern of
bits a given thing is using. A signature is a thing you are supposed to match.

And I think it's a bad idea for
another reason, namely, sloppy language promotes sloppy thinking.

I mostly agree, but!

It is sometimes a sign that people need more distinctions than the formal
terminology provides.

As far as what may have happened, to me it seems more likely
that people picked up the term without really understanding what
it meant in the original context, and started using it without
knowing what it was supposed to mean, because it sounds more
cool and more sophisticated than a short word like type. And
unfortunately that misunderstanding has gotten propogated by the
term being repeated by further people who mimicked what they
heard without bothering to go back and try to find out where
the term may have come from. Sometimes that's good for natural
language; for technical language it usually isn't.

I have this vague recollection of seeing the term pretty early on in C stuff;
it never made it into the spec, but I think it was used in other writing early
on.

-s

 

[88888 Dihedral]

Tim Rentschæ–¼ 2013å¹´3月20日星期三UTC+8上åˆ6時29分23秒寫é“：

Yes; it is, regrettably, a common misusage.

My personally favorite function proto-types in c is the following:

1.
int fun( T* input, T2* output, ... plus call by value parameters)

for any function that could fail an execution code
is returned just mimic a sub-process under the unix system.

2. T fun(T1 input); or T fun(T1* input), T* fun(T1 input),
T* fun(T1 *input ) for those can't fail in the run time.

 

[Philip Lantz]

Yes; it is, regrettably, a common misusage.

(b) in languages where it does have an official
definition, it means something significantly different from how
people often use it here, (c) it's confusing to use a "common"
term to mean something different from what it officially means,

Agreed, but it's also confusing for a standard to coopt a common term
and give it a definition that differs from the way it is commonly used.
I don't know that that's what has happened with this term in C++, but I
was surprised to read in this thread what the standard definition is,
since it differs from the way I have heard the term used (or at least,
the way I understood it to be used).

 

[James Kuyper]

On 03/20/2013 05:50 AM, Philip Lantz wrote:
....

I don't know that that's what has happened with this term in C++, but I
was surprised to read in this thread what the standard definition is,
since it differs from the way I have heard the term used (or at least,
the way I understood it to be used).

Agreed. The distinction, as I remembered it, was that a function's type
was "function returning T", whereas a function's signature was "function
taking this specific list of argument types, returning T", with "..."
being a special case in the argument list. That the function's signature
also includes the name of the function and the namespace in which it is
defined came as a surprise to me, and I'm now wondering where I got the
other idea from, and what aspects of C++ I may have misunderstood as a
result of interpreting that term incorrectly.

 

[Shao Miller]

Agreed, but it's also confusing for a standard to coopt a common term
and give it a definition that differs from the way it is commonly used.
I don't know that that's what has happened with this term in C++, but I
was surprised to read in this thread what the standard definition is,
since it differs from the way I have heard the term used (or at least,
the way I understood it to be used).

Suppose you wish to find a function in a library at run-time. One
strategy is to have a "signature" that makes sense to both the
programming language as well as the function-finding, run-time facility.

 

[glen herrmannsfeldt]

Tim Rentsch wrote:
(snip)

Agreed, but it's also confusing for a standard to coopt a common term
and give it a definition that differs from the way it is commonly used.
I don't know that that's what has happened with this term in C++, but I
was surprised to read in this thread what the standard definition is,
since it differs from the way I have heard the term used (or at least,
the way I understood it to be used).

Seems to me that Fortran has many terms with different meaning than
the usual CS definition, but in most cases Fortran got there first.

C has many meanings for 'static', only one of corresponding
to the usual definition. (I haven't counted recently.)

-- glen

 

[James Kuyper]

On 03/20/2013 05:50 AM, Philip Lantz wrote:
...

Agreed. The distinction, as I remembered it, was that a function's type
was "function returning T", whereas a function's signature was "function
taking this specific list of argument types, returning T", with "..."
being a special case in the argument list.

Correction: the signature does NOT include the function's return type,
and I've even posted messages (many years ago) that reflected a correct
understanding of that point. That was back when I had just finished
studying the 1998 C++ standard, and those concepts were fresher in my mind.

That makes it even more ridiculous to misuse "function signature" as a
synonym for "function type".

 

[Tim Rentsch]

(snip)


I suppose, but it seems to me that, at least in some languages,
it is meant to be the unambiguously unique indication of which
routine to call. We also hope that our written signatures
are unambiguously unique, so it makes some sense.

I think you misunderstood what I was trying to say (and maybe I
didn't say it clearly enough, no argument there). In cases like
C++, I think the language definers chose a word and a definition
deliberately, to suit their own purposes; they might or might
not have known about earlier usages in other languages, but that
doesn't matter because they are using the word for a different
purpose. What I was talking about is other people, who are not
language definers, but using what they think is an existing
definition, except their usage is different from the original
definition.