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

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

Forward declarations ... the straw that broke the camel's back

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

Contents

  Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-29 10:36 -0700
    Re: Forward declarations ... the straw that broke the camel's back supercat@casperkitty.com - 2016-06-29 16:04 -0700
      Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-29 16:30 -0700
        Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-29 19:52 -0700
          Re: Forward declarations ... the straw that broke the camel's back Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-30 13:00 +0100
            Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 05:42 -0700
              Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 18:11 +0100
                Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 10:30 -0700
                  Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 19:54 +0100
                    Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 12:31 -0700
                      Re: Forward declarations ... the straw that broke the camel's back Ian Collins <ian-news@hotmail.com> - 2016-07-01 07:59 +1200
                        Re: Forward declarations ... the straw that broke the camel's back Gareth Owen <gwowen@gmail.com> - 2016-06-30 21:31 +0100
                        Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 14:19 -0700
                          Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 14:31 -0700
                      Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 21:18 +0100
                        Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 14:26 -0700
                          Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 22:44 +0100
                            Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 17:23 -0700
                  Re: Forward declarations ... the straw that broke the camel's back David Brown <david.brown@hesbynett.no> - 2016-07-05 21:38 +0200
                    Re: Forward declarations ... the straw that broke the camel's back Richard Heathfield <rjh@cpax.org.uk> - 2016-07-05 21:05 +0100
                    Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-05 13:32 -0700
                      Re: Forward declarations ... the straw that broke the camel's back David Brown <david.brown@hesbynett.no> - 2016-07-05 23:20 +0200
                        Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-05 14:25 -0700
                        Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-05 16:14 -0700
                          Re: Forward declarations ... the straw that broke the camel's back David Brown <david.brown@hesbynett.no> - 2016-07-06 11:18 +0200
                            Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-06 03:36 -0700
                        Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-05 16:23 -0700
                          Re: Forward declarations ... the straw that broke the camel's back David Brown <david.brown@hesbynett.no> - 2016-07-06 11:29 +0200
                            Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-06 02:49 -0700
                              Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-06 05:18 -0700
                                Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-07-06 13:57 +0100
                                  Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-06 06:24 -0700
                              Re: Forward declarations ... the straw that broke the camel's back David Brown <david.brown@hesbynett.no> - 2016-07-06 15:22 +0200
                                Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-06 07:12 -0700
                                Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-06 08:08 -0700
                                  Re: Forward declarations ... the straw that broke the camel's back supercat@casperkitty.com - 2016-07-06 09:00 -0700
                                    Re: Forward declarations ... the straw that broke the camel's back Ian Collins <ian-news@hotmail.com> - 2016-07-07 08:01 +1200
                                      Re: Forward declarations ... the straw that broke the camel's back supercat@casperkitty.com - 2016-07-06 13:30 -0700
                                Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-07-06 17:30 +0100
      Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 00:39 +0100
        Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-06-30 22:08 +0200
    Re: Forward declarations ... the straw that broke the camel's back gordonb.h5sc5@burditt.org (Gordon Burditt) - 2016-06-29 20:52 -0500
      Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-29 19:00 -0700
        Re: Forward declarations ... the straw that broke the camel's back Ian Collins <ian-news@hotmail.com> - 2016-06-30 16:06 +1200
          Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-30 02:48 -0700
            Re: Forward declarations ... the straw that broke the camel's back Ian Collins <ian-news@hotmail.com> - 2016-06-30 23:25 +1200
              Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-30 04:39 -0700
                Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-06-30 21:50 +0200
              Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-06-30 06:49 -0700
                Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-06-30 22:23 +0200
                  Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-04 10:43 -0700
                    Vaporware (Was: Forward declarations ... the straw that broke ...) gazelle@shell.xmission.com (Kenny McCormack) - 2016-07-04 17:59 +0000
                    Re: Forward declarations ... the straw that broke the camel's back Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-07-06 12:38 -0500
                      Re: Forward declarations ... the straw that broke the camel's back "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-07-06 11:38 -0700
            Re: Forward declarations ... the straw that broke the camel's back Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-30 19:51 +0100
              Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-06-30 21:59 +0200
                Re: Forward declarations ... the straw that broke the camel's back Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-01 01:05 -0700
          Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 11:32 +0100
            Re: Forward declarations ... the straw that broke the camel's back Ian Collins <ian-news@hotmail.com> - 2016-06-30 23:23 +1200
              Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 14:28 +0100
                Re: Forward declarations ... the straw that broke the camel's back supercat@casperkitty.com - 2016-06-30 08:24 -0700
                  Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 16:56 +0100
                Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-06-30 22:17 +0200
                  Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-06-30 22:22 +0100
                    Re: Forward declarations ... the straw that broke the camel's back jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-01 08:25 +0200
                      Re: Forward declarations ... the straw that broke the camel's back BartC <bc@freeuk.com> - 2016-07-01 12:09 +0100

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

#89872

Le 30/06/2016 à 01:39, BartC a écrit :

> You don't want the hassle of either defining addint() before all
> references to it, or having to write a forward declaration, which
> repeats much of the function signature, at the top of the module.
>

It is such a trivial  task... It has never bothered me actually. I 
prefer a fast compiler that has a single pass than a compilcated one 
that has to backtrack until it finds the definition of a call and can 
emit code for it.

And, by the way, I like RE READING my programs...

	foo(25/987,height, calories, age);

???

What's that foo?

Where is the definition of foo???

Gosh...

grep foo *.c

nothing?
Where the hell is that defined? Maybe in the header subdirectory?

I like readable code because... I can re read it later you see? Even if 
I wasn't the author, or if I have completely fogotten all that code.

In the current situation I know that the definition is before the first 
call, and that reduces considerably the search time. Generally in well 
structured code I just look in the headers and I see it.

Yes, we can conceive a language where there are no declarations but...
have fun searching the definitions then!

:-)

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

#89846

> Forward declarations have pushed me over the edge of tolerance.  I have
> tried to work with C and C++ within their constraints, but it makes things
> increasing complex and difficult, and reduces productivity significantly,
> in trying to address their needs.

I have found dealing with forward declarations relatively easy:

	cproto *.c > proto.h

Now have every source file #include "proto.h" .
In practice, I have the variable $(SRCS) in the Makefile and use
that rather than *.c, as sometimes there's an old version of 
something hanging around in case I need to back out a change, or
some kind of test program.

cproto extracts declarations from C files and makes one big file of
prototypes.  Sometimes it is useful to add some #include's to the
front of proto.h, say, including <stdio.h> if functions use
a FILE * as a parameter, using a short script.

cproto has options to include static functions or not.  Generally,
I will deal with forward declarations of static functions by ordering
them in the source file or adding a prototype at the front of the
file.  There usually aren't that many static functions and the don't
change much.

The Makefile ensures that the prototypes are always up to date.

If I want to divide things into separate libraries, I can put them
in separate directories and run cproto in each one of them.

> Forward declaration requirements are completely insane in the year 2016,
> and if it's at all possible, I will never require them in any product I
> create.  I will always do my best to allow for the n-pass scenario, to take
> the microsecond hit in performance to alleviate the burden from the
> shoulders of the human developer.

I find the error-checking provided by forward declarations essential.
cproto takes care of providing the declarations, and the only
manual job is ensuring that types needed for function return types
and arguments are available (and I think you'd need this even without
forward declarations, as you'd need to provide an argument of the 
right type).  

Do you have a way of doing error-checking without the forward declarations,
even in a situation of a not-more-than-one-function-per-source-file
coding?

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

#89847

On Wednesday, June 29, 2016 at 9:53:05 PM UTC-4, Gordon Burditt wrote:
> > Forward declaration requirements are completely insane in the year 2016,
> > and if it's at all possible, I will never require them in any product I
> > create.  I will always do my best to allow for the n-pass scenario, to take
> > the microsecond hit in performance to alleviate the burden from the
> > shoulders of the human developer.
> 
> I find the error-checking provided by forward declarations essential.
> cproto takes care of providing the declarations, and the only
> manual job is ensuring that types needed for function return types
> and arguments are available (and I think you'd need this even without
> forward declarations, as you'd need to provide an argument of the 
> right type).
> 
> Do you have a way of doing error-checking without the forward declarations,
> even in a situation of a not-more-than-one-function-per-source-file
> coding?

The only thing forward declarations do is define things so they can be
used in source code.

By removing the cproto step and having the compiler do that for you at
each compile, you are able to derive all definitions in the project.
And, by doing a standard top-down compile you can allow the redefinition
of things (if that's important to you), but that can also be done away
with and you can just give each thing a unique name or namespace/scope.

Errors are reported when things aren't known.

Best regards,
Rick C. Hodgin

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

#89849

On 06/30/16 02:00 PM, Rick C. Hodgin wrote:
>
> The only thing forward declarations do is define things so they can be
> used in source code.
>
> By removing the cproto step and having the compiler do that for you at
> each compile, you are able to derive all definitions in the project.
> And, by doing a standard top-down compile you can allow the redefinition
> of things (if that's important to you), but that can also be done away
> with and you can just give each thing a unique name or namespace/scope.
>
> Errors are reported when things aren't known.

So you loose most of the benefits of incremental builds?

Wouldn't your scheme require the compiler to check every source file to 
see if a function signature has changed and retain a cache of all the 
callers of all function in order to detect errors?

-- 
Ian

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

#89851

On Thursday, June 30, 2016 at 5:06:50 AM UTC+1, Ian Collins wrote:
>
> So you loose most of the benefits of incremental builds?
> 
> Wouldn't your scheme require the compiler to check every source file to 
> see if a function signature has changed and retain a cache of all the 
> callers of all function in order to detect errors?
> 
That doesn't mean doing a full semantic parse of all files.
If the system doesn't time/date stamp files, you can do a sha1 hash to
quickly detect edited files.
The much criticised "Malcolm call tree" would provide a list of all
dependencies. Dynamic binding is harder, of course.

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

#89855

On 06/30/16 09:48 PM, Malcolm McLean wrote:
> On Thursday, June 30, 2016 at 5:06:50 AM UTC+1, Ian Collins wrote:
>>
>> So you loose most of the benefits of incremental builds?
>>
>> Wouldn't your scheme require the compiler to check every source file to
>> see if a function signature has changed and retain a cache of all the
>> callers of all function in order to detect errors?
>>
> That doesn't mean doing a full semantic parse of all files.
> If the system doesn't time/date stamp files, you can do a sha1 hash to
> quickly detect edited files.
> The much criticised "Malcolm call tree" would provide a list of all
> dependencies. Dynamic binding is harder, of course.

Sure you can check for edited source files, but how would you know which 
other files are impacted by the change?

-- 
Ian

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

#89856

On Thursday, June 30, 2016 at 12:25:51 PM UTC+1, Ian Collins wrote:
> On 06/30/16 09:48 PM, Malcolm McLean wrote:
> > On Thursday, June 30, 2016 at 5:06:50 AM UTC+1, Ian Collins wrote:
> >>
> >> So you loose most of the benefits of incremental builds?
> >>
> >> Wouldn't your scheme require the compiler to check every source file to
> >> see if a function signature has changed and retain a cache of all the
> >> callers of all function in order to detect errors?
> >>
> > That doesn't mean doing a full semantic parse of all files.
> > If the system doesn't time/date stamp files, you can do a sha1 hash to
> > quickly detect edited files.
> > The much criticised "Malcolm call tree" would provide a list of all
> > dependencies. Dynamic binding is harder, of course.
> 
> Sure you can check for edited source files, but how would you know which 
> other files are impacted by the change?
> 
The "Malcolm call tree" gives you the points from which subroutines are
called. So if a file is edited, any changed functions are marked as "changed",
then the call tree gives you the places where those functions are invoked.
However if A.c calls functions from B.c and B.c calls functions from C.c,
which is edited,  then change should only affect B.c and C.c, unless A.c
is inlining.

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

#89869

Le 30/06/2016 à 13:39, Malcolm McLean a écrit :
> if a file is edited, any changed functions are marked as "changed",
> then the call tree gives you the places where those functions are invoked.
> However if A.c calls functions from B.c and B.c calls functions from C.c,
> which is edited,  then change should only affect B.c and C.c, unless A.c
> is inlining.

If the change is as follows:

Function in C.c has a new extra parameter. This means that its calling 
function must be modified to require a new parameter in the worst case, 
since the new data has to be passed from A.c.

Then, since the interface of B.c has changed, all the calls to the 
functions in B.c could be affected if they call indirectly any changed 
function. Nice job to be sure that no function pointer is passed around 
that has been assigned in file Z.c to a concerned function.

This requires a considerable team to program all the weird cases that 
could arise into that incredible compiler Malcolm.

I think it is certain that that compiler is beyond the means of Mr 
Hodgin. He is fond of starting discussions about his "CAlive" compiler 
and all te nice things it will do, but I haven't seen anything that 
remotely resembles a compiler even in its earliest stages after all this 
time.

:-)

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

#89860

On Thursday, June 30, 2016 at 7:25:51 AM UTC-4, Ian Collins wrote:
> On 06/30/16 09:48 PM, Malcolm McLean wrote:
> > On Thursday, June 30, 2016 at 5:06:50 AM UTC+1, Ian Collins wrote:
> >>
> >> So you loose most of the benefits of incremental builds?
> >>
> >> Wouldn't your scheme require the compiler to check every source file to
> >> see if a function signature has changed and retain a cache of all the
> >> callers of all function in order to detect errors?
> >>
> > That doesn't mean doing a full semantic parse of all files.
> > If the system doesn't time/date stamp files, you can do a sha1 hash to
> > quickly detect edited files.
> > The much criticised "Malcolm call tree" would provide a list of all
> > dependencies. Dynamic binding is harder, of course.
> 
> Sure you can check for edited source files, but how would you know which 
> other files are impacted by the change?

CAlive is a full edit-and-continue compiler, a feature I call "LiveCode".
As such, it maintains an internal database on compilation which has the
references to each type, each token, etc, using SHA-1, a trick I learned
from git's design.

As such, whenever anything is changed, a search of that database reveals
where it is in the system, and only those lines are re-compiled then in
real-time, with real-time warnings and something I call "inquiry"s are
created, as CAlive allows broken programs to still compile and run, but
when that errant line of code is encountered it traps to the debugger so
it can be changed via the LiveCode edit-and-continue abilities.

This will be for the full GUI version of the compiler.  It won't be
implemented until I'm able to bootstrap my own compiler, and extend it
into the GUI environment, which will be exposed through an API allowing
any other IDE to be expanded to introduce these features into their own
design.

Best regards,
Rick C. Hodgin

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

#89875

Le 30/06/2016 à 15:49, Rick C. Hodgin a écrit :
> CAlive is a full edit-and-continue compiler, a feature I call "LiveCode".
> As such, it maintains an internal database on compilation which has the
> references to each type, each token, etc, using SHA-1, a trick I learned
> from git's design.
Nice, nice.

Can we see it? Can I have a copy?

Ahh ok ok, as you say some lines later

<quote>
until I'm able to bootstrap my own compiler
<end quote>

Of course. Well, please when you post messages here make clear that all 
that CAlive is just vaporware.

Vapoware always runs...

:-)

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

#90000

On Thursday, June 30, 2016 at 4:23:24 PM UTC-4, jacobnavia wrote:
> Le 30/06/2016 à 15:49, Rick C. Hodgin a écrit :
> > CAlive is a full edit-and-continue compiler, a feature I call "LiveCode".
> > As such, it maintains an internal database on compilation which has the
> > references to each type, each token, etc, using SHA-1, a trick I learned
> > from git's design.
> Nice, nice.
> 
> Can we see it? Can I have a copy?
> 
> Ahh ok ok, as you say some lines later
> 
> <quote>
> until I'm able to bootstrap my own compiler
> <end quote>
> 
> Of course. Well, please when you post messages here make clear that all 
> that CAlive is just vaporware.
> 
> Vapoware always runs...
> 
> :-)

You're welcome to watch me coding, Jacob.  There's a "live coding now" link
on that page when I'm active.

    http://www.libsf.org/es2/tasks.html

It's not done yet ... but it's in progress.  And I would welcome any help
that Christ-serving folk would like to offer.

Best regards,
Rick C. Hodgin

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

#90003 — Vaporware (Was: Forward declarations ... the straw that broke ...)

In article <1358d8da-6287-4232-be33-91cf645859e7@googlegroups.com>,
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
...
>It's not done yet ... but it's in progress.

Quelle surprise!

>And I would welcome any help
>that Christ-serving folk would like to offer.

Then it sounds like Jacob need not apply...

-- 
"Insisting on perfect safety is for people who don't have the balls to live
in the real world."

    - Mary Shafer, NASA Ames Dryden -

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

#90088

On 7/4/16 12:43 PM, Rick C. Hodgin wrote:
> You're welcome to watch me coding, Jacob.  There's a "live coding now" link
> on that page when I'm active.
>
>     http://www.libsf.org/es2/tasks.html
>

Is this being picked up by the comedy channel in the fall?


-- 
Randy Howard
(replace the obvious text in the obvious way if you wish to contact me 
directly)

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

#90091

On Wednesday, July 6, 2016 at 1:39:03 PM UTC-4, Randy Howard wrote:
> On 7/4/16 12:43 PM, Rick C. Hodgin wrote:
> > You're welcome to watch me coding, Jacob.  There's a "live coding now" link
> > on that page when I'm active.
> >
> >     http://www.libsf.org/es2/tasks.html
> 
> Is this being picked up by the comedy channel in the fall?

Not to my knowledge.

Best regards,
Rick C. Hodgin

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

#89866

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
<snip>
> The much criticised "Malcolm call tree" would provide a list of all
> dependencies.

The simpler and less contrived static call graph also provides that (and
there are tools already in existence that construct it).

-- 
Ben.

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

#89871

Le 30/06/2016 à 20:51, Ben Bacarisse a écrit :
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> <snip>
>> The much criticised "Malcolm call tree" would provide a list of all
>> dependencies.
>
> The simpler and less contrived static call graph also provides that (and
> there are tools already in existence that construct it).
>

I programmed that in lcc-win's IDE.

I opened all the object files and extracted the exported/imported 
symbols. Then I arranges all C files in a circle and draw a line between 
each circle and any other if there were any calls in file A.c to B.c, say.

That gave interesting information, but well, nothing really spectacular. 
Actually a profiler is a much more interesting tool, not to speak of a 
debugger

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

#89896

On Thursday, June 30, 2016 at 8:59:55 PM UTC+1, jacobnavia wrote:
> Le 30/06/2016 à 20:51, Ben Bacarisse a écrit :
> > Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> > <snip>
> >> The much criticised "Malcolm call tree" would provide a list of all
> >> dependencies.
> >
> > The simpler and less contrived static call graph also provides that (and
> > there are tools already in existence that construct it).
> >
> 
> I programmed that in lcc-win's IDE.
> 
> I opened all the object files and extracted the exported/imported 
> symbols. Then I arranges all C files in a circle and draw a line between 
> each circle and any other if there were any calls in file A.c to B.c, say.
> 
> That gave interesting information, but well, nothing really spectacular. 
> Actually a profiler is a much more interesting tool, not to speak of a 
> debugger
>
No, you seldom actually draw the static call graph or the Malcolm call
tree (to update you, if you turn the graph into a tree, that's such a 
new idea that the others have named it after me).
You do need to have it in mind. In a well-structured program, you
actually have several tree of different granularity - the tree of
blocks, the function call tree, the file dependency tree, the module
or library dependency tree. Any of which is convertible to any
other and re-divisible.

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

#89852

On 30/06/2016 05:06, Ian Collins wrote:
> On 06/30/16 02:00 PM, Rick C. Hodgin wrote:
>>
>> The only thing forward declarations do is define things so they can be
>> used in source code.
>>
>> By removing the cproto step and having the compiler do that for you at
>> each compile, you are able to derive all definitions in the project.
>> And, by doing a standard top-down compile you can allow the redefinition
>> of things (if that's important to you), but that can also be done away
>> with and you can just give each thing a unique name or namespace/scope.
>>
>> Errors are reported when things aren't known.
>
> So you loose most of the benefits of incremental builds?
>
> Wouldn't your scheme require the compiler to check every source file to
> see if a function signature has changed and retain a cache of all the
> callers of all function in order to detect errors?

How does it work now?

You have, for example, 50 .c files and one .h file containing all shared 
function declarations that is included by all the .c files.

If an exported function changes in any .c file, the .h file must be 
manually updated, and that will trigger a recompile of all 50 .c files.

-- 
Bartc

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

#89854

On 06/30/16 10:32 PM, BartC wrote:
> On 30/06/2016 05:06, Ian Collins wrote:
>> On 06/30/16 02:00 PM, Rick C. Hodgin wrote:
>>>
>>> The only thing forward declarations do is define things so they can be
>>> used in source code.
>>>
>>> By removing the cproto step and having the compiler do that for you at
>>> each compile, you are able to derive all definitions in the project.
>>> And, by doing a standard top-down compile you can allow the redefinition
>>> of things (if that's important to you), but that can also be done away
>>> with and you can just give each thing a unique name or namespace/scope.
>>>
>>> Errors are reported when things aren't known.
>>
>> So you loose most of the benefits of incremental builds?
>>
>> Wouldn't your scheme require the compiler to check every source file to
>> see if a function signature has changed and retain a cache of all the
>> callers of all function in order to detect errors?
>
> How does it work now?
>
> You have, for example, 50 .c files and one .h file containing all shared
> function declarations that is included by all the .c files.
>
> If an exported function changes in any .c file, the .h file must be
> manually updated, and that will trigger a recompile of all 50 .c files.

So you don't put everything in one header.

-- 
Ian

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

#89859

On 30/06/2016 12:23, Ian Collins wrote:
> On 06/30/16 10:32 PM, BartC wrote:
>> On 30/06/2016 05:06, Ian Collins wrote:

>>> Wouldn't your scheme require the compiler to check every source file to
>>> see if a function signature has changed and retain a cache of all the
>>> callers of all function in order to detect errors?
>>
>> How does it work now?
>>
>> You have, for example, 50 .c files and one .h file containing all shared
>> function declarations that is included by all the .c files.
>>
>> If an exported function changes in any .c file, the .h file must be
>> manually updated, and that will trigger a recompile of all 50 .c files.
>
> So you don't put everything in one header.

How do you share declarations then across modules?

If there is a global function F used by all 50 modules M1 to M50, you 
either declare F in a single header H included in all M modules, or you 
have to duplicate the declaration for F in M1 to M50, possibly by 
creating headers H1 to H50.

The latter will solve your problems with parallel compilation (at a 
massive maintenance cost and a quadratic explosion in the number of 
header files), but if F changes, I don't see how you can avoid 
recompiling everything.

Now if you have some sort of supervisory system in place which keeps 
track of the definition of F and where it is referenced in all modules, 
then it can take care of all such details, including even generating the 
headers needed, and can invoke the minimal amount of re-compilations.

(Anyway, my current experiments with fast compilation suggests that a 
build system could simply do a pre-scan of all relevant modules to 
extract these dependencies, and it could do so /very/ much more quickly 
than a full compile. There are many possibilities.

Although if applied to current C, it would be dragged down by the 
complications introduced by its macro system, by conditional 
compilation, and the fact that subsequent compilation of the same header 
- with no source changes - might give a different result. (To say 
nothing about many C projects also depending heavily on external tools 
where the source might not even exist until just before compilation.)

In the absence of radically changing the language, strict guidelines and 
assumptions would need to be used when writing C projects, if such new 
approaches are to be useful.)

-- 
Bartc

[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