Pointer to function inside struct

Discussion in 'C Programming' started by dmjcunha@gmail.com, Mar 8, 2013.

  1. Guest

    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.
     
    , Mar 8, 2013
    #1
    1. Advertising

  2. Eric Sosman Guest

    On 3/8/2013 12:27 PM, wrote:
    > 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.

    --
    Eric Sosman
    d
     
    Eric Sosman, Mar 8, 2013
    #2
    1. Advertising

  3. Noob Guest

    dmjcunha wrote:

    > 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;
     
    Noob, Mar 8, 2013
    #3
  4. Tim Rentsch Guest

    Eric Sosman <> writes:

    > On 3/8/2013 12:27 PM, wrote:
    >> 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.
     
    Tim Rentsch, Mar 16, 2013
    #4
  5. Tim Rentsch <> wrote:

    (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'


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


    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
     
    glen herrmannsfeldt, Mar 16, 2013
    #5
  6. BartC Guest

    "Tim Rentsch" <> wrote in message
    news:...
    > Eric Sosman <> writes:


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

    --
    Bartc
     
    BartC, Mar 17, 2013
    #6
  7. On 17-Mar-13 07:04, BartC wrote:
    > "Tim Rentsch" <> wrote in message
    > news:...
    >> 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...)


    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

    --
    Stephen Sprunk "God does not play dice." --Albert Einstein
    CCIE #3723 "God is an inveterate gambler, and He throws the
    K5SSS dice at every possible opportunity." --Stephen Hawking
     
    Stephen Sprunk, Mar 17, 2013
    #7
  8. Tim Rentsch Guest

    "BartC" <> writes:

    > "Tim Rentsch" <> wrote in message
    > news:...
    >> Eric Sosman <> writes:

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

    >> 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),


    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.
     
    Tim Rentsch, Mar 17, 2013
    #8
  9. James Kuyper Guest

    On 03/17/2013 08:04 AM, BartC wrote:
    > "Tim Rentsch" <> wrote in message
    > news:...

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


    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.
    --
    James Kuyper
     
    James Kuyper, Mar 17, 2013
    #9
  10. Seebs Guest

    On 2013-03-17, Tim Rentsch <> wrote:
    > 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
    --
    Copyright 2013, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
     
    Seebs, Mar 19, 2013
    #10
  11. Tim Rentsch Guest

    Seebs <> writes:

    > On 2013-03-17, Tim Rentsch <> wrote:
    >> 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..."


    Yes; it is, regrettably, a common misusage.

    >> 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 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.
     
    Tim Rentsch, Mar 19, 2013
    #11
  12. Tim Rentsch <> wrote:

    (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
     
    glen herrmannsfeldt, Mar 20, 2013
    #12
  13. Seebs Guest

    On 2013-03-19, Tim Rentsch <> wrote:
    > Seebs <> writes:
    >> On 2013-03-17, Tim Rentsch <> wrote:
    >>> 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..."


    > 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
    --
    Copyright 2013, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
     
    Seebs, Mar 20, 2013
    #13
  14. Tim Rentschæ–¼ 2013å¹´3月20日星期三UTC+8上åˆ6時29分23秒寫é“:
    > Seebs <> writes:
    >
    >
    >
    > > On 2013-03-17, Tim Rentsch <> wrote:

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

    >
    >
    >
    > Yes; it is, regrettably, a common misusage.
    >
    >
    >
    > >> 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".

    >
    >
    >

    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.
     
    88888 Dihedral, Mar 20, 2013
    #14
  15. Philip Lantz Guest

    Tim Rentsch wrote:
    > Seebs writes:
    > > Tim Rentsch wrote:
    > >> 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..."

    >
    > Yes; it is, regrettably, a common misusage.
    >
    > >> Again, this usage is out of step with how the term is used
    > >> in languages that have an official definition.

    > >

    > (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).
     
    Philip Lantz, Mar 20, 2013
    #15
  16. James Kuyper Guest

    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.
    --
    James Kuyper
     
    James Kuyper, Mar 20, 2013
    #16
  17. Shao Miller Guest

    On 3/20/2013 05:50, Philip Lantz wrote:
    > Tim Rentsch wrote:
    >> Seebs writes:
    >>> Tim Rentsch wrote:
    >>>> 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..."

    >>
    >> Yes; it is, regrettably, a common misusage.
    >>
    >>>> Again, this usage is out of step with how the term is used
    >>>> in languages that have an official definition.
    >>>

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


    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.

    --
    - Shao Miller
    --
    "Thank you for the kind words; those are the kind of words I like to hear.

    Cheerily," -- Richard Harter
     
    Shao Miller, Mar 20, 2013
    #17
  18. Philip Lantz <> wrote:
    > Tim Rentsch wrote:


    (snip)
    >> (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).


    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
     
    glen herrmannsfeldt, Mar 20, 2013
    #18
  19. James Kuyper Guest

    On 03/20/2013 07:27 AM, James Kuyper wrote:
    > 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.


    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".
     
    James Kuyper, Mar 20, 2013
    #19
  20. Tim Rentsch Guest

    glen herrmannsfeldt <> writes:

    > Tim Rentsch <> wrote:
    >
    > (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.


    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.
     
    Tim Rentsch, Mar 21, 2013
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris Fogelklou
    Replies:
    36
    Views:
    1,441
    Chris Fogelklou
    Apr 20, 2004
  2. Ole
    Replies:
    4
    Views:
    623
    Michael Wojcik
    Oct 26, 2004
  3. beetle
    Replies:
    2
    Views:
    967
    beetle
    Jan 25, 2005
  4. Zero
    Replies:
    16
    Views:
    682
    Barry Schwarz
    Nov 19, 2005
  5. aleksa

    Struct pointer vs. struct array pointer

    aleksa, Feb 20, 2013, in forum: C Programming
    Replies:
    16
    Views:
    510
    Shao Miller
    Feb 20, 2013
Loading...

Share This Page