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 4 of 4 — ← Prev page 1 2 3 [4]

#76184

On 11/16/2015 6:05 AM, Ben Bacarisse wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>> [...]
>>      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.

     Oops!  Sorry: I meant to respond not to you, but to someone
you quoted.  He maintains that mentioning a function pointer as
a parameter in a function declaration automatically declares the
pointed-to function.  The /reductio ad absurdum/ is that the qsort()
declaration, by his reasoning, declares both qsort() and an infinite
number of comparator functions.

     Actually, they don't even need to be comparators: They just
need to take two `const void*' arguments and return an `int'.  If
you ever want to write such a function, for any purpose whatever,
there's no need to declare it if a qsort() declaration is visible!
And then there's `void atexit(void (*)(void))', which automatically
declares all no-argument no-value functions -- how convenient!

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

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

#76160

On 16/11/15 01:57, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
<snip>

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

Had he said that, he would have been making a *correct* statement of 
fact. It's like saying "I don't believe that Neil Armstrong landed on 
the moon". The statement itself is correct (or at least we have no way 
of telling that it isn't), even though the scepticism it describes is 
misplaced.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#76174

On 16/11/2015 01:57, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 16/11/2015 00:47, Ben Bacarisse wrote:

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

Yes, there are only two conventional function definitions. I think I 
said that in my first post in the sub-thread.

But look at the subject line: it's about forward declarations. In my 
view, specifying a function pointer and telling the compiler how it 
ought to be called, constitutes most of a forward declaration.

Because C still requires that. (My own language doesn't work the same 
way. The sole source of information as to how bas ought be called, comes 
from its definition. That is used to double-check the call to it in foo, 
when they are written without function pointers.)

>> The other unsatisfactory thing [...]
>
> I don't think anyone is claiming it's an example of a style to copy.

OK, so a more acceptable style would need forward declarations. The OP 
is saying that oughtn't be necessary. And I'm sure he meant being able 
to just leave them out without then having to rewrite the code in a 
convoluted and unsafe manner.

-- 
Bartc

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

#76177

On 16/11/15 12:26, BartC wrote:
> On 16/11/2015 01:57, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 16/11/2015 00:47, Ben Bacarisse wrote:
> 
>>>> 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).
> 
> Yes, there are only two conventional function definitions. I think I
> said that in my first post in the sub-thread.
> 
> But look at the subject line: it's about forward declarations. In my
> view, specifying a function pointer and telling the compiler how it
> ought to be called, constitutes most of a forward declaration.

Then your view is wrong.

A forward declaration for a function tells the compiler about a
/particular/ function.  The most critical piece of information here is
the name of the function.  Parameter and return types are important to
get correct, efficient and safe code - but it is the name that makes
this a forward declaration of a function.

Thus "int foo(int, char*);" declares a function just like "int x;"
declares a variable.


What Tim wrote was a function that took a function pointer as a
parameter.  The parameter simply gives the compiler a type (in this
case, a function pointer type) and a local name for that parameter.  It
is not a declaration of the parameter, or of the thing it points to -
that comes from the function's caller.

So when you write:

void qsort(void*, size_t, size_t,
	    int(*)(const void*,const void*));

you are declaring the function "qsort", but not making a function
declaration for the comparison function.

Even in its implementation:

void qsort(void* base, size_t nmemb, size_t size,
	    int(*compar)(const void*,const void*))
{
	...
}

you are only declaring and defining qsort.  "compar" is not a function
declaration or a forward declaration - there is no function called
"compar" in the code.  You would not call "void* base" a forward
declaration of the data that is going to be sorted by "qsort" - why
would you call the "compar" parameter a forward declaration of a function?


> 
> Because C still requires that. (My own language doesn't work the same
> way. The sole source of information as to how bas ought be called, comes
> from its definition. That is used to double-check the call to it in foo,
> when they are written without function pointers.)

I don't disagree that forward declarations could be made unnecessary in
C or a C-like language, at least when the same translation unit has the
definition.  But that is an independent matter from specifying the type
of a function pointer parameter.

> 
>>> The other unsatisfactory thing [...]
>>
>> I don't think anyone is claiming it's an example of a style to copy.
> 
> OK, so a more acceptable style would need forward declarations. The OP
> is saying that oughtn't be necessary. And I'm sure he meant being able
> to just leave them out without then having to rewrite the code in a
> convoluted and unsafe manner.
> 

In the case of two mutually recursive and dependent functions, a forward
declaration is probably the best solution in most cases.  Tim's point
was merely that it is not the /only/ solution.  A solution using
function pointers may be preferably if you want greater separation
between the functions, such as compiling them in different modules - you
certainly would not use function pointers merely to avoid forward
declarations, except as a teaching example.

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

#76178

On 16/11/2015 11:43, David Brown wrote:
> On 16/11/15 12:26, BartC wrote:
>> On 16/11/2015 01:57, Ben Bacarisse wrote:
>>> BartC <bc@freeuk.com> writes:
>>>
>>>> On 16/11/2015 00:47, Ben Bacarisse wrote:
>>
>>>>> 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).
>>
>> Yes, there are only two conventional function definitions. I think I
>> said that in my first post in the sub-thread.
>>
>> But look at the subject line: it's about forward declarations. In my
>> view, specifying a function pointer and telling the compiler how it
>> ought to be called, constitutes most of a forward declaration.
>
> Then your view is wrong.
>
> A forward declaration for a function tells the compiler about a
> /particular/ function.  The most critical piece of information here is
> the name of the function.

Are you sure? In the example, foo knows nothing of the name of the 
function it's calling. Neither does the compiler. Perhaps you mean its 
address, but the compiler doesn't know that either.

> void qsort(void*, size_t, size_t,
> 	    int(*)(const void*,const void*));
>
> you are declaring the function "qsort", but not making a function
> declaration for the comparison function.

So what's all that 'int(*)(const void*,const void*)' about? And what are 
the chances that it will bear a striking resemblance to the signature of 
the actual comparison function?

My point is that the compiler knows to know everything about a function 
at the call-site - except where it doesn't know which specific function 
because that's been hidden behind a pointer. Then it has to do an 
indirect call.

-- 
Bartc

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

#76181

On 16/11/15 13:20, BartC wrote:
> On 16/11/2015 11:43, David Brown wrote:
>> On 16/11/15 12:26, BartC wrote:
>>> On 16/11/2015 01:57, Ben Bacarisse wrote:
>>>> BartC <bc@freeuk.com> writes:
>>>>
>>>>> On 16/11/2015 00:47, Ben Bacarisse wrote:
>>>
>>>>>> 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).
>>>
>>> Yes, there are only two conventional function definitions. I think I
>>> said that in my first post in the sub-thread.
>>>
>>> But look at the subject line: it's about forward declarations. In my
>>> view, specifying a function pointer and telling the compiler how it
>>> ought to be called, constitutes most of a forward declaration.
>>
>> Then your view is wrong.
>>
>> A forward declaration for a function tells the compiler about a
>> /particular/ function.  The most critical piece of information here is
>> the name of the function.
> 
> Are you sure? In the example, foo knows nothing of the name of the
> function it's calling. Neither does the compiler. Perhaps you mean its
> address, but the compiler doesn't know that either.

Which example?  Are you talking about Tim's example?  In that case, you
are correct that foo knows nothing about the function it is calling,
including its name - that is because there are no forward declarations
involved!

Function forward declarations tell the compiler about a /named/,
/identified/ function.  Function pointers are a way to pass around
function details without a name known to the receiving function - just
as integer pointers are a way to let a function access an integer
without knowing its name.

> 
>> void qsort(void*, size_t, size_t,
>>         int(*)(const void*,const void*));
>>
>> you are declaring the function "qsort", but not making a function
>> declaration for the comparison function.
> 
> So what's all that 'int(*)(const void*,const void*)' about? And what are
> the chances that it will bear a striking resemblance to the signature of
> the actual comparison function?

The "int(*)(const void*,const void*)" is a /type/ - it is a function
pointer type.  Used in this context, in the declaration of qsort, it
determines the type of the fourth parameter to the qsort function.  It
is just like "void*" or "size_t" in the qsort declaration.  And just as
you don't call the "void*" a "forward declaration of a void", you don't
call the function pointer parameter type a "forward declaration of a
function".

And of course the syntax is very similar between a function declaration
and a function pointer type - just as "int" and "int*" are rather similar.

> 
> My point is that the compiler knows to know everything about a function
> at the call-site - except where it doesn't know which specific function
> because that's been hidden behind a pointer. Then it has to do an
> indirect call.
> 

Yes, that is how a function pointer works.  And that is why it is
different from a forward declaration for a function.

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

#76180

BartC <bc@freeuk.com> writes:

> On 16/11/2015 01:57, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 16/11/2015 00:47, Ben Bacarisse wrote:
>
>>>> 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).
>
> Yes, there are only two conventional function definitions. I think I
> said that in my first post in the sub-thread.

Not that I can see, no.  Maybe in another sub-thread?

> But look at the subject line: it's about forward declarations. In my
> view, specifying a function pointer and telling the compiler how it
> ought to be called, constitutes most of a forward declaration.

It's not, however, a second declaration of either of the functions which
was what I was talking about.  A parameter declaration declares the
parameter, and that alone.  It's never a declaration for the thing that
will one day get passed, no matter how tight the restrictions it places
on that thing.

As a debating exercise it has great potential -- you will be able to
argue indefinitely that a parameter that is a pointer to a function is
like a declaration of, or is similar to a declaration of, or is not
entirely unlike a declaration of the function that will get passed, but
unless you want to say that it *is* a declaration of that function, we
will just be talking at cross purposes.

<snip>
-- 
Ben.

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

#76182

On 16/11/2015 13:26, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>> Yes, there are only two conventional function definitions. I think I
>> said that in my first post in the sub-thread.
>
> Not that I can see, no.  Maybe in another sub-thread?

It was posted 11:11 GMT 15-Nov-2015 (but the sub-thread has a complex 
structure when I view in threaded mode). I said:

"The functions are defined once each. There is also a function pointer 
declared once, as a device used to be able to refer to a function not 
visible in the source until later. ..."

-- 
BartC

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

#76151

On Sunday, November 15, 2015 at 7:47:29 PM UTC-5, Ben Bacarisse wrote:
> "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.

Nope.

Best regards,
Rick C. Hodgin

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

#75803

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

> [ ... ]
> I do not propose forward declarations be done away with.  They have
> their place.  But in many cases they're not, and forcing the
> requirement means making writing the code harder for people (lots of
> people, everyone who programs in C) when the compiler could do that
> job for them, allowing them to have an easier job of authoring source
> code.

Yeah, but it also makes the code easier to *read* for people (lots
of people, everyone who maintains programs written in C by themselves
or others).

-- 
pa at panix dot com

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

#75810

On Wednesday, November 11, 2015 at 8:55:20 PM UTC-5, Pierre Asselin wrote:
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> 
> > [ ... ]
> > I do not propose forward declarations be done away with.  They have
> > their place.  But in many cases they're not, and forcing the
> > requirement means making writing the code harder for people (lots of
> > people, everyone who programs in C) when the compiler could do that
> > job for them, allowing them to have an easier job of authoring source
> > code.
> 
> Yeah, but it also makes the code easier to *read* for people (lots
> of people, everyone who maintains programs written in C by themselves
> or others).

Nobody has to code using non-forward declarations, Pierre.  They can
still code as they always have.  But in those cases where it would
not be hard to read, then it would be available.

It's not a limitation of the technology, only an enforced and artificial
limitation imposed upon developers by the compiler.  It's one countless
other languages have circumvented.

It's time for C to offer this feature in 2015.

Best regards,
Rick C. Hodgin

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

#75809

On 11/11/2015 14:40, David Brown wrote:
> On 10/11/15 23:20, Rick C. Hodgin wrote:
>> What's the standard C compiler command line switch allowing one to
>> turn off the REQUIREMENT of having forward declarations in a source
>> file here in 2015 when hard disk space, memory, and CPU power render
>> the requirement absolutely and completely unnecessary?

> Hyperbole aside, there are several reasons for having declarations in
> addition to definitions.
>
> It is definitely the case that declarations in advance of usage make it
> easier to implement a compiler - without them, the compiler would have
> to build up bits of its parse trees as it goes along, filling in the
> missing bits when it has more information.

That would only be the case, for a language with C-like syntax, for 
things such as typedefs, where you need to know that something is the 
name of a type in order to easily parse what follows.

That is not necessary for function names (nor label names, but C has 
already figured that one out). Variables can be declared later on too, 
but C requires them to be declared before use, and I prefer that anyway.)

> However, it would not be hard to have a compiler that first ran through
> the pre-processed file and sorted the file into type definitions,
> variable declarations, variable definitions, function declarations, then
> function definitions.  For each function definition, it could create a
> forward definition and squeeze that in before the function definitions,
> and then compile the whole lot.  Off-hand I cannot think of any reason
> why that might not work, but I would want a good deal more thought and
> opinion before calling it problem-free.

I've done that (in a source-to-source converter) and it appears to work. 
It neatly segregates module-scope or exported local typedefs, local 
variables, local function prototypes, imported versions of all those, 
followed by local or exported function definitions.

> As for scaling, and cpu power and memory, then it is clear that you
> haven't worked on large-scale projects.  There are plenty of projects
> that take /hours/ to compile and link when doing a full re-build.

(I don't think any project of mine would have got to the point where a 
development cycle would take hours. I would first explore what is 
possible with things such as dynamic linking, so that different parts 
can be developed separately, and the off-loading of as much 
functionality as possible onto interpreted languages which don't have a 
build time.

If that wasn't enough I would look at speeding up the tools as much as 
possible: writing a linker isn't that hard for example. But then, it is 
also possible that some projects are unnecessarily complex, and I 
wouldn't have allowed that to happen either!)

-- 
Bartc

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

#76313

On Tuesday, November 10, 2015 at 4:20:31 PM UTC-6, Rick C. Hodgin wrote:

[snip rant about still needing forward declarations in the 21st century]

This has been a complaint about C since...well, pretty much forever.  

C was designed in part to be easy to parse.  It's part of why C compilers 
made it to the desktop so much earlier than Fortran compilers (which 
required a bit more horsepower).  

From my perspective, it isn't that big a deal, and I appreciate that it
buys me some compile-time checks.  Within a single translation unit, I
just define the function before it's first called.  It means my code reads
"backwards", but again, as far as I'm concerned it's a reasonable tradeoff.

Yeah, it's not like writing a multipass compiler is deep magic or 
anything.  But changing the language definition to enable the behavior
is (probably) a non-trivial exercise, and I don't imaging WG14 is 
champing at the bit to make such a change.  It's less about tradition
and more about not wanting to break existing code. 

And, you know, there's always Java...

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

#76319

On Tuesday, November 17, 2015 at 5:48:29 PM UTC-5, John Bode wrote:
> On Tuesday, November 10, 2015 at 4:20:31 PM UTC-6, Rick C. Hodgin wrote:
> 
> [snip rant about still needing forward declarations in the 21st century]
> 
> This has been a complaint about C since...well, pretty much forever.  
> 
> C was designed in part to be easy to parse.  It's part of why C compilers 
> made it to the desktop so much earlier than Fortran compilers (which 
> required a bit more horsepower).  
> 
> From my perspective, it isn't that big a deal, and I appreciate that it
> buys me some compile-time checks.  Within a single translation unit, I
> just define the function before it's first called.  It means my code reads
> "backwards", but again, as far as I'm concerned it's a reasonable tradeoff.
> 
> Yeah, it's not like writing a multipass compiler is deep magic or 
> anything.  But changing the language definition to enable the behavior
> is (probably) a non-trivial exercise, and I don't imaging WG14 is 
> champing at the bit to make such a change.  It's less about tradition
> and more about not wanting to break existing code. 
> 
> And, you know, there's always Java...

Nothing would break, John.  It's a relaxation which would be allowed
when enabled.  The compiler would maintain its current method unless
the relaxation was explicitly set, in which case the developer would
be aware of the ability, and appropriately code for it.

Best regards,
Rick C. Hodgin

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

#76327

On 17/11/2015 22:46, John Bode wrote:
> On Tuesday, November 10, 2015 at 4:20:31 PM UTC-6, Rick C. Hodgin wrote:
>
> [snip rant about still needing forward declarations in the 21st century]
>
> This has been a complaint about C since...well, pretty much forever.
>
> C was designed in part to be easy to parse.  It's part of why C compilers
> made it to the desktop so much earlier than Fortran compilers (which
> required a bit more horsepower).

That's little to do with C being easier to parse, which it isn't. And 
weren't Fortran compilers around in the 1950s? The machines then weren't 
exactly powerful.

And, IIRC, Fortran didn't require forward declarations of subroutines, 
so it can't have been that difficult to do.

>  From my perspective, it isn't that big a deal, and I appreciate that it
> buys me some compile-time checks.  Within a single translation unit, I
> just define the function before it's first called.  It means my code reads
> "backwards", but again, as far as I'm concerned it's a reasonable tradeoff.
>
> Yeah, it's not like writing a multipass compiler is deep magic or
> anything.

(Are any compilers still multi-pass, in terms of rescanning the source 
code, in the 21st century? What we're talking about doesn't really need 
an extra pass.)

   But changing the language definition to enable the behavior
> is (probably) a non-trivial exercise, and I don't imaging WG14 is
> champing at the bit to make such a change.  It's less about tradition
> and more about not wanting to break existing code.

The language has already been changed to require a prototype of a 
function, so that encountered a function call that has not been declared 
is flagged as a warning or error.

That ones that can be assumed that the definition (or a forward 
declaration occuring after the call site) is yet to come.

-- 
Bartc

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

#76329

On 17/11/2015 23:35, BartC wrote:
> On 17/11/2015 22:46, John Bode wrote:

>    But changing the language definition to enable the behavior
>> is (probably) a non-trivial exercise, and I don't imaging WG14 is
>> champing at the bit to make such a change.  It's less about tradition
>> and more about not wanting to break existing code.
>

> The language has already been changed to require a prototype of a
> function, so that encountered a function call that has not been declared
> is flagged as a warning or error.
>
> That ones that can be assumed that the definition (or a forward
> declaration occuring after the call site) is yet to come.

Or in English (why doesn't Thunderbird has a preview stage?):

The language has already been changed to require a prototype of a 
function, so that encountering a function call that has not been 
declared is flagged as a warning or error.

That means it can be assumed that the definition (or a forward 
declaration occurring after the call site) is yet to come.

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

#76346

BartC <bc@freeuk.com> writes:
[...]
> The language has already been changed to require a prototype of a 
> function, so that encountering a function call that has not been 
> declared is flagged as a warning or error.

Almost.  A *declaration* is required; that declaration doesn't have to
be a prototype.

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

#76340

BartC <bc@freeuk.com> wrote:

(snip)

>> C was designed in part to be easy to parse.  It's part of why C compilers
>> made it to the desktop so much earlier than Fortran compilers (which
>> required a bit more horsepower).
 
> That's little to do with C being easier to parse, which it isn't. And 
> weren't Fortran compilers around in the 1950s? The machines then weren't 
> exactly powerful.

Fortran I manual is dated October 15, 1956. I am not sure when it
was actually available to users.

Knuth sometimes discusses Fortran 0, as the language was described
before the compiler was written.

The 704 compiler requires at least 4K (36 bit) words, one drum,
four tape units, and a card punch. 
 
> And, IIRC, Fortran didn't require forward declarations of subroutines, 
> so it can't have been that difficult to do.

SUBROUTINE and FUNCTION didn't come until Fortran II. 

For Fortran I (and II) "The name of a function is 4 to 7 alphabetic
or numeric characters (not special characters), of which the last
must be F and the first must be alphabetic. Also, the first must
be X if and only if the value of the function is to be fixed point."

Variable names are defined to exclude those names.  So, the parser
can tell a variable from a function just from the name.

For Fortran IV and Fortran 66, it is more interesting. If a name
is used in an expression followed by parenthesized expressions,
and isn't declared as an array, then it is a function.  Big surprise
to those who forget to declare arrays.

-- glen

[toc] | [prev] | [standalone]

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

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

csiph-web