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

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

Forward declarations

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

Contents

  Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-10 14:20 -0800
    Re: Forward declarations jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-10 23:38 +0100
      Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-10 15:00 -0800
        Re: Forward declarations Ian Collins <ian-news@hotmail.com> - 2015-11-11 12:24 +1300
          Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-10 15:53 -0800
            Re: Forward declarations gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-11 00:01 +0000
            Re: Forward declarations Ian Collins <ian-news@hotmail.com> - 2015-11-11 13:46 +1300
              Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-10 21:05 -0800
      Re: Forward declarations BartC <bc@freeuk.com> - 2015-11-11 00:21 +0000
    Re: Forward declarations Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-11-11 10:16 +0100
      Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-11 07:19 -0800
    Re: Forward declarations David Brown <david.brown@hesbynett.no> - 2015-11-11 15:40 +0100
      Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-11 07:21 -0800
        Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-11 07:23 -0800
        Re: Forward declarations David Brown <david.brown@hesbynett.no> - 2015-11-11 16:29 +0100
          Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-11 07:31 -0800
          Re: Forward declarations Nick Bowler <nbowler@draconx.ca> - 2015-11-13 18:20 +0000
            Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-13 10:39 -0800
              Re: Forward declarations BartC <bc@freeuk.com> - 2015-11-13 19:40 +0000
            Re: Forward declarations Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-14 11:42 -0800
              Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-14 12:32 -0800
                Re: Forward declarations Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 00:15 +0000
                  Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-14 16:34 -0800
                    Re: Forward declarations Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 01:54 +0000
                      Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-14 18:00 -0800
                        Re: Forward declarations Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 02:13 +0000
                          Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-14 18:26 -0800
                            Re: Forward declarations Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 02:34 +0000
                          Re: Forward declarations BartC <bc@freeuk.com> - 2015-11-15 11:11 +0000
                Re: Forward declarations Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 02:36 +0000
                  Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-14 19:25 -0800
                  Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-14 19:37 -0800
                  Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-14 20:11 -0800
                    Re: Forward declarations Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 10:36 +0000
                      Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-15 06:16 -0800
                        Re: Forward declarations BartC <bc@freeuk.com> - 2015-11-15 14:44 +0000
                          Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-15 09:41 -0800
                            Re: Forward declarations Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 18:26 +0000
                              Re: Forward declarations BartC <bc@freeuk.com> - 2015-11-15 18:42 +0000
                                Re: Forward declarations Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 18:53 +0000
                                  Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-15 12:58 -0800
                              Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-15 12:49 -0800
                                Re: Forward declarations Ian Collins <ian-news@hotmail.com> - 2015-11-16 10:01 +1300
                        Re: Forward declarations Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 14:54 +0000
                          Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-15 09:53 -0800
                          Re: Forward declarations Keith Thompson <kst-u@mib.org> - 2015-11-15 10:36 -0800
                            Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-15 12:56 -0800
                              Re: Forward declarations Ian Collins <ian-news@hotmail.com> - 2015-11-16 10:04 +1300
                                Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-15 13:11 -0800
                                  Re: Forward declarations Ian Collins <ian-news@hotmail.com> - 2015-11-16 10:25 +1300
                                    Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-15 13:37 -0800
                Re: Forward declarations Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-15 13:13 -0800
                  Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-15 13:16 -0800
                    Re: Forward declarations David Brown <david.brown@hesbynett.no> - 2015-11-16 00:23 +0100
                      Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-15 16:20 -0800
                        Re: Forward declarations Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-16 00:47 +0000
                          Re: Forward declarations BartC <bc@freeuk.com> - 2015-11-16 01:28 +0000
                            Re: Forward declarations Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-16 01:57 +0000
                              Re: Forward declarations Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-15 21:15 -0500
                                Re: Forward declarations Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-16 11:05 +0000
                                  Re: Forward declarations Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-16 10:18 -0500
                              Re: Forward declarations Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 06:44 +0000
                              Re: Forward declarations BartC <bc@freeuk.com> - 2015-11-16 11:26 +0000
                                Re: Forward declarations David Brown <david.brown@hesbynett.no> - 2015-11-16 12:43 +0100
                                  Re: Forward declarations BartC <bc@freeuk.com> - 2015-11-16 12:20 +0000
                                    Re: Forward declarations David Brown <david.brown@hesbynett.no> - 2015-11-16 14:38 +0100
                                Re: Forward declarations Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-16 13:26 +0000
                                  Re: Forward declarations BartC <bc@freeuk.com> - 2015-11-16 13:53 +0000
                          Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-15 18:12 -0800
        Re: Forward declarations pa@see.signature.invalid (Pierre Asselin) - 2015-11-12 01:54 +0000
          Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-12 02:08 -0800
      Re: Forward declarations BartC <bc@freeuk.com> - 2015-11-12 09:58 +0000
    Re: Forward declarations John Bode <jfbode1029@gmail.com> - 2015-11-17 14:46 -0800
      Re: Forward declarations "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-17 14:59 -0800
      Re: Forward declarations BartC <bc@freeuk.com> - 2015-11-17 23:35 +0000
        Re: Forward declarations BartC <bc@freeuk.com> - 2015-11-17 23:40 +0000
          Re: Forward declarations Keith Thompson <kst-u@mib.org> - 2015-11-17 19:48 -0800
        Re: Forward declarations glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 01:04 +0000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#76119

On Sunday, November 15, 2015 at 1:53:18 PM UTC-5, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
> 
> > On 15/11/2015 18:26, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >>
> >
> >>> You can do that in terms of general variable creation, but not in
> >>> terms of a function parameter declaration.
> >>
> >> C does not have function parameters.  The example had a pointer
> >> parameter.
> >>
> >>> In the case of function
> >>> parameter declaration, be it in the prototype or the function body,
> >>> the declaration is always there, and always provides the declaration,
> >>> and, provided the function is called, it is also always defined in
> >>> usage (as by the passed value).
> >>
> >> Nonsense.  In the case of an object, be it in the prototype or the
> >> function body, the declaration is always there, and always provides the
> >> declaration, and, provided the function is called, it is also always
> >> defined in usage (as by the passed value).  You are trying to invent a
> >> distinction between function pointers and other kinds of object that is
> >> simply not there.
> >
> > There is a subtle difference. A properly written declaration for a
> > function pointer would need to specify the function signature: the
> > parameter types and return type.
> 
> That's not subtle.  Function pointer declarations are different to other
> declarations in significant ways.  They are just not different in the
> way that Rick would like then to be.

They, by their very form and nature, beg to differ with you.  'Tis not I
differing with you, Mr. Ben, but they.

> > But the function signature is already most of the information that
> > would be in a forward declaration and that is necessary for the
> > function to be correctly called. All that's missing is the name of the
> > function.
> 
> A pointer to int has even more -- it contains *all* the information for
> the int to be used.  All that's missing is the int it points to.

I get the impression from your responses that you're just being difficult.
I hope I'm wrong about that, but it seems to be the case.  If it is the
case, I forgive you.  And if not, I still forgive you.

Best regards,
Rick C. Hodgin

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

#76116

On Sunday, November 15, 2015 at 1:27:09 PM UTC-5, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Sunday, November 15, 2015 at 9:45:00 AM UTC-5, Bart wrote:
> >> On 15/11/2015 14:16, Rick C. Hodgin wrote:
> >> > On Sunday, November 15, 2015 at 5:36:27 AM UTC-5, Ben Bacarisse wrote:
> >> 
> >> >> That does not answer the first question about which function is declared
> >> >> twice.
> >> >
> >> > It does.  A function pointer cannot be declared without declaring the
> >> > existence of /A/ function.
> >> 
> >> That's not true. You can declare a function pointer without it being 
> >> initialised or tied to any actual functions.
> >
> > You can do that in terms of general variable creation, but not in
> > terms of a function parameter declaration.
> 
> C does not have function parameters.  The example had a pointer
> parameter.

When I say function parameters, I mean the components like the "int argc,
char* argv[]" of main().

> > In the case of function
> > parameter declaration, be it in the prototype or the function body,
> > the declaration is always there, and always provides the declaration,
> > and, provided the function is called, it is also always defined in
> > usage (as by the passed value).
> 
> Nonsense.  In the case of an object, be it in the prototype or the
> function body, the declaration is always there, and always provides the
> declaration, and, provided the function is called, it is also always
> defined in usage (as by the passed value).  You are trying to invent a
> distinction between function pointers and other kinds of object that is
> simply not there.

The function declaration in the function parameters does define a
function.  It goes a step further than merely conveying something like
an int*.  It actually prototypes the function for use in any subsequent
use, as for syntax checking by the compiler.  It is doing more work than
other types of pointers, and that's why I make the distinction.

I really don't care to argue over it, Ben.  If you believe you're correct
then I'm content to say, "Okay, my mistake," and then to simply move on
secure in the knowledge that what I said is correct regardless of what
you might say to the contrary. :-)

Best regards,
Rick C. Hodgin

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

#76121

Rick C. Hodgin wrote:
>
> The function declaration in the function parameters does define a
> function.

No, it specifies a function pointer parameter.

> It goes a step further than merely conveying something like
> an int*.  It actually prototypes the function for use in any subsequent
> use, as for syntax checking by the compiler.

No, it specifies that the parameter is a function pointer.

> It is doing more work than
> other types of pointers, and that's why I make the distinction.

How so?

Is

typedef int (*Fn)( int );

void g() {}

void f( Fn fn )
{
   fn = g;;
}

any less or more of an error than

void f1( int* p )
{
   p = g;
}

?
-- 
Ian Collins

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

#76095

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Sunday, November 15, 2015 at 5:36:27 AM UTC-5, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> 
>> > On Saturday, November 14, 2015 at 9:36:29 PM UTC-5, Ben Bacarisse wrote:
>> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> >> 
>> >> > On Saturday, November 14, 2015 at 2:50:19 PM UTC-5, Tim Rentsch wrote:
>> >> >> Nick Bowler <nbowler@draconx.ca> writes:
>> >> >> 
>> >> >> > It is currently impossible in C to write mutually recursive
>> >> >> > functions without declaring at least one of the functions twice.
>> >> >> 
>> >> >> I wouldn't bet money on that if I were you -
>> >> >> 
>> >> >>     int
>> >> >>01:  foo( char *s, int n, int ferrah() ){
>> >> >>         if(  *s == ' '  )  return  foo( s+1, n, ferrah );
>> >> >>         return  ferrah( s, n+1 );
>> >> >>     }
>> >> >> 
>> >> >>02:  int
>> >> >>     bas( char *s, int n ){
>> >> >>         if(  *s == 0  )  return  n;
>> >> >>         if(  *s != ' '  )  return  bas( s+1, n );
>> >> >>         return  foo( s, n, bas );
>> >> >>     }
>> >> >
>> >> > Technically, you did declared it twice,
>> >> 
>> >> Being more direct this time...  What function is declared twice in that
>> >> code?  Where are the two declarations?  You marked lines but the lines
>> >> are for declarations of two different functions so I need you to say
>> >> exactly where you see the second declaration.
>> >
>> > My serious answer:  I showed the 01: and 02: lines.  They contain
>> > the definitions.
>> 
>> That does not answer the first question about which function is declared
>> twice.
>
> It does.  A function pointer cannot be declared without declaring the
> existence of /A/ function.  In this case the function declaration was
> partial, and dangerous, but it was a function declaration indicating
> that a function would be referenced through ferrah.

That's not a function declaration -- It's the declaration of a pointer.
But even if it were of function type, it's a parameter -- a new "thing"
(instantiated on every call) not a second declaration of something
else.  (I have to say "thing", because C does not have function objects
or function values so there is no terminology to talk about functions as
parameters.)

That, by the way, was the point of my example with an int.  Declaring an
int parameter does mean the existing int has been declared twice.  You
only wanted to joke about that, but there was a point to it.

<snip>
>> > One is a function parameter declaration of a
>> > function.  The other is a function body declaration.
>> 
>> No, the code contains contains two function declarations, two char
>> pointer declarations, an int declaration and a function pointer
>> declaration.
>
> How does one declare a function pointer declaration without declaring
> a function, or casting it into the role of a function, albeit in this
> instance in a more limited scope than a true function declaration?

No one in claiming that the function whose address will be passed is not
declared.  You asserted that some function is declared *twice* -- that's
the error.  There are only two function declarations and two functions,
so there is one declaration each.

>> There are only two functions in total, and two function
>> declarations in total.  No function is declared twice.
>
> I'm sure you see my point:

Yes, of course.  How could I know it's wrong if I did not see what you
are saying?

> [...] three functions are referenced. Two
> function declarations, one function declaration within the parameter
> list of one of those two,

No, there is no function declaration in the parameter list.  Perhaps you
don't know that the declaration is of a pointer type?  But even if C
actually had function parameters, you'd still be wrong -- a function
parameter declares something new; it is never a second declaration of
something already declared.

> indicating the existence of another
> function, one which MAY be one of the original two, but doesn't
> have to be, but in Tim's case is.

You didn't say "there's a pointer to an already declared function" you
said (or implied by not accepting the counter-example) that at least one
function had to be declared twice.

In summary:

1. The parameter is not a function.  The declaration is of "pointer to
function" type.  A declaration of something of type T *, can never be a
declaration of something of type T.

2. A declared parameter is not a second declaration of anything, no
matter what value is eventually passed to the function.  A parameter
declaration is of a new object with automatic lifetime and never a
second declaration of something else.

-- 
Ben.

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

#76097

On Sunday, November 15, 2015 at 9:54:51 AM UTC-5, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Sunday, November 15, 2015 at 5:36:27 AM UTC-5, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> 
> >> > On Saturday, November 14, 2015 at 9:36:29 PM UTC-5, Ben Bacarisse wrote:
> >> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> >> 
> >> >> > On Saturday, November 14, 2015 at 2:50:19 PM UTC-5, Tim Rentsch wrote:
> >> >> >> Nick Bowler <nbowler@draconx.ca> writes:
> >> >> >> 
> >> >> >> > It is currently impossible in C to write mutually recursive
> >> >> >> > functions without declaring at least one of the functions twice.
> >> >> >> 
> >> >> >> I wouldn't bet money on that if I were you -
> >> >> >> 
> >> >> >>     int
> >> >> >>01:  foo( char *s, int n, int ferrah() ){
> >> >> >>         if(  *s == ' '  )  return  foo( s+1, n, ferrah );
> >> >> >>         return  ferrah( s, n+1 );
> >> >> >>     }
> >> >> >> 
> >> >> >>02:  int
> >> >> >>     bas( char *s, int n ){
> >> >> >>         if(  *s == 0  )  return  n;
> >> >> >>         if(  *s != ' '  )  return  bas( s+1, n );
> >> >> >>         return  foo( s, n, bas );
> >> >> >>     }
> >> >> >
> >> >> > Technically, you did declared it twice,
> >> >> 
> >> >> Being more direct this time...  What function is declared twice in that
> >> >> code?  Where are the two declarations?  You marked lines but the lines
> >> >> are for declarations of two different functions so I need you to say
> >> >> exactly where you see the second declaration.
> >> >
> >> > My serious answer:  I showed the 01: and 02: lines.  They contain
> >> > the definitions.
> >> 
> >> That does not answer the first question about which function is declared
> >> twice.
> >
> > It does.  A function pointer cannot be declared without declaring the
> > existence of /A/ function.  In this case the function declaration was
> > partial, and dangerous, but it was a function declaration indicating
> > that a function would be referenced through ferrah.
> 
> That's not a function declaration -- It's the declaration of a pointer.

Okay.  My mistake.

Best regards,
Rick C. Hodgin

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

#76100

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> That's not a function declaration -- It's the declaration of a pointer.
> But even if it were of function type, it's a parameter -- a new "thing"
> (instantiated on every call) not a second declaration of something
> else.  (I have to say "thing", because C does not have function objects
> or function values so there is no terminology to talk about functions as
> parameters.)
[...]

As you say, C does not have parameters of function type.  If it did,
since all arguments are passed by value, it would have to be possible to
pass a function value in a call.  It's very difficult to say what that
would mean unless you made some major changes to C semantics.


-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#76118

On Sunday, November 15, 2015 at 1:37:09 PM UTC-5, Keith Thompson wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
> > That's not a function declaration -- It's the declaration of a pointer.
> > But even if it were of function type, it's a parameter -- a new "thing"
> > (instantiated on every call) not a second declaration of something
> > else.  (I have to say "thing", because C does not have function objects
> > or function values so there is no terminology to talk about functions as
> > parameters.)
> [...]
> 
> As you say, C does not have parameters of function type.

Whatever you call them "in C speak," this is what I mean (line 03):

01:    #include <stdio.h>
02:
03:    int foo(char *s, int n, int ferrah(char* s, int n))
04:    {
05:        if (*s == ' ')        return(foo(s+1, n, ferrah));
06:        else                  return(ferrah(s+1, n));
07:    }
08:
09:    int bas(char *s, int n)
10:    {
11:             if (*s == 0)     return(n);
12:        else if (*s != ' ')   return(bas(s+1, n));
13:        else                  return(foo(s, n, bas));
14:    } 
15:
16:    int main(int argc, char* argv[])
17:    {
18:        printf("%d\n", bas("Rick test", 0));
19:    }

I am referring to this part specifically:

    int foo(char *s, int n, int ferrah(char* s, int n))
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^
Here we see:

    int ferrah(char* s, int n)

Except for that fact that it doesn't have a trailing semicolon, it
is a function declaration.  It defines the return type, the name,
the parameters, and it is available for use within the function,
albeit as a function pointer, but that is an internal issue and
not an external one.

> If it did,
> since all arguments are passed by value, it would have to be possible to
> pass a function value in a call.  It's very difficult to say what that
> would mean unless you made some major changes to C semantics.

I wish I wasn't in your killfile on this group.  It would be nice
to hear your response on this.

Best regards,
Rick C. Hodgin

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

#76122

Rick C. Hodgin wrote:
>
> I am referring to this part specifically:
>
>      int foo(char *s, int n, int ferrah(char* s, int n))
>                              ^^^^^^^^^^^^^^^^^^^^^^^^^^
> Here we see:
>
>      int ferrah(char* s, int n)
>
> Except for that fact that it doesn't have a trailing semicolon, it
> is a function declaration.  It defines the return type, the name,
> the parameters, and it is available for use within the function,
> albeit as a function pointer, but that is an internal issue and
> not an external one.

No, it'd a function pointer.  Would you say the same id the code were 
written:

typedef int (*Fn)(char*, int);

int foo(char *s, int n, Fn ferrah )

?
-- 
Ian Collins

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

#76123

On Sunday, November 15, 2015 at 4:04:46 PM UTC-5, Ian Collins wrote:
> Rick C. Hodgin wrote:
> >
> > I am referring to this part specifically:
> >
> >      int foo(char *s, int n, int ferrah(char* s, int n))
> >                              ^^^^^^^^^^^^^^^^^^^^^^^^^^
> > Here we see:
> >
> >      int ferrah(char* s, int n)
> >
> > Except for that fact that it doesn't have a trailing semicolon, it
> > is a function declaration.  It defines the return type, the name,
> > the parameters, and it is available for use within the function,
> > albeit as a function pointer, but that is an internal issue and
> > not an external one.
> 
> No, it'd a function pointer.  Would you say the same id the code were 
> written:
> 
> typedef int (*Fn)(char*, int);
> 
> int foo(char *s, int n, Fn ferrah )
> 
> ?

No.  In this case the function definition is given on the typedef line.
In the case of Tim's example, expanded in my example above with the full
parameter listing, that is the function declaration.

Concept-wise, there is a new function being declared.  It is accessible
through the named parameter variable, but its existence, its form, its
signature, everything about it is declared there in the function parameter
declaration.

It's a very simple concept.  I'm at a loss how you make the distinction
to say that a function pointer is being declared because, while that is
true, the function pointer points to something ... and what does it point
to?  That's right!  A function declaration, which conveys the target then
of the independent component, which is the address conveyed through the
pointer.

I don't know how much experience you have on x86 OS programming, Ian, or
Ben, but on the x86 there is something called a segment selector.  It is
a value that is loaded by a user app (though typically the OS), to point
to a block of memory.  Behind the scenes that selector backs into a whole
slew of information, which conveys far more than just the value being
used for the selector.  The selector is only one component of a much more
complex system at work.  That is basically what is happening here with
these function pointer declarations which, by their existence, also declare
a function form and signature.  By the fact that they convey the indicated
syntax, they are declaring a function.

It's elementary, dear Ian.

Best regards,
Rick C Hodgin

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

#76127

Rick C. Hodgin wrote:
> On Sunday, November 15, 2015 at 4:04:46 PM UTC-5, Ian Collins wrote:
>> Rick C. Hodgin wrote:
>>>
>>> I am referring to this part specifically:
>>>
>>>       int foo(char *s, int n, int ferrah(char* s, int n))
>>>                               ^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> Here we see:
>>>
>>>       int ferrah(char* s, int n)
>>>
>>> Except for that fact that it doesn't have a trailing semicolon, it
>>> is a function declaration.  It defines the return type, the name,
>>> the parameters, and it is available for use within the function,
>>> albeit as a function pointer, but that is an internal issue and
>>> not an external one.
>>
>> No, it'd a function pointer.  Would you say the same id the code were
>> written:
>>
>> typedef int (*Fn)(char*, int);
>>
>> int foo(char *s, int n, Fn ferrah )
>>
>> ?
>
> No.  In this case the function definition is given on the typedef line.

There isn't a function definition.  The typedef creates an alias to a 
function pointer type.

> In the case of Tim's example, expanded in my example above with the full
> parameter listing, that is the function declaration.

No it isn't, it is just a function pointer parameter.

A function pointer is a type, just like int* is a type.

> Concept-wise, there is a new function being declared.  It is accessible
> through the named parameter variable, but its existence, its form, its
> signature, everything about it is declared there in the function parameter
> declaration.

Only it isn't.

> It's a very simple concept.  I'm at a loss how you make the distinction
> to say that a function pointer is being declared because, while that is
> true, the function pointer points to something ... and what does it point
> to?  That's right!  A function declaration, which conveys the target then
> of the independent component, which is the address conveyed through the
> pointer.

A function pointer (just like any other pointer type) doesn't have to 
point to anything.  It is type.  A function pointer can point to any 
function with the correct signature, so how can it specify a *specific* 
function declaration?  It can't, any more than an int pointer declares a 
*specific* int.

> I don't know how much experience you have on x86 OS programming, Ian, or
> Ben, but on the x86 there is something called a segment selector.

In my case, decades....

-- 
Ian Collins

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

#76128

On Sunday, November 15, 2015 at 4:25:33 PM UTC-5, Ian Collins wrote:
> Rick C. Hodgin wrote:
> > I don't know how much experience you have on x86 OS programming, Ian, or
> > Ben, but on the x86 there is something called a segment selector.
> 
> In my case, decades....

Then you clearly understand my point, which is why you had no response to
it, and why you deleted the text from your response.  Selectors are values,
but what they relate to is far more than a value, just like function
pointer declarations.  Sure they are function pointers, but they are not
only function pointers, they back into a function prototype declaration,
and that's just the way it is.

Again, I am convinced you and Ben are just being difficult.  This concept
is so obvious.  Even a young child with no former knowledge or experience
could understand it with six minutes of explanation.

Best regards,
Rick C. Hodgin

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

#76124

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Saturday, November 14, 2015 at 2:50:19 PM UTC-5, Tim Rentsch wrote:
>> Nick Bowler <nbowler@draconx.ca> writes:
>>
>>> It is currently impossible in C to write mutually recursive
>>> functions without declaring at least one of the functions twice.
>>
>> I wouldn't bet money on that if I were you -
>>
>>     int
>>     foo( char *s, int n, int ferrah() ){
>>         if(  *s == ' '  )  return  foo( s+1, n, ferrah );
>>         return  ferrah( s, n+1 );
>>     }
>>
>>     int
>>     bas( char *s, int n ){
>>         if(  *s == 0  )  return  n;
>>         if(  *s != ' '  )  return  bas( s+1, n );
>>         return  foo( s, n, bas );
>>     }
>
> Technically, you did declared it twice, [snip elaboration]

Each identifier in the program is declared exactly once.  The
identifier 'ferrah' is declared as a parameter as part of the
declaration (which also has an associated definition) for the
function foo().  The identifier 'bas' is declared (and defined)
as a function, and is independent of the function foo() and any
of its parameters (ie, in its declaration;  the body of bas()
refers to foo(), but that doesn't affect the declaration of the
identifier 'bas').  The declarations of 'ferrah' and 'bas' give
distinct identifier names, and so cannot be declaring the same
identifier.  The identifier names 's' and 'n' are used to declare
two identifiers each, one a parameter of foo() and the other a
parameter of bas(), but even though the names are the same there
are (for each name) two different identifiers, with each
identifier having only one declaration.

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

#76125

On Sunday, November 15, 2015 at 4:13:33 PM UTC-5, Tim Rentsch wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Saturday, November 14, 2015 at 2:50:19 PM UTC-5, Tim Rentsch wrote:
> >> Nick Bowler <nbowler@draconx.ca> writes:
> >>
> >>> It is currently impossible in C to write mutually recursive
> >>> functions without declaring at least one of the functions twice.
> >>
> >> I wouldn't bet money on that if I were you -
> >>
> >>     int
> >>     foo( char *s, int n, int ferrah() ){
> >>         if(  *s == ' '  )  return  foo( s+1, n, ferrah );
> >>         return  ferrah( s, n+1 );
> >>     }
> >>
> >>     int
> >>     bas( char *s, int n ){
> >>         if(  *s == 0  )  return  n;
> >>         if(  *s != ' '  )  return  bas( s+1, n );
> >>         return  foo( s, n, bas );
> >>     }
> >
> > Technically, you did declared it twice, [snip elaboration]
> 
> Each identifier in the program is declared exactly once.  The
> identifier 'ferrah' is declared as a parameter as part of the
> declaration (which also has an associated definition) for the
> function foo().  The identifier 'bas' is declared (and defined)
> as a function, and is independent of the function foo() and any
> of its parameters (ie, in its declaration;  the body of bas()
> refers to foo(), but that doesn't affect the declaration of the
> identifier 'bas').  The declarations of 'ferrah' and 'bas' give
> distinct identifier names, and so cannot be declaring the same
> identifier.  The identifier names 's' and 'n' are used to declare
> two identifiers each, one a parameter of foo() and the other a
> parameter of bas(), but even though the names are the same there
> are (for each name) two different identifiers, with each
> identifier having only one declaration.

Yeah.  There's a whole movement in comp.lang.c saying what you're saying
here, Tim.  We're at an impasse.  As such, I'm content to just walk away
from the discussion knowing I'm right. :-)

Best regards,
Rick C. Hodgin

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

#76140

On 15/11/15 22:16, Rick C. Hodgin wrote:

> Yeah.  There's a whole movement in comp.lang.c saying what you're saying
> here, Tim.  We're at an impasse.  As such, I'm content to just walk away
> from the discussion knowing I'm right. :-)
>

I don't always agree with everything said by some of the regulars in 
c.l.c., but I know that if four of the most serious "heavyweights" here 
(Keith, Ben, Ian and Tim) all disagree with someone, that someone is 
likely to be wrong.

If you were a little more humble, this would be your chance to learn 
something rather than a chance to convince any doubters that you lack 
detailed C knowledge.

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

#76142

On Sunday, November 15, 2015 at 6:23:52 PM UTC-5, David Brown wrote:
> On 15/11/15 22:16, Rick C. Hodgin wrote:
> 
> > Yeah.  There's a whole movement in comp.lang.c saying what you're saying
> > here, Tim.  We're at an impasse.  As such, I'm content to just walk away
> > from the discussion knowing I'm right. :-)
> >
> 
> I don't always agree with everything said by some of the regulars in 
> c.l.c., but I know that if four of the most serious "heavyweights" here 
> (Keith, Ben, Ian and Tim) all disagree with someone, that someone is 
> likely to be wrong.
> 
> If you were a little more humble, this would be your chance to learn 
> something rather than a chance to convince any doubters that you lack 
> detailed C knowledge.

I believe I am humble.  But also, in this particular case, I happen
to be right.

Every person could figure this out for themselves.  Envision yourself
writing a compiler.  The function prototype declaration which comes
through function parameters, as in Tim's example, has to be parsed
and recorded within the compiler.  The parsing and recording of that
information process is am explicit function declaration.  It records
the return type, the name, and the parameter inputs.  It is the one
later used when the named token is found in code which, depending on
how it's used, can be conveyed by mere pointer value, or can be used
as a function pointer, relating then back to the prototype definition
it parsed in the function parameters, used then by the compiler at
compile time to determine how to set things up, to syntax check the
parameters, the parameter count, return type mating, etc.

Once the binary is written, of course it's just a function pointer
from that point.  But the whole point of having the definition in
the first place is to instruct the compiler on how to handle that
data.  And in the case of a function pointer like this, it HAS to
ALWAYS be also a function declaration, because the form and signature
used in the function parameters (ferrah() in Tim's example) may or
may not actually exist elsewhere in the program.  But regardles of
whether or not it actually exists elsewhere, the instance encountered
in the function parameters as a function declaration is a unique and
self-contained entity, one which, if it's conveyed as Tim did, has
all the necessary definition to identify the function found only there
within that which was parsed only there.

As such, it is a full function declaration, just one which happens to be
used through the mechanics of indirection as by the function's address
being passed, but one which also references completely the full range of
information conveyed in the function declaration as by its form and
signature in the function parameters.

-----
I'm perfectly content to be wrong when I'm wrong.  A few days ago Ben
suggested I should use an array rather than the method I was using,
and he was right.  I was wrong in my pursuit of that path, and I changed
my program and converted everything to use arrays after that message:

    https://github.com/RickCHodgin/libsf/commit/ebe8abe0567d1c746fe7edb8dbc92d00462ce513

In this case though, it's not a matter of not being humble.  It's a
simple matter of me not being wrong.  A function declaration /was/ given
in Tim's example.  It happened to be incomplete and prone to error,
but it /was/ a function declaration nonetheless.  And in the case of
Nick's comment that you could not write mutually recursive functions
without having at least one function declared twice, was right.  Even
in Tim's example the declaration is there ... it just happened to be
in a cheap disguise.

Best regards,
Rick C. Hodgin

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

#76143

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Sunday, November 15, 2015 at 6:23:52 PM UTC-5, David Brown wrote:
>> On 15/11/15 22:16, Rick C. Hodgin wrote:
>> 
>> > Yeah.  There's a whole movement in comp.lang.c saying what you're saying
>> > here, Tim.  We're at an impasse.  As such, I'm content to just walk away
>> > from the discussion knowing I'm right. :-)

That would be good by you seem to be reluctant to do the walking away
part.

<snip>
>> If you were a little more humble, this would be your chance to learn 
>> something rather than a chance to convince any doubters that you lack 
>> detailed C knowledge.
>
> I believe I am humble.  But also, in this particular case, I happen
> to be right.

And yet you still haven't answered by question about which function is
declared twice.  The example included only two and you agreed that at
least one much be declared twice so there are only two answers: foo or
bar.  I'd like to be charitable and assume that you are a bit confused
about what constitutes the declaration of a function, but your not
answering this question suggests otherwise.  It suggests to me that you
don't want to say because it would be so obviously false.

> Every person could figure this out for themselves.

That's the good part.  I don't think many people reading this will come
away thinking that the pointer parameter declaration is a second
declaration for either "foo" or "bar".  After all there were two
functions and only two function declarations in the whole code example.

<snip>
-- 
Ben.

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

#76149

On 16/11/2015 00:47, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

>>
>> I believe I am humble.  But also, in this particular case, I happen
>> to be right.
>
> And yet you still haven't answered by question about which function is
> declared twice.  The example included only two and you agreed that at
> least one much be declared twice so there are only two answers: foo or
> bar.  I'd like to be charitable and assume that you are a bit confused
> about what constitutes the declaration of a function, but your not
> answering this question suggests otherwise.  It suggests to me that you
> don't want to say because it would be so obviously false.
>
>> Every person could figure this out for themselves.
>
> That's the good part.  I don't think many people reading this will come
> away thinking that the pointer parameter declaration is a second
> declaration for either "foo" or "bar".  After all there were two
> functions and only two function declarations in the whole code example.

Well I think this solution is unacceptable.

For foo() to call bas() later in the module, the compiler needs certain 
information about how to call it.

If a function pointer is used as here, then that would normally provide 
most of that information. But in Tim's example, that is incomplete, so 
some of that information has to be gleaned from the nature of the call: 
the type and number of the arguments. These have to be provided /before/ 
the definition of the bas.

The only thing not known is the function address, so only an indirect 
call can be made. A direct call would need a forward declaration (unless 
you create some hairy self-modifying code).

The other unsatisfactory thing is that with the incomplete function 
pointer, you can pass anything you like to the function pointer, and the 
compiler doesn't care. But you can also do this:

  struct (int x,y,z;} pt;

   ferrah(s,n);
   ferrah(pt,pt,pt,pt,pt,pt,pt,pt,pt,pt,pt);

and it's perfectly fine! (Another crazy quirk of the language I guess.)

The same technique can be used like this:

int (*fooptr)();
int (*basptr)();

..... foo/bas define here

  fooptr=foo;
  basptr=bas;

Then foo and bas call each other via the pointers; that keeps the 
parameter passing cleaner. Notice however, that to make this work, it is 
those function pointers that now become the forward declarations. foo 
will always need to know something about bas.

(I can appreciate now the advantage of not bothering with parameter 
types for int (*fooptr)() if you can't remember the syntax! But why 
doesn't 'int ferrah()' need the "*" pointer thingy; another quirk?)

-- 
Bartc









-- 
Bartc

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

#76150

BartC <bc@freeuk.com> writes:

> On 16/11/2015 00:47, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>
>>>
>>> I believe I am humble.  But also, in this particular case, I happen
>>> to be right.
>>
>> And yet you still haven't answered by question about which function is
>> declared twice.  The example included only two and you agreed that at
>> least one much be declared twice so there are only two answers: foo or
>> bar.  I'd like to be charitable and assume that you are a bit confused
>> about what constitutes the declaration of a function, but your not
>> answering this question suggests otherwise.  It suggests to me that you
>> don't want to say because it would be so obviously false.
>>
>>> Every person could figure this out for themselves.
>>
>> That's the good part.  I don't think many people reading this will come
>> away thinking that the pointer parameter declaration is a second
>> declaration for either "foo" or "bar".  After all there were two
>> functions and only two function declarations in the whole code example.
>
> Well I think this solution is unacceptable.

That is your right.  What you accept, in this unqualified sense, is up
to you.  Had you said "I don't accept that both functions are declared
exactly once" you would have made a statement of fact (an incorrect
one).

> For foo() to call bas() later in the module, the compiler needs
> certain information about how to call it.
>
> If a function pointer is used as here, then that would normally
> provide most of that information. But in Tim's example, that is
> incomplete,

Deliberately so, I feel sure.

> so some of that information has to be gleaned from the
> nature of the call: the type and number of the arguments. These have
> to be provided /before/ the definition of the bas.
>
> The only thing not known is the function address, so only an indirect
> call can be made. A direct call would need a forward declaration
> (unless you create some hairy self-modifying code).

So you agree that there is no declaration of bar before the indirect
function call.  In fact, you agree that both foo and bar are declared
exactly once.  Would you point that out to Rick, please?  He seems to
take what you say as reliable and trustworthy.

> The other unsatisfactory thing [...]

I don't think anyone is claiming it's an example of a style to copy.

<snip>
-- 
Ben.

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

#76152

On 11/15/2015 8:57 PM, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 16/11/2015 00:47, Ben Bacarisse wrote:
>>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>
>>>>
>>>> I believe I am humble.  But also, in this particular case, I happen
>>>> to be right.
>>>
>>> And yet you still haven't answered by question about which function is
>>> declared twice.  The example included only two and you agreed that at
>>> least one much be declared twice so there are only two answers: foo or
>>> bar.  I'd like to be charitable and assume that you are a bit confused
>>> about what constitutes the declaration of a function, but your not
>>> answering this question suggests otherwise.  It suggests to me that you
>>> don't want to say because it would be so obviously false.
>>>
>>>> Every person could figure this out for themselves.
>>>
>>> That's the good part.  I don't think many people reading this will come
>>> away thinking that the pointer parameter declaration is a second
>>> declaration for either "foo" or "bar".  After all there were two
>>> functions and only two function declarations in the whole code example.
>>
>> Well I think this solution is unacceptable.
>
> That is your right.  What you accept, in this unqualified sense, is up
> to you.  Had you said "I don't accept that both functions are declared
> exactly once" you would have made a statement of fact (an incorrect
> one).
>
>> For foo() to call bas() later in the module, the compiler needs
>> certain information about how to call it.
>>
>> If a function pointer is used as here, then that would normally
>> provide most of that information. But in Tim's example, that is
>> incomplete,
>
> Deliberately so, I feel sure.
>
>> so some of that information has to be gleaned from the
>> nature of the call: the type and number of the arguments. These have
>> to be provided /before/ the definition of the bas.
>>
>> The only thing not known is the function address, so only an indirect
>> call can be made. A direct call would need a forward declaration
>> (unless you create some hairy self-modifying code).
>
> So you agree that there is no declaration of bar before the indirect
> function call.  In fact, you agree that both foo and bar are declared
> exactly once.  Would you point that out to Rick, please?  He seems to
> take what you say as reliable and trustworthy.
>
>> The other unsatisfactory thing [...]
>
> I don't think anyone is claiming it's an example of a style to copy.

     Hmm: How many functions does
	
	void qsort(void*, size_t, size_t,
	    int(*)(const void*,const void*));

declare?

     (My answer: "One.")

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#76172

Eric Sosman <esosman@comcast-dot-net.invalid> writes:

> On 11/15/2015 8:57 PM, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 16/11/2015 00:47, Ben Bacarisse wrote:
>>>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>>
>>>>>
>>>>> I believe I am humble.  But also, in this particular case, I happen
>>>>> to be right.
>>>>
>>>> And yet you still haven't answered by question about which function is
>>>> declared twice.  The example included only two and you agreed that at
>>>> least one much be declared twice so there are only two answers: foo or
>>>> bar.  I'd like to be charitable and assume that you are a bit confused
>>>> about what constitutes the declaration of a function, but your not
>>>> answering this question suggests otherwise.  It suggests to me that you
>>>> don't want to say because it would be so obviously false.
>>>>
>>>>> Every person could figure this out for themselves.
>>>>
>>>> That's the good part.  I don't think many people reading this will come
>>>> away thinking that the pointer parameter declaration is a second
>>>> declaration for either "foo" or "bar".  After all there were two
>>>> functions and only two function declarations in the whole code example.
>>>
>>> Well I think this solution is unacceptable.
>>
>> That is your right.  What you accept, in this unqualified sense, is up
>> to you.  Had you said "I don't accept that both functions are declared
>> exactly once" you would have made a statement of fact (an incorrect
>> one).
>>
>>> For foo() to call bas() later in the module, the compiler needs
>>> certain information about how to call it.
>>>
>>> If a function pointer is used as here, then that would normally
>>> provide most of that information. But in Tim's example, that is
>>> incomplete,
>>
>> Deliberately so, I feel sure.
>>
>>> so some of that information has to be gleaned from the
>>> nature of the call: the type and number of the arguments. These have
>>> to be provided /before/ the definition of the bas.
>>>
>>> The only thing not known is the function address, so only an indirect
>>> call can be made. A direct call would need a forward declaration
>>> (unless you create some hairy self-modifying code).
>>
>> So you agree that there is no declaration of bar before the indirect
>> function call.  In fact, you agree that both foo and bar are declared
>> exactly once.  Would you point that out to Rick, please?  He seems to
>> take what you say as reliable and trustworthy.
>>
>>> The other unsatisfactory thing [...]
>>
>> I don't think anyone is claiming it's an example of a style to copy.
>
>     Hmm: How many functions does
> 	
> 	void qsort(void*, size_t, size_t,
> 	    int(*)(const void*,const void*));
>
> declare?
>
>     (My answer: "One.")

Mine too.  Did you take my "not a style to copy" as suggesting that
function pointers should not be used?  I meant only that they should not
be used simply to avoid a forward declaration.

-- 
Ben.

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web