Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #58026 > unrolled thread

Is there any way to make a function local to two TUs without including it as static in both?

Back to article view | Back to comp.lang.c

Contents

  Is there any way to make a function local to two TUs without including it as static in both? DSF <notavalid@address.here> - 2015-03-09 15:02 -0400
    Re: Is there any way to make a function local to two TUs without including it as static in both? James Kuyper <jameskuyper@verizon.net> - 2015-03-09 15:22 -0400
      Re: Is there any way to make a function local to two TUs without including it as static in both? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-09 19:34 +0000
    Re: Is there any way to make a function local to two TUs without including it as static in both? Keith Thompson <kst-u@mib.org> - 2015-03-09 12:47 -0700
      Re: Is there any way to make a function local to two TUs without including it as static in both? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-09 21:33 +0000
        Re: Is there any way to make a function local to two TUs without including it as static in both? Keith Thompson <kst-u@mib.org> - 2015-03-10 07:28 -0700
          Re: Is there any way to make a function local to two TUs without including it as static in both? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-10 14:59 +0000
            Re: Is there any way to make a function local to two TUs without including it as static in both? Keith Thompson <kst-u@mib.org> - 2015-03-10 10:37 -0700
              Re: Is there any way to make a function local to two TUs without including it as static in both? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-10 18:45 +0000
    Re: Is there any way to make a function local to two TUs without including it as static in both? Lőrinczy Zsigmond <nospam@for.me> - 2015-03-09 21:04 +0100
    Re: Is there any way to make a function local to two TUs without including it as static in both? August Karlstrom <fusionfile@gmail.com> - 2015-03-09 21:39 +0100
    Re: Is there any way to make a function local to two TUs without including it as static in both? Kaz Kylheku <kaz@kylheku.com> - 2015-03-09 21:20 +0000
    Re: Is there any way to make a function local to two TUs without including it as static in both? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-09 19:23 -0500
      Re: Is there any way to make a function local to two TUs without including it as static in both? wssimms@gmail.com - 2015-03-09 21:42 -0700
        Re: Is there any way to make a function local to two TUs without including it as static in both? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-10 04:52 -0500
      Re: Is there any way to make a function local to two TUs without including it as static in both? Keith Thompson <kst-u@mib.org> - 2015-03-10 07:35 -0700
        Re: Is there any way to make a function local to two TUs without including it as static in both? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-10 12:53 -0700
    Re: Is there any way to make a function local to two TUs without including it as static in both? Les Cargill <lcargill99@comcast.com> - 2015-03-09 19:58 -0500
      Re: Is there any way to make a function local to two TUs without including it as static in both? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 13:06 -0700
        Re: Is there any way to make a function local to two TUs without including it as static in both? Les Cargill <lcargill99@comcast.com> - 2015-03-24 20:03 -0500
          Re: Is there any way to make a function local to two TUs without including it as static in both? James Kuyper <jameskuyper@verizon.net> - 2015-03-25 10:26 -0400
          Re: Is there any way to make a function local to two TUs without including it as static in both? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 10:36 -0700
            Re: Is there any way to make a function local to two TUs without including it as static in both? Kaz Kylheku <kaz@kylheku.com> - 2015-03-25 17:47 +0000
              Re: Is there any way to make a function local to two TUs without including it as static in both? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:03 -0700
        Re: Is there any way to make a function local to two TUs without including it as static in both? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 10:28 -0700
          Re: Is there any way to make a function local to two TUs without including it as static in both? Kaz Kylheku <kaz@kylheku.com> - 2015-03-25 17:46 +0000
            [OT] Re: meaning of "signature" in other languages Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:01 -0700
          Re: Is there any way to make a function local to two TUs without including it as static in both? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 09:05 -0700

Page 2 of 2 — ← Prev page 1 [2]

#58912

On 03/24/2015 09:03 PM, Les Cargill wrote:
> Tim Rentsch wrote:
...
>> In C functions don't have signatures, they have types.
>>
> 
> 
> True dat. Too bad it's not considered the same thing.

Why?
In both languages, a function's type involves the function's return type
and the number and type of it's arguments. A function's signature in C++
involves the function's namespace and the number and type of it's
arguments, but NOT the return type. "Consider[ing them] to be the same
thing" strikes me as a mistake - why do you think otherwise?

[toc] | [prev] | [next] | [standalone]

#58934

Les Cargill <lcargill99@comcast.com> writes:

> Tim Rentsch wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>>
>>> DSF wrote:
>>>> Hello!
>>>>
>>>> Is there any way to make a function local to two TUs without including
>>>> it as static in both?
>>>
>>> The *identical* function?  Or just "same name, same signature"?
>>
>> In C functions don't have signatures, they have types.
>
> True dat.  Too bad it's not considered the same thing.

I'm at a loss to know why you would say such a thing.
The two terms are not considered the same thing because
they have different meanings.  Furthermore, the word
"type" means pretty much the same thing in most programming
languages, whereas the word "signature", when a language
defines it at all, means very different things in different
languages.

[toc] | [prev] | [next] | [standalone]

#58938

On 2015-03-25, Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>
>> Tim Rentsch wrote:
>>> Les Cargill <lcargill99@comcast.com> writes:
>>>
>>>> DSF wrote:
>>>>> Hello!
>>>>>
>>>>> Is there any way to make a function local to two TUs without including
>>>>> it as static in both?
>>>>
>>>> The *identical* function?  Or just "same name, same signature"?
>>>
>>> In C functions don't have signatures, they have types.
>>
>> True dat.  Too bad it's not considered the same thing.
>
> I'm at a loss to know why you would say such a thing.

Indeed; what is the utility in making "signature" into a synonym
for "type". If you want "type", say and write "type".

Engineering documents are not judged on their esthetic variety of sentence
structure and use of synonyms.

[toc] | [prev] | [next] | [standalone]

#58980

Kaz Kylheku <kaz@kylheku.com> writes:

> On 2015-03-25, Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>>
>>> Tim Rentsch wrote:
>>>> Les Cargill <lcargill99@comcast.com> writes:
>>>>
>>>>> DSF wrote:
>>>>>> Hello!
>>>>>>
>>>>>> Is there any way to make a function local to two TUs without including
>>>>>> it as static in both?
>>>>>
>>>>> The *identical* function?  Or just "same name, same signature"?
>>>>
>>>> In C functions don't have signatures, they have types.
>>>
>>> True dat.  Too bad it's not considered the same thing.
>>
>> I'm at a loss to know why you would say such a thing.
>
> Indeed;  what is the utility in making "signature" into a synonym
> for "type".  If you want "type", say and write "type".

A rowdy "hoo rah" to that.

[toc] | [prev] | [next] | [standalone]

#58932

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> In C functions don't have signatures, they have types.
>
>   In C, a function type is characterized by its return
>   type and the number and types of its parameters.
>
>   The corresponding concept in Java is not >>signature<<,
>   but >>descriptor<< (signature plus return type).

Do you mean that Java calls a "descriptor" (in the case of
functions) what in C would be called a type?  The word
"signature" does not have a language-independent meaning.
(The word "type" means pretty much the same thing in
most languages, I believe.)

[toc] | [prev] | [next] | [standalone]

#58937

On 2015-03-25, Tim Rentsch <txr@alumni.caltech.edu> wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> In C functions don't have signatures, they have types.
>>
>>   In C, a function type is characterized by its return
>>   type and the number and types of its parameters.
>>
>>   The corresponding concept in Java is not >>signature<<,
>>   but >>descriptor<< (signature plus return type).
>
> Do you mean that Java calls a "descriptor" (in the case of
> functions) what in C would be called a type?  The word
> "signature" does not have a language-independent meaning.
> (The word "type" means pretty much the same thing in
> most languages, I believe.)

In some non-C languages, "signature" sometimes means some aspect
of the type of the funtion that is less than the complete type---usually
the type info of the argument list.

(The word for the entire type is just "type"; it would be superfluous
to use "signature" for this.)

The signature concept matters in situations like overload selection, where
argument types are considered, but not return value.

Example: C++. We may not have this overload situation:

  double foo(int, int);
  int foo(int, int);

Though the two declarations give different function types, the
signatures of those two function types are the same.

Why we may not have that overload situation is that overload resolution
is a synthesized semantic attribute: that is to say, when a function
call is resolved with regard to overloads, only its constituent expressions
are considered, and not the surrounding expression context.

So this doesn't resolve the situation:

  double x = foo(1, 2); // go to double(int, int)? Wishful thinking!
  int y = foo(3, 4);    // ditto w.r.t.  int(int, int).

Only the contents of the foo(1, 2) expression are considered
to come up with what is to be called, without regard to how the
return type fits into the surrounding context. If that were
considered, then the overload resolution would be a "synthesized
semantic attribute" (one computed from parent and sibling
nodes of the abstract syntax tree, not only bottom-up from the children).

[toc] | [prev] | [next] | [standalone]

#58978 — [OT] Re: meaning of "signature" in other languages

Kaz Kylheku <kaz@kylheku.com> writes:

> On 2015-03-25, Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> In C functions don't have signatures, they have types.
>>>
>>>   In C, a function type is characterized by its return
>>>   type and the number and types of its parameters.
>>>
>>>   The corresponding concept in Java is not >>signature<<,
>>>   but >>descriptor<< (signature plus return type).
>>
>> Do you mean that Java calls a "descriptor" (in the case of
>> functions) what in C would be called a type?  The word
>> "signature" does not have a language-independent meaning.
>> (The word "type" means pretty much the same thing in
>> most languages, I believe.)
>
> In some non-C languages, "signature" sometimes means some aspect
> of the type of the funtion that is less than the complete
> type---usually the type info of the argument list.
>
> (The word for the entire type is just "type";  it would be
> superfluous to use "signature" for this.)
>
> The signature concept matters in situations like overload
> selection, where argument types are considered, but not return
> value.
>
> Example:  C++. We may not have this overload situation:
>
>   double foo(int, int);
>   int foo(int, int);
>
> Though the two declarations give different function types, the
> signatures of those two function types are the same.  [snip
> elaboration]

My understanding is that this is not how the term "signature" is
used in the C++ standard.  (Disclaimer:  I am not by any means an
expert on C++.)  I agree that such a definition might be useful
in some circumstances, but AFAIK it is not how C++ defines the
term.  (Recognizing the topic drift I am marking this [OT]...)

[toc] | [prev] | [next] | [standalone]

#59147

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> In C functions don't have signatures, they have types.
>>>
>>> In C, a function type is characterized by its return
>>> type and the number and types of its parameters.
>>> The corresponding concept in Java is not >>signature<<,
>>> but >>descriptor<< (signature plus return type).
>>
>> Do you mean that Java calls a "descriptor" (in the case of
>> functions) what in C would be called a type?
>
>   No, what I meant was that Java calls a "descriptor" (in the
>   case of methods) what in C would be called a function type.

You're using different words but I think we are saying
the same thing (not counting the 'method' aspect, which
is incidental to my question).

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web