Pointer to function inside struct

[Tim Rentsch]

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.

 

[Tim Rentsch]

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.

Fair enough...


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.

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

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.

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

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

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.

 

[Öö Tiib]

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

 

[James Kuyper]

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?

 

[glen herrmannsfeldt]

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

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

 

[Öö Tiib]

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

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

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.

 

[88888 Dihedral]

Öö Tiibæ–¼ 2013å¹´3月22日星期五UTC+8上åˆ2時29分20秒寫é“：

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.









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.

 

[James Kuyper]

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.

 

[Öö Tiib]

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.

 

[Bart van Ingen Schenau]

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

 

[James Kuyper]

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.

It never even occurred to me that the term "signature", as used in C++,
had anything to do with the ordinary English use of the term. I didn't
see any connection, and even now that I have a more accurate
understanding of what it means, the connection seems very weak. I have
no idea how I came by my misunderstanding of what the term means in C++,
but the fact that there are so many places where my misunderstanding
fails to cause any problems probably played a key role in that process.