Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Pointer to function inside struct

Reply
Thread Tools

Pointer to function inside struct

 
 
Tim Rentsch
Guest
Posts: n/a
 
      03-21-2013
Philip Lantz <(E-Mail Removed)> writes:

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


I agree with your first sentence, but here I think the reverse is
true. That is, the C++ language definition defined something
they referred to by the term 'signature', and it was after that
that the term started to be used with a different meaning. I
don't think C++ co-opted a common term (the use in Russell was
earlier, but I don't think it was common). Actually I think
'signature' is reasonably descriptive for what it is C++ is
trying to connote; probably they could have done better, but it
is at least plausibly appropriate for what they mean to convey.

The "common meaning", on the other hand, besides being confusing as
to what is meant exactly, has nothing to offer beyond sophistry,
since we already have a perfectly good, and well-defined, term that
fills that need.
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      03-21-2013
Seebs <(E-Mail Removed)> writes:

> On 2013-03-19, Tim Rentsch <(E-Mail Removed)> wrote:
>> Seebs <(E-Mail Removed)> writes:
>>> On 2013-03-17, Tim Rentsch <(E-Mail Removed)> 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.


The formal definitions exist for a purpose (more accurately, for
several different purposes, depending on which definition), and
presumably they serve those purposes appropriately. I don't know
of any purpose served by defining 'signature' to mean "the type
of a function (in C?)", other than trying to sound grandiose.

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


That's true. The downside is that one doesn't know exactly what
is meant by the term.

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


It is true in all cases that I am aware of. If there
are different definitions in other languages certainly
I would like to hear about those.

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


Haskell uses the term 'type signature' in a way that's consistent
with the Wikipedia entry for the term, ie, it it includes the name
of the identifier being typed. (Source: Haskell 98 Report). A
'type signature' in Haskell is very much like what in C is called
a declaration.

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


I am not familiar with Lua, but this usage sounds consistent
with the Wikipedia entry for '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.


There isn't, and that's part of the problem. It's a fuzzy
word, and also unnecessary, since 'type' works perfectly well.

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


I don't know if there is one. If there is, I don't know what it
is. Just as important, I don't think everyone attributes exactly
the same meaning (connoted or otherwise) when they use the term.

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


I don't know what difference you're trying to identify. Types
have to match too. Also, 'type' certainly means more than just
what the bit patterns are. For example, 'const int' and 'int'
are different types, as are 'int *' and 'int *restrict'.

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


But do they in this case? The examples I've seen use 'signature'
pretty much as just a synonym for 'type'.

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


If your recollection of seeing it is vague, might it also be that
your recollection of what the term was supposed to mean is vague?
Searching pre-2000, I found a couple of examples in newsgroup
postings (I would have looked more, but the new Google Groups just
sucks), and the uses I found both use 'signature' in the sense
of 'type signature' on wikipedia, ie, the name along with the type.
 
Reply With Quote
 
 
 
 
Tiib
Guest
Posts: n/a
 
      03-21-2013
On Thursday, 21 March 2013 18:39:32 UTC+2, Tim Rentsch wrote:
> 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.


In C++: Signature of function is name, parameter type list, and
enclosing namespace (if any). There are no other meanings of
"signature of function" in C++.

Rest of the signatures in C++ are similarly well specified to identify
concrete thing exactly. Those are irrelevant to C being signatures of
member functions and template functions etc.

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


If C++ developer would confuse type of function with signature of it then
that would be terrible. Signature is very important in C++ since
overload resolution and argument dependent look-up depend on it. One who
does not understand those features should not use overloads in C++.

In C it does not matter since overloads are illegal in C so ... feel free
to misuse the term ... but ... it does not fit with common sense. By
common sense when I sign something then that is my signature. Signature
identifies me. So I would expect "signature of function" to identify
concrete function. Who else uses "signature" in sense of "type"?
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      03-21-2013
On 03/21/2013 02:29 PM, Tiib wrote:
> On Thursday, 21 March 2013 18:39:32 UTC+2, Tim Rentsch wrote:

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

>
> If C++ developer would confuse type of function with signature of it then
> that would be terrible. Signature is very important in C++ since
> overload resolution ...


Overload resolution is described in section 13.3. I found only one use
of the word "signature" there, in section 13.3.3.2p3. That was as part
of the phrase "cv-qualification signature", a concept that is described
in section 4.4p4, and is unrelated to function signatures. It would seem
to be the case that a person could read and correctly understand that
entire section, even without a correct understanding of the meaning of
"signature".

> ... and argument dependent look-up ...


Argument dependent name look-up is described in section 3.4.2, and that
description makes no use of the term "signature".

> ... depend on it. One who
> does not understand those features should not use overloads in C++.


I'm not saying that you're wrong about that - but if you are, the
dependence upon the signature must be somewhat indirect, if those
features can be described without making any use of the term. Would you
care to explain the connection in more detail?
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      03-21-2013
Tim Rentsch <(E-Mail Removed)> wrote:

(snip on signature, and its meaning in different programming
languages)

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


Seems to me that most new languages designers assume that their
new languages is better (at least for some things) than all the
others, and so don't really care about existing definitions.

As I noted earlier, Fortran seems to have different definitions
for many common CS words, but most likely was there first.

But okay, for not-language-designers, that is different.
Most likely they know at least one, and probably more than
one programming language. That can easily get one confused
over the existing usage.

-- glen
 
Reply With Quote
 
Tiib
Guest
Posts: n/a
 
      03-21-2013
On Thursday, 21 March 2013 21:21:25 UTC+2, James Kuyper wrote:
> On 03/21/2013 02:29 PM, ?? Tiib wrote:
> > On Thursday, 21 March 2013 18:39:32 UTC+2, Tim Rentsch wrote:

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

> >
> > If C++ developer would confuse type of function with signature of it then
> > that would be terrible. Signature is very important in C++ since
> > overload resolution ...

>
> Overload resolution is described in section 13.3. I found only one use
> of the word "signature" there, in section 13.3.3.2p3. That was as part
> of the phrase "cv-qualification signature", a concept that is described
> in section 4.4p4, and is unrelated to function signatures. It would seem
> to be the case that a person could read and correctly understand that
> entire section, even without a correct understanding of the meaning of
> "signature".


Oh that 13.3 is only heating you up on the true thing that is yet to come
(14.8.3).

> > ... and argument dependent look-up ...

>
> Argument dependent name look-up is described in section 3.4.2, and that
> description makes no use of the term "signature".


> > ... depend on it. One who
> > does not understand those features should not use overloads in C++.

>
> I'm not saying that you're wrong about that - but if you are, the
> dependence upon the signature must be somewhat indirect, if those
> features can be described without making any use of the term. Would you
> care to explain the connection in more detail?


My point was that understanding what signature is and what it is not is
important for those things. I was mostly about some diagnostics that
compilers will spit out about ambiguities. From standard 14.8.3 mentions signature and several other special cases all around standard.

The using directive messes overload resolution up, see 7.3.4/7. That
is very important but novices seem always learn to write ...

using namespace std;

.... as one of the first things and then will be confused.

Rest of it is more about templates and how those overload or hide.
Copy assignment operator and copy/move constructors for example are
always implicitly defined so defining or using-declaring template that
may produce same signature does not help; implicit definition hides
it.

The signature is important for other things too. Two functions
with fully same signature are same, so violate ODR; if template
parameters differ then there are no violations however (despite overload
resolution alone can not distinguish them). Virtual overrides
must match signature and return value must be co-variant otherwise
they do not override (again novices are often confused with it) etc.

That is why I said that one who does not understand the nuances will
be very confused when using overloads.
 
Reply With Quote
 
88888 Dihedral
Guest
Posts: n/a
 
      03-21-2013
Öö Tiib於 2013年3月22日星期五UTC+8上午2時29分20秒 寫道:
> On Thursday, 21 March 2013 18:39:32 UTC+2, Tim Rentsch wrote:
>
> > 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.

>
>
>
> In C++: Signature of function is name, parameter type list, and
>
> enclosing namespace (if any). There are no other meanings of
>
> "signature of function" in C++.
>
>
>
> Rest of the signatures in C++ are similarly well specified to identify
>
> concrete thing exactly. Those are irrelevant to C being signatures of
>
> member functions and template functions etc.
>
>
>
> > 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.

>
>
>
> If C++ developer would confuse type of function with signature of it then
>
> that would be terrible. Signature is very important in C++ since
>
> overload resolution and argument dependent look-up depend on it. One who
>


Since I use c++ most of the time for wrapping and interfacing
with works from others.

Writing member functions to be used quite often by others
without high maintainence fees is the common practice.


 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      03-21-2013
On 03/21/2013 04:45 PM, Tiib wrote:
> On Thursday, 21 March 2013 21:21:25 UTC+2, James Kuyper wrote:
>> On 03/21/2013 02:29 PM, ?? Tiib wrote:

....
>>> If C++ developer would confuse type of function with signature of it then
>>> that would be terrible. Signature is very important in C++ since
>>> overload resolution ...

>>
>> Overload resolution is described in section 13.3. I found only one use
>> of the word "signature" there, in section 13.3.3.2p3. That was as part
>> of the phrase "cv-qualification signature", a concept that is described
>> in section 4.4p4, and is unrelated to function signatures. It would seem
>> to be the case that a person could read and correctly understand that
>> entire section, even without a correct understanding of the meaning of
>> "signature".

>
> Oh that 13.3 is only heating you up on the true thing that is yet to come
> (14.8.3).


The only thing that 14.8.3 says about the signature is that it's the
only aspect of a function template specialization that is needed in
order to resolve overloading. The actual description of overloading in
that section is entirely in other terms - again, it's hard to see how
confusion about what a function signature is could prevent proper
understanding of 14.8.3.

....
> The using directive messes overload resolution up, see 7.3.4/7. That
> is very important but novices seem always learn to write ...


"An ambiguity exists if the best match finds two functions with the same
signature, ...".
That is an important point that does depend upon the signature. However,
someone who incorrectly thought, as I used to, that the name played no
role in the signature, would not reach an incorrect conclusion because
of that error. That's because overload resolution only comes into play
when the names are the same.

Similarly, someone like me who incorrectly thought that the namespace
played no role in the signature, would not reach an incorrect
conclusion, either. That's because the only way of finding two matching
functions that differ only in their namespaces, without either one
hiding the other, is by use of a using direction, and that paragraph
goes on to say "..., even if one is in a namespace reachable through
using-directives in the namespace of the other." At the very least, that
statement confuses the issue: since the namespace is part of the
signature, how can functions declared in two different namespaces have
the same signature?

> The signature is important for other things too. Two functions
> with fully same signature are same, so violate ODR; ...


3.5p9 refers to "two names that are the same", "members of the same
namespace or members, not by inheritance, of the same class", and "the
parameter-type-list of the functions ... are identical". You don't need
to understand that those three things mean that the functions have the
same signature, in order to use 3.5p9 to conclude that they denote the
same function.

For function templates, on the other hand, 3.5p9 refers explicitly to
the signature - a correct understanding of 1.3.18 is, therefore, needed
to understand when two different function template declarations denote
the same function template.

> ... Virtual overrides
> must match signature ...


10.3p2 doesn't use the concept of a signature when describing the
requirements for overriding. That's good, because according to 1.3.20,
the class that a member function is a member of is part of it's
signature, so an overrider could never have the same signature as the
function it's overriding. What is actually required is "... same name,
parameter-type-list, ...", among other things. Once again, you don't
need to correctly understand the meaning of "signature" in order to
correctly determine whether one member function meets the requirements
for overriding another.
 
Reply With Quote
 
Tiib
Guest
Posts: n/a
 
      03-21-2013
On Friday, 22 March 2013 00:03:28 UTC+2, James Kuyper wrote:
> On 03/21/2013 04:45 PM, �� Tiib wrote:
> > Oh that 13.3 is only heating you up on the true thing that is yet to come
> > (14.8.3).

>
> The only thing that 14.8.3 says about the signature is that it's the
> only aspect of a function template specialization that is needed in
> order to resolve overloading. The actual description of overloading in
> that section is entirely in other terms - again, it's hard to see how
> confusion about what a function signature is could prevent proper
> understanding of 14.8.3.


Ok, you won. My bad. I did not think that way. For me it just feels
too natural that signature contains name. How else? What I write
when I sign something? My name. But I am not native English
speaker so some nuance of the term has been possibly "lost in
translation" and the term is less clear in English.

Someone may always understand written text correctly even if he
does partially misunderstand the terms used. He can think that
overload resolution implicitly involves same name and scope so the
signature may be something that is applied on top of it. Same is with
overrides and same with ODR and signatures produced by template
instantiations.
 
Reply With Quote
 
Bart van Ingen Schenau
Guest
Posts: n/a
 
      03-22-2013
On Thu, 21 Mar 2013 16:14:55 -0700, Öö Tiib wrote:

> Someone may always understand written text correctly even if he does
> partially misunderstand the terms used. He can think that overload
> resolution implicitly involves same name and scope so the signature may
> be something that is applied on top of it. Same is with overrides and
> same with ODR and signatures produced by template instantiations.


Given the definition of signature in C++98, it is not even surprising
that this alternative understanding of the term gets used. You have to
analyze all the relevant clauses carefully to reach the conclusion that
the name is actually part of the signature.

<quote C++98>
1.3.10 signature
the information about a function that participates in overload resolution
(13.3): the types of its parameters and, if the function is a class
member, the cv-qualifiers (if any) on the function itself and the class
in which the member function is declared.[footnote] The signature of a
function template specialization includes the types of its template
arguments (14.5.5.1).
</quote>
<quote footnote>
Function signatures do not include return type, because that does not
participate in overload resolution.
</quote>

As you can see, the function's name is not mentioned in the definition.
The only reason that the name should be considered part of the signature
is because the name lookup is described (in 13.3) as being part of the
overload resolution. With an alternative formulation of overload
resolution (as in, it being performed *after* name lookup, if multiple
function with the same name were found) it would have been correct to
have the term signature cover only the information mentioned explicitly
in its definition.

Bart v Ingen Schenau
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Struct pointer vs. struct array pointer aleksa C Programming 16 02-20-2013 08:20 PM
Can *common* struct-members of 2 different struct-types, that are thesame for the first common members, be accessed via pointer cast to either struct-type? John Reye C Programming 28 05-08-2012 12:24 AM
(: Pointer to struct withing pointer to struct :) Zero C Programming 16 11-19-2005 01:27 AM
passing pointer->struct->pointer->struct to function. .. ?? beetle C Programming 2 01-25-2005 06:08 PM
Access from function in struct (pointer to function) to other items in the struct (advanced) Ole C Programming 4 10-26-2004 09:43 PM



Advertisments