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 1 of 4  [1] 2 3 4  Next page →

#75691 — Forward declarations

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?

Oh?  There isn't one?  Well WHY ON EARTH NOT??

What planet is this we live on?  Is this Legacy?  Is this Tradition?
Do we live in Toilinlabor Land?  Or is this Earth where capable and
comprehensive real human beings live, those with great resources and
capacity for creativity and an ability to overcome the historic ways
of laborious effort through thought, ideas, and collaboration?

C'mon C people!  Get with the times!!  Step into the 1980s at least,
please.

We live in a remarkable age.  We do not need to tie ourselves down to
those features which weren't even cutting edge back in the 70s.

Ugh!

Best regards,
Rick C. Hodgin

[toc] | [next] | [standalone]

#75694

Le 10/11/2015 23:20, Rick C. Hodgin a écrit :
> 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?
>
> Oh?  There isn't one?  Well WHY ON EARTH NOT??


OK, no forward declarations Rick, as you wish.

/* declaration 1 */
struct something {
	RvszTTrrTwassds hIIjjkqlsazsddeffd;
	BBuuunnissqgzeeethradsdee N;
} JUUUYYGGGOG;

[snip 150 lines]

/* declaration 2 */
typedef int RvszTTrrTwassds;

So, your SUPER-DUPER compiler sees declaration 1 and... Well, it doesn't 
bark (OF COURSE! It is your SUPER-DUPER compiler). It goes on, noting 
that struct something has two fields. It can't generate anything about 
struct JUUUYYGGGOG since its size isn't known. Actually, it can't start 
generating ANYTHING that concerns that structure until the end of the 
source file.

AT the end, it notices that the definition of BBuuunnissqgzeeethradsdee
is missing so... it must quit anyway.

You NEED a two pass compiler. Yes, of course, compilation speed is a 
negligable aspect nowadays... unless

it is still WAY TOO SLOW.

Lcc is a one pass compiler and very fast. Yes, it needs forward 
declarations. It is better for the reader anyway. You KNOW where to 
search for the definitions: they can be ONLY above their usage, so it 
saves you a lot of time looking...

Normally in C, Rick, you put those declarations in a .h and it is easy 
to find them. Using your system you have to look ANYWHERE in all 
possible places. Using a Grep tool on the generated pre-processor file

compiler -E

that is almost universally recognized as "Please output the preprocessor 
output and quit" option, the first occurrence of the word is the 
definition... Not in your new language.

Those are *some* of the MANY reasons why you are complaining about a 
non-problem Rick.

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

#75695

On Tuesday, November 10, 2015 at 5:38:43 PM UTC-5, jacobnavia wrote:
> Those are *some* of the MANY reasons why you are complaining about a 
> non-problem Rick.

Robert Griesemer, Rob Pike, and Ken Thompson all disagree with you,
Jacob, as does Google as a corporation in general, as they have several
Go language programs in place, and not one of them requires forward
declarations.  Why ... it's a miracle!

From:

    https://golang.org/doc/faq

Quote:

    "What are the guiding principles in the [Go] design?

    "Programming today involves too much bookkeeping, repetition,
     and clerical work. As Dick Gabriel says, ''Old programs read like
     quiet conversations between a well-spoken research worker and a
     well-studied mechanical colleague, not as a debate with a compiler.
     Who'd have guessed sophistication bought such noise?'' The
     sophistication is worthwhile -- no one wants to go back to the old
     languages -- but can it be more quietly achieved?

    "Go attempts to reduce the amount of typing in both senses of the
     word. Throughout its design, we have tried to reduce clutter and
     complexity. There are no forward declarations and no header files;
     everything is declared exactly once. Initialization is expressive,
     automatic, and easy to use. Syntax is clean and light on keywords."

-----
"Everything is declared exactly once."

What a novel concept in saving developer time in development at the
expense of a few microseconds of extra processing time per compilation.

Best regards,
Rick C. Hodgin

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

#75696

Rick C. Hodgin wrote:
> On Tuesday, November 10, 2015 at 5:38:43 PM UTC-5, jacobnavia wrote:
>> Those are *some* of the MANY reasons why you are complaining about a
>> non-problem Rick.
>
> Robert Griesemer, Rob Pike, and Ken Thompson all disagree with you,
> Jacob, as does Google as a corporation in general, as they have several
> Go language programs in place, and not one of them requires forward
> declarations.  Why ... it's a miracle!
>
> From:
>
>      https://golang.org/doc/faq
>
> Quote:
>
>      "What are the guiding principles in the [Go] design?
>
>      "Programming today involves too much bookkeeping, repetition,
>       and clerical work. As Dick Gabriel says, ''Old programs read like
>       quiet conversations between a well-spoken research worker and a
>       well-studied mechanical colleague, not as a debate with a compiler.
>       Who'd have guessed sophistication bought such noise?'' The
>       sophistication is worthwhile -- no one wants to go back to the old
>       languages -- but can it be more quietly achieved?
>
>      "Go attempts to reduce the amount of typing in both senses of the
>       word. Throughout its design, we have tried to reduce clutter and
>       complexity. There are no forward declarations and no header files;
>       everything is declared exactly once. Initialization is expressive,
>       automatic, and easy to use. Syntax is clean and light on keywords."
>
> -----
> "Everything is declared exactly once."
>
> What a novel concept in saving developer time in development at the
> expense of a few microseconds of extra processing time per compilation.

Have you ever tried building a big real world project?

I often make test builds of my main OS and they are far from quick, even 
on a $20K build box.  Headers and declarations get written once and as 
Jacob says, are easy for the human reader to find and read.  My vote 
goes to speeding up builds over a trivial reduction in typing.

-- 
Ian Collins

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

#75699

On Tuesday, November 10, 2015 at 6:24:24 PM UTC-5, Ian Collins wrote:
> Have you ever tried building a big real world project?
> 
> I often make test builds of my main OS and they are far from quick, even 
> on a $20K build box.  Headers and declarations get written once and as 
> Jacob says, are easy for the human reader to find and read.  My vote 
> goes to speeding up builds over a trivial reduction in typing.

Here's something to think on, Ian... how many of those big project
source files have changed?  How many lines of code have actually
changed?  Why recompile the whole project when only a few things
have changed?  And why not create a programming environment where
the changes you make, as you make them, are applied throughout the
system so that the change you've just made is applied immediately?

We are doing it wrong today.  It's the way that was required back
when computers ate oats and drank water and you had to have them
shod every few months.  But today they run on gasoline and diesel
fuel and can go 100,000 miles or more with little more than oil
changes and new tires.

Do you see where I'm coming from?

Best regards,
Rick C. Hodgin

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

#75702

In article <d0812d1c-0a0c-4880-b852-076092f70f51@googlegroups.com>,
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
>On Tuesday, November 10, 2015 at 6:24:24 PM UTC-5, Ian Collins wrote:
>> Have you ever tried building a big real world project?
>> 
>> I often make test builds of my main OS and they are far from quick, even 
>> on a $20K build box.  Headers and declarations get written once and as 
>> Jacob says, are easy for the human reader to find and read.  My vote 
>> goes to speeding up builds over a trivial reduction in typing.
>
>Here's something to think on, Ian... how many of those big project
>source files have changed?  How many lines of code have actually
>changed?  Why recompile the whole project when only a few things
>have changed?  And why not create a programming environment where
>the changes you make, as you make them, are applied throughout the
>system so that the change you've just made is applied immediately?
>
>We are doing it wrong today.  It's the way that was required back
>when computers ate oats and drank water and you had to have them
>shod every few months.  But today they run on gasoline and diesel
>fuel and can go 100,000 miles or more with little more than oil
>changes and new tires.
>
>Do you see where I'm coming from?
>
>Best regards,
>Rick C. Hodgin

This may get nominated for dumb post of the year.  Submissions are being
accepted...

This YouTube vid [*] describes Rick very well:

    http://www.youtube.com/watch?v=wvVPdyYeaQU

[*] Appropriate, since Rick is so fond of answering questions (those put to
him) via giving YouTube URLs.

-- 
Given Bush and his insanely expensive wars (*), that we will be paying for
for generations to come, the only possible response a sensible person need
ever give, when a GOPer/TeaBagger says anything about "deficits", is a
polite snicker.

(*) Obvious money transfers between the taxpayers and Bush's moneyed
interests.  Someday, we'll actually figure out a way to have a war where the
money just gets moved around and nobody (on either side) gets injured or
killed.  That will be an accomplishment of which we will be justly proud.

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

#75707

Rick C. Hodgin wrote:
> On Tuesday, November 10, 2015 at 6:24:24 PM UTC-5, Ian Collins wrote:
>> Have you ever tried building a big real world project?
>>
>> I often make test builds of my main OS and they are far from quick, even
>> on a $20K build box.  Headers and declarations get written once and as
>> Jacob says, are easy for the human reader to find and read.  My vote
>> goes to speeding up builds over a trivial reduction in typing.
>
> Here's something to think on, Ian... how many of those big project
> source files have changed?  How many lines of code have actually
> changed?  Why recompile the whole project when only a few things
> have changed?  And why not create a programming environment where
> the changes you make, as you make them, are applied throughout the
> system so that the change you've just made is applied immediately?

Because most projects aren't one man shows.  There may be dozens or 
hundreds of developers and scores of commits to the project each day.  I 
don't know what changes someone else has made when I pull their changes, 
but the build system does.  If one of those changes touches a 
significant header, the rebuild will be big.

> We are doing it wrong today.  It's the way that was required back
> when computers ate oats and drank water and you had to have them
> shod every few months.  But today they run on gasoline and diesel
> fuel and can go 100,000 miles or more with little more than oil
> changes and new tires.
>
> Do you see where I'm coming from?

Ignorance of large scale software development?

I don't intend that is an insult, just an observation.  Most of your 
tool ideas would work reasonably well for very small projects, but they 
would not scale to a real world distributed development.

-- 
Ian Collins

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

#75713

Ian Collins wrote:
> Most of your tool ideas would work reasonably
> well for very small projects, but they would
> not scale to a real world distributed development.

Where you see a blocker, I see a solution. What's
needed is a git-like ability with candidate commits,
candidate pushes, and push notifications from
the servers we pull from. Each such notification
would allow anyone working on that branch to
receive the candidate changes where they could
be merged in as though they were simply edited,
with automatic recompilation of those lines also
in real-time.

It's just a rethinking of existing methodologies
applied to a modern retooling.

Best regards,
Rick C. Hodgin

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

#75705

On 10/11/2015 22:38, jacobnavia wrote:
> Le 10/11/2015 23:20, Rick C. Hodgin a écrit :
>> 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?
>>
>> Oh?  There isn't one?  Well WHY ON EARTH NOT??
>
> OK, no forward declarations Rick, as you wish.
>
> /* declaration 1 */
> struct something {
>      RvszTTrrTwassds hIIjjkqlsazsddeffd;
>      BBuuunnissqgzeeethradsdee N;
> } JUUUYYGGGOG;
>
> [snip 150 lines]
>
> /* declaration 2 */
> typedef int RvszTTrrTwassds;
>
> So, your SUPER-DUPER compiler sees declaration 1 and... Well, it doesn't
> bark (OF COURSE! It is your SUPER-DUPER compiler). It goes on, noting
> that struct something has two fields. It can't generate anything about
> struct JUUUYYGGGOG since its size isn't known. Actually, it can't start
> generating ANYTHING that concerns that structure until the end of the
> source file.
>
> AT the end, it notices that the definition of BBuuunnissqgzeeethradsdee
> is missing so... it must quit anyway.

I don't think it's typedefs that are being objected to.

It's mainly functions, as the function prototype usually needs to be 
written twice (typedefs, only once.)

> You NEED a two pass compiler.

You don't need two passes over the source code, not if you just want to 
avoid writing function prototypes.

You /will/ probably need to do the type-checking (of function arguments) 
in a latter pass over the internal representation.

Or does your compiler start generating code for a function even before 
it's started compiling the next function?

  Yes, of course, compilation speed is a
> negligable aspect nowadays... unless

> it is still WAY TOO SLOW.
>
> Lcc is a one pass compiler and very fast.

Avoiding prototypes has a benefit and sometimes benefits have costs, but 
it needn't be much.

A few years ago, I was using a scheme where a program scanned my source 
files for function definitions, and automatically generated files of 
prototypes so that I never had to bother.

This *did* involve a separate scan of the source code, plus writing out 
files and stuff, plus rewriting the source code as a new file (because I 
was doing a bunch of other transformations too), *and* the program that 
did all this was interpreted as well!

How long do you think that took? I remember it was about generally a 3% 
overhead compared with compiling the resulting C code.

Doing this stuff inside the compiler, I think the cost will be negligible.

-- 
Bartc

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

#75723

On 2015-11-10 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?

Please try to present some examples
to help me understand your suggestion...

(I am willingly admit I am neither clairvoyant nor legilimens.)

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

#75749

On Wednesday, November 11, 2015 at 4:19:26 AM UTC-5, Lőrinczy Zsigmond wrote:
> On 2015-11-10 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?
> 
> Please try to present some examples
> to help me understand your suggestion...
> 
> (I am willingly admit I am neither clairvoyant nor legilimens.)

#include <stdio.h>

int main(int argc, char* argv[])
{
    my_function();
    exit(0);
}

void my_function(void)
{
    printf("Hello, world!\n");
}

Best regards,
Rick C. Hodgin

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

#75743

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?
> 
> Oh?  There isn't one?  Well WHY ON EARTH NOT??
> 
> What planet is this we live on?  Is this Legacy?  Is this Tradition?
> Do we live in Toilinlabor Land?  Or is this Earth where capable and
> comprehensive real human beings live, those with great resources and
> capacity for creativity and an ability to overcome the historic ways
> of laborious effort through thought, ideas, and collaboration?
> 
> C'mon C people!  Get with the times!!  Step into the 1980s at least,
> please.
> 
> We live in a remarkable age.  We do not need to tie ourselves down to
> those features which weren't even cutting edge back in the 70s.
> 
> Ugh!
> 
> Best regards,
> Rick C. Hodgin
> 

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.

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.

For exported functions and data, the definition in a header file is
important to being sure that everything is consistent between
independently compiled translation units.  For my own code, I am quite
strict in the rule that code and data are either declared and defined
with "static" in a C file, or they are declared with "extern" in a
matching H file that is included by everything that uses the function or
data, including the implementation C file.  So for me, the "forward
declaration" is in the header file and is part of the description of how
the code is to be used by other modules, while the definition in the
implementation file is the implementation.  It is not a duplication of
effort, because it serves two purposes - and the compiler will help
check that it all matches.  (It is very rare that I need forward
declarations of functions within the implementation - I have never found
it difficult to order function definitions before their use.  It makes
it easier to find out what is going on in the code.)


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.  And
with modern link-time optimisation, if you want top-quality results then
you often need to do a substantial amount of rebuilding and re-compiling
even for small changes to a few files in the project.  So ideas that
mean slowdowns for compilation, even relatively small slowdowns, are
rarely popular.

However, there is an idea that would improve scalability significantly,
especially in C++ (where large headers full of templates make compile
times much larger) - "modules" that allow the compilation of headers and
source files into blocks that can be re-used optimally and conveniently
without the compiler having to re-compile all the code from scratch.  I
don't know if C will ever adopt some sort of module system, but it is
likely that C++ will - and if I were making a new compiler for a new
C-like language, I'd have some sort of module concept.

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

#75750

On Wednesday, November 11, 2015 at 9:40:14 AM UTC-5, 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?
> > 
> > Oh?  There isn't one?  Well WHY ON EARTH NOT??
> > 
> > What planet is this we live on?  Is this Legacy?  Is this Tradition?
> > Do we live in Toilinlabor Land?  Or is this Earth where capable and
> > comprehensive real human beings live, those with great resources and
> > capacity for creativity and an ability to overcome the historic ways
> > of laborious effort through thought, ideas, and collaboration?
> > 
> > C'mon C people!  Get with the times!!  Step into the 1980s at least,
> > please.
> > 
> > We live in a remarkable age.  We do not need to tie ourselves down to
> > those features which weren't even cutting edge back in the 70s.
> > 
> > Ugh!
> > 
> > Best regards,
> > Rick C. Hodgin
> > 
> 
> 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.
> 
> 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.
> 
> For exported functions and data, the definition in a header file is
> important to being sure that everything is consistent between
> independently compiled translation units.  For my own code, I am quite
> strict in the rule that code and data are either declared and defined
> with "static" in a C file, or they are declared with "extern" in a
> matching H file that is included by everything that uses the function or
> data, including the implementation C file.  So for me, the "forward
> declaration" is in the header file and is part of the description of how
> the code is to be used by other modules, while the definition in the
> implementation file is the implementation.  It is not a duplication of
> effort, because it serves two purposes - and the compiler will help
> check that it all matches.  (It is very rare that I need forward
> declarations of functions within the implementation - I have never found
> it difficult to order function definitions before their use.  It makes
> it easier to find out what is going on in the code.)
> 
> 
> 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.  And
> with modern link-time optimisation, if you want top-quality results then
> you often need to do a substantial amount of rebuilding and re-compiling
> even for small changes to a few files in the project.  So ideas that
> mean slowdowns for compilation, even relatively small slowdowns, are
> rarely popular.
> 
> However, there is an idea that would improve scalability significantly,
> especially in C++ (where large headers full of templates make compile
> times much larger) - "modules" that allow the compilation of headers and
> source files into blocks that can be re-used optimally and conveniently
> without the compiler having to re-compile all the code from scratch.  I
> don't know if C will ever adopt some sort of module system, but it is
> likely that C++ will - and if I were making a new compiler for a new
> C-like language, I'd have some sort of module concept.

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.

Best regards,
Rick C. Hodgin

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

#75751

On Wednesday, November 11, 2015 at 10:21:47 AM UTC-5, Rick C. Hodgin wrote:
> On Wednesday, November 11, 2015 at 9:40:14 AM UTC-5, 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?
> > > 
> > > Oh?  There isn't one?  Well WHY ON EARTH NOT??
> > > 
> > > What planet is this we live on?  Is this Legacy?  Is this Tradition?
> > > Do we live in Toilinlabor Land?  Or is this Earth where capable and
> > > comprehensive real human beings live, those with great resources and
> > > capacity for creativity and an ability to overcome the historic ways
> > > of laborious effort through thought, ideas, and collaboration?
> > > 
> > > C'mon C people!  Get with the times!!  Step into the 1980s at least,
> > > please.
> > > 
> > > We live in a remarkable age.  We do not need to tie ourselves down to
> > > those features which weren't even cutting edge back in the 70s.
> > > 
> > > Ugh!
> > > 
> > > Best regards,
> > > Rick C. Hodgin
> > > 
> > 
> > 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.
> > 
> > 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.
> > 
> > For exported functions and data, the definition in a header file is
> > important to being sure that everything is consistent between
> > independently compiled translation units.  For my own code, I am quite
> > strict in the rule that code and data are either declared and defined
> > with "static" in a C file, or they are declared with "extern" in a
> > matching H file that is included by everything that uses the function or
> > data, including the implementation C file.  So for me, the "forward
> > declaration" is in the header file and is part of the description of how
> > the code is to be used by other modules, while the definition in the
> > implementation file is the implementation.  It is not a duplication of
> > effort, because it serves two purposes - and the compiler will help
> > check that it all matches.  (It is very rare that I need forward
> > declarations of functions within the implementation - I have never found
> > it difficult to order function definitions before their use.  It makes
> > it easier to find out what is going on in the code.)
> > 
> > 
> > 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.  And
> > with modern link-time optimisation, if you want top-quality results then
> > you often need to do a substantial amount of rebuilding and re-compiling
> > even for small changes to a few files in the project.  So ideas that
> > mean slowdowns for compilation, even relatively small slowdowns, are
> > rarely popular.
> > 
> > However, there is an idea that would improve scalability significantly,
> > especially in C++ (where large headers full of templates make compile
> > times much larger) - "modules" that allow the compilation of headers and
> > source files into blocks that can be re-used optimally and conveniently
> > without the compiler having to re-compile all the code from scratch.  I
> > don't know if C will ever adopt some sort of module system, but it is
> > likely that C++ will - and if I were making a new compiler for a new
> > C-like language, I'd have some sort of module concept.
> 
> I do not propose forward declarations be done away with.  They have
> their place.  But in many cases they're not, and forcing the

Ode to dyslexia.

Should be:  "...in many cases they're not needed, 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.

Best regards,
Rick C. Hodgin

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

#75753

On 11/11/15 16:21, Rick C. Hodgin 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.
> 

Fair enough, I suppose.  But I don't personally think that the
requirement for forward declarations is at all onerous - when I code, I
almost never use them (except for defining exported functions and data,
and we agree that those are fine).  Even if I did have particular reason
to want to write a static function after its usage rather than before,
I just can't see it as a big issue.

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

#75754

On Wednesday, November 11, 2015 at 10:30:07 AM UTC-5, David Brown wrote:
> On 11/11/15 16:21, Rick C. Hodgin 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.
> > 
> 
> Fair enough, I suppose.  But I don't personally think that the
> requirement for forward declarations is at all onerous - when I code, I
> almost never use them (except for defining exported functions and data,
> and we agree that those are fine).  Even if I did have particular reason
> to want to write a static function after its usage rather than before,
> I just can't see it as a big issue.

Would that the world were as enlightened as you, Mr. David.

Best regards,
Rick C. Hodgin

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

#75959

On Wed, 11 Nov 2015 16:29:55 +0100, David Brown wrote:
> On 11/11/15 16:21, Rick C. Hodgin 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.
>> 
> 
> Fair enough, I suppose.  But I don't personally think that the
> requirement for forward declarations is at all onerous - when I code, I
> almost never use them (except for defining exported functions and data,
> and we agree that those are fine).  Even if I did have particular reason
> to want to write a static function after its usage rather than before,
> I just can't see it as a big issue.

It's not a big issue.  But it is pointless repetition.  The saving
grace is that compilers generally check the consistency of declarations
within a translation unit (up to substitution of compatible types),
so problems with the duplicate declarations are likely to be noticed
quickly.

I mentioned this example in another thread:

It is currently impossible in C to write mutually recursive
functions without declaring at least one of the functions twice.
Requiring redundant declarations is rather arbitrary and not helpful.

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

#75961

On Friday, November 13, 2015 at 1:23:10 PM UTC-5, Nick Bowler wrote:
> I mentioned this example in another thread:
> 
> It is currently impossible in C to write mutually recursive
> functions without declaring at least one of the functions twice.
> Requiring redundant declarations is rather arbitrary and not helpful.

That reason is exactly why I asked for this relaxation to be added to
the C standard.  I had that very scenario come up:

    https://groups.google.com/forum/#!topic/comp.std.c/jmm6dXeXiHY

Best regards,
Rick C. Hodgin

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

#75967

On 13/11/2015 18:39, Rick C. Hodgin wrote:
> On Friday, November 13, 2015 at 1:23:10 PM UTC-5, Nick Bowler wrote:
>> I mentioned this example in another thread:
>>
>> It is currently impossible in C to write mutually recursive
>> functions without declaring at least one of the functions twice.
>> Requiring redundant declarations is rather arbitrary and not helpful.
>
> That reason is exactly why I asked for this relaxation to be added to
> the C standard.  I had that very scenario come up:
>
>      https://groups.google.com/forum/#!topic/comp.std.c/jmm6dXeXiHY

Yes, that's an entirely reasonable proposal.

What's of more interest is the extents people go to to defend the way C 
works.

It's 'good' that you have to write a summary of the functions at the 
start! Because it apparently makes it easier to find the prototype of a 
function when you encounter a call to it.

But this isn't the case at all:

(1) If the functions are declared in the right order, then there /are/ 
no forward declarations anyway; you still have to search for them! 
(Unless you've been reading the source file line by line and have a 
photographic memory)

(2) The list of local function prototypes, in any real program, is going 
to be mess of mixed declarations, macros, conditional code and all the 
rest. They're not that easy to find unless you use a search function, 
which can just as easily find the definition.

(3) Half the functions won't appear in the list of forward references 
because they are imported and the prototypes will be in separate header 
files.

So function prototypes will be all over the place anyway.

Then, it's also 'good' that you have to write function definitions and 
function declarations 'in sync. Or, if it's admitted that it's extra 
effort, then it doesn't matter because it only takes a dozen key presses 
to generate or update each exported prototype.

Frankly, some of the arguments in the comp.std.c thread you linked to 
are ludicrous.

-- 
Bartc

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

#76007

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 );
    }

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web