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

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

Request for source code review

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

Contents

  Request for source code review Udyant Wig <udyantw@gmail.com> - 2012-08-30 00:49 +0530
    Re: Request for source code review Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-08-29 19:43 +0000
      Re: Request for source code review Udyant Wig <udyantw@gmail.com> - 2012-08-30 18:46 +0530
    Re: Request for source code review Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-29 22:27 +0100
      Re: Request for source code review Udyant Wig <udyantw@gmail.com> - 2012-08-30 09:44 +0530
      Re: Request for source code review Seungbeom Kim <musiphil@bawi.org> - 2012-09-07 17:31 -0700
        Re: Request for source code review Ian Collins <ian-news@hotmail.com> - 2012-09-08 12:41 +1200
        Re: Request for source code review Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 04:06 +0100
          Re: Request for source code review 88888 Dihedral <dihedral88888@googlemail.com> - 2012-09-07 23:50 -0700
            Re: Request for source code review Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 12:28 +0100
    Re: Request for source code review "BartC" <bc@freeuk.com> - 2012-08-29 22:58 +0100
      Re: Request for source code review Udyant Wig <udyantw@gmail.com> - 2012-08-30 09:48 +0530
    Re: Request for source code review Keith Thompson <kst-u@mib.org> - 2012-08-29 18:55 -0700
      Re: Request for source code review Udyant Wig <udyantw@gmail.com> - 2012-08-30 10:06 +0530
        Re: Request for source code review lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-29 21:59 -0700
          Re: Request for source code review Udyant Wig <udyantw@gmail.com> - 2012-08-30 18:51 +0530
        Re: Request for source code review Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-30 13:44 +0100
          Re: Request for source code review lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-09-12 03:24 -0700
      Re: Request for source code review Ian Collins <ian-news@hotmail.com> - 2012-08-30 17:04 +1200
        Re: Request for source code review James Kuyper <jameskuyper@verizon.net> - 2012-08-30 07:43 -0400
          Re: Request for source code review Ian Collins <ian-news@hotmail.com> - 2012-08-31 20:43 +1200
            Re: Request for source code review Les Cargill <lcargill99@comcast.com> - 2012-08-31 21:18 -0500
              Re: Request for source code review James Kuyper <jameskuyper@verizon.net> - 2012-09-01 20:34 -0400
                Re: Request for source code review Les Cargill <lcargill99@comcast.com> - 2012-09-01 20:45 -0500
                  Re: Request for source code review Ian Collins <ian-news@hotmail.com> - 2012-09-02 15:11 +1200
                    Re: Request for source code review Les Cargill <lcargill99@comcast.com> - 2012-09-01 23:43 -0500
        Re: Request for source code review Adrian Ratnapala <raka@scooter.fritz.box> - 2012-09-01 07:40 +0000
    Re: Request for source code review Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-30 05:10 -0700
      Re: Request for source code review Udyant Wig <udyantw@gmail.com> - 2012-08-30 19:14 +0530
        Re: Request for source code review Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-30 16:42 +0100
    Re: Request for source code review Udyant Wig <udyantw@gmail.com> - 2012-08-31 19:44 +0530
    Re: Request for source code review Udyant Wig <udyantw@gmail.com> - 2012-08-31 20:03 +0530
      Re: Request for source code review Keith Thompson <kst-u@mib.org> - 2012-08-31 13:34 -0700
        Re: Request for source code review Adrian Ratnapala <raka@scooter.fritz.box> - 2012-09-01 07:49 +0000
          Re: Request for source code review Keith Thompson <kst-u@mib.org> - 2012-09-01 02:53 -0700
      Re: Request for source code review pete <pfiland@mindspring.com> - 2012-08-31 21:15 -0400
    Re: Request for source code review Jan Kuiken <jan.kuiken@quicknet.nl> - 2012-08-31 19:55 +0200
      Re: Request for source code review Udyant Wig <udyantw@gmail.com> - 2012-09-02 15:39 +0530
        Re: Request for source code review Jan Kuiken <jan.kuiken@quicknet.nl> - 2012-09-02 19:57 +0200

Page 1 of 2  [1] 2  Next page →

#25426 — Request for source code review

I was following Steve Summit's C programming notes at
    http://www.eskimo.com/~scs/cclass/notes/top.html
and got inspired by the dice-rolling project.  I have written a naive
Gaussian distribution program that simulates throwing a specific number
of n-sided dice a given number of times.  The output is the expected
bell curve along with the numerical value of each sum's occurences.

For example, the output for 10000 rolls of three six-sided dice is:

 3: 51
 4: 148
 5: 260
 6: 454
 7: 686
 8: 969
 9: 1146
10: 1266
11: 1239
12: 1149
13: 1013
14: 713
15: 433
16: 280
17: 152
18: 41

 3: 
 4: =
 5: ==
 6: ====
 7: ======
 8: =========
 9: ===========
10: ============
11: ============
12: ===========
13: ==========
14: =======
15: ====
16: ==
17: =
18: 


Being a novice, I request the readers of this newsgroup to look over the
source to suggest improvements regarding readability, layout, style,
correctness, idioms, etc.  I would appreciate it very much.

I have placed the source files on Pastebin at this URL
http://pastebin.com/1PTVJrTN

In case anyone needs the Makefile, this is what I used:


CC = clang
FLAGS = -Wall -Wextra -std=c89 -pedantic

gauss: gauss.o main.o utils.o
	$(CC) $(FLAGS) -o gauss gauss.o main.o utils.o
gauss.o: gauss.c
	$(CC) $(FLAGS) -c gauss.c
main.o: main.c
	$(CC) $(FLAGS) -c main.c
utils.o: utils.c
	$(CC) $(FLAGS) -c utils.c

clean:  
	rm *.o gauss


Thank you.    

[toc] | [next] | [standalone]

#25430

On Wed, 2012-08-29, Udyant Wig wrote:
> I was following Steve Summit's C programming notes at
>     http://www.eskimo.com/~scs/cclass/notes/top.html
> and got inspired by the dice-rolling project.  I have written a naive
> Gaussian distribution program that simulates throwing a specific number
...
> I have placed the source files on Pastebin at this URL
> http://pastebin.com/1PTVJrTN
>
> In case anyone needs the Makefile, this is what I used:
...
> FLAGS = -Wall -Wextra -std=c89 -pedantic
...
> utils.o: utils.c
> 	$(CC) $(FLAGS) -c utils.c

Off-topic hint: if you call the flags CFLAGS instead of FLAGS, you can
skip the object file targets.  Gnu Make has builtin rules for such
things.  See the manual.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#25532

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
| Off-topic hint: if you call the flags CFLAGS instead of FLAGS, you can
| skip the object file targets.  Gnu Make has builtin rules for such
| things.  See the manual.
 That worked.

 I will have to study the manual at some point.
 
| /Jorgen

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

#25453

Udyant Wig <udyantw@gmail.com> writes:

> I was following Steve Summit's C programming notes at
>     http://www.eskimo.com/~scs/cclass/notes/top.html
> and got inspired by the dice-rolling project.  I have written a naive
> Gaussian distribution program that simulates throwing a specific number
> of n-sided dice a given number of times.  The output is the expected
> bell curve along with the numerical value of each sum's occurences.
<snip>
> Being a novice, I request the readers of this newsgroup to look over the
> source to suggest improvements regarding readability, layout, style,
> correctness, idioms, etc.  I would appreciate it very much.
>
> I have placed the source files on Pastebin at this URL
> http://pastebin.com/1PTVJrTN

I think it's good.

By the way, it's easier to comment on posted code though I know you were
probably worried about posting a long listing here.  It is longish, but
I think it's probably within the length where people are more likely to
read it when posted directly than when it's referenced on a sharing site.

Anyway, I have only a few of remarks:

* Why have the function 'd' in file on its own?  If it's going to be used
a lot other programs, it needs a much better name than 'd', and if it
isn't, why not just put it where it is used?  (Either way, 'd' is not
really a good name for it -- too sort whatever the use).

* It's widely regarded a good style to put parentheses round all
macro bodies that are anything more the a constant or an identifier.
One day you'll forget that you wrote

  #define LIMIT    (MAXSUM) + 1

and you'll write LIMIT * 2.

* I'd just initialise my array where it is declared:

  int sums[LIMIT] = {0};

rather than have an initsums function.

* Finally, I prefer to avoid having extra variables.  Rather than:

    int sum;                    /* Sum of the dice. */
    int i;

    for (i = 0; i < maxrolls; i++) {
        sum = sumdice (NDICE);
        ++sums [sum];
    }

I'd write:

    for (i = 0; i < maxrolls; i++)
        ++sums[ sumdice(NDICE) ];

For one thing, after a while, you run out of good names for them.
That's already happening here: 'sumdice' is a better name than 'sum'
i.e. the function name says more than the extra variable does.

Anyway, it's good.  Don't let my nit-picking get you down.

-- 
Ben.

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

#25494

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
| I think it's good.
 Thank you.
 
| By the way, it's easier to comment on posted code though I know you were
| probably worried about posting a long listing here.  It is longish, but
| I think it's probably within the length where people are more likely to
| read it when posted directly than when it's referenced on a sharing site.
 I had originally wanted to post the entire source here, but I had no
 idea about the acceptable source post length.

 I will keep your advice in mind, though.
 
| Anyway, I have only a few of remarks:
| * Why have the function 'd' in file on its own?  If it's going to be used
| a lot other programs, it needs a much better name than 'd', and if it
| isn't, why not just put it where it is used?  (Either way, 'd' is not
| really a good name for it -- too sort whatever the use).
 Makes sense.
 
| * It's widely regarded a good style to put parentheses round all
| macro bodies that are anything more the a constant or an identifier.
| One day you'll forget that you wrote
|   #define LIMIT    (MAXSUM) + 1
|
| and you'll write LIMIT * 2.
 I can see now how my current scheme could lead to nasty macroexpansion
 bugs when used carelessly.

| * I'd just initialise my array where it is declared:
|
|   int sums[LIMIT] = {0};
|
| rather than have an initsums function.
 I had forgotten about zero-initialization for arrays.  That function of
 mine seems highly redundant now.
 
| * Finally, I prefer to avoid having extra variables.  Rather than:
|
|     int sum;                    /* Sum of the dice. */
|     int i;
|
|     for (i = 0; i < maxrolls; i++) {
|         sum = sumdice (NDICE);
|         ++sums [sum];
|     }
|
| I'd write:
|
|     for (i = 0; i < maxrolls; i++)
|         ++sums[ sumdice(NDICE) ];
|
| For one thing, after a while, you run out of good names for them.
| That's already happening here: 'sumdice' is a better name than 'sum'
| i.e. the function name says more than the extra variable does.
 Sounds good.
 
| Anyway, it's good.  Don't let my nit-picking get you down.
 I think your remarks have made the code clearer to me.

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

#26107

On 2012-08-29 14:27, Ben Bacarisse wrote:
> 
> * Finally, I prefer to avoid having extra variables.  Rather than:
> 
>     int sum;                    /* Sum of the dice. */
>     int i;
> 
>     for (i = 0; i < maxrolls; i++) {
>         sum = sumdice (NDICE);
>         ++sums [sum];
>     }
> 
> I'd write:
> 
>     for (i = 0; i < maxrolls; i++)
>         ++sums[ sumdice(NDICE) ];

On the other hand, some people prefer that one statement should
do only one thing, and that also makes debugging easier: you can
insert a printf to examine the return value of sumdice, and in a
debugger you can pause the execution after calling sumdice but before
incrementing sums (with a breakpoint or by line-by-line execution).

I'd just limit the scope of the variable to the loop:

    int i;      /* in case you're stuck to C90 */

    for (i = 0; i < maxrolls; i++) {
        int sum = sumdice (NDICE);
	/* you could do printf("%d\n", sum) here */
        ++sums[sum];    /* you could set a breakpoint here */
    }

-- 
Seungbeom Kim

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

#26109

On 09/ 8/12 12:31 PM, Seungbeom Kim wrote:
> On 2012-08-29 14:27, Ben Bacarisse wrote:
>>
>> * Finally, I prefer to avoid having extra variables.  Rather than:
>>
>>      int sum;                    /* Sum of the dice. */
>>      int i;
>>
>>      for (i = 0; i<  maxrolls; i++) {
>>          sum = sumdice (NDICE);
>>          ++sums [sum];
>>      }
>>
>> I'd write:
>>
>>      for (i = 0; i<  maxrolls; i++)
>>          ++sums[ sumdice(NDICE) ];
>
> On the other hand, some people prefer that one statement should
> do only one thing, and that also makes debugging easier: you can
> insert a printf to examine the return value of sumdice, and in a
> debugger you can pause the execution after calling sumdice but before
> incrementing sums (with a breakpoint or by line-by-line execution).
>
> I'd just limit the scope of the variable to the loop:
>
>      int i;      /* in case you're stuck to C90 */
>
>      for (i = 0; i<  maxrolls; i++) {
>          int sum = sumdice (NDICE);
> 	/* you could do printf("%d\n", sum) here */
>          ++sums[sum];    /* you could set a breakpoint here */
>      }

An important point for the OP there is by declaring sum within the loop, 
the name can be reused elsewhere.  This reduces the chance of running 
out of good names!

-- 
Ian Collins

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

#26126

Seungbeom Kim <musiphil@bawi.org> writes:

> On 2012-08-29 14:27, Ben Bacarisse wrote:
>> 
>> * Finally, I prefer to avoid having extra variables.  Rather than:
>> 
>>     int sum;                    /* Sum of the dice. */
>>     int i;
>> 
>>     for (i = 0; i < maxrolls; i++) {
>>         sum = sumdice (NDICE);
>>         ++sums [sum];
>>     }
>> 
>> I'd write:
>> 
>>     for (i = 0; i < maxrolls; i++)
>>         ++sums[ sumdice(NDICE) ];
>
> On the other hand, some people prefer that one statement should
> do only one thing, and that also makes debugging easier: you can
> insert a printf to examine the return value of sumdice, and in a
> debugger you can pause the execution after calling sumdice but before
> incrementing sums (with a breakpoint or by line-by-line execution).
>
> I'd just limit the scope of the variable to the loop:
>
>     int i;      /* in case you're stuck to C90 */
>
>     for (i = 0; i < maxrolls; i++) {
>         int sum = sumdice (NDICE);
> 	/* you could do printf("%d\n", sum) here */
>         ++sums[sum];    /* you could set a breakpoint here */
>     }

That's a perfectly reasonable point of view.  I feel I should add,
though, that I've never felt at any disadvantage writing the way I do.
The debugger has usually been able to tell me what I need to know and
there are probably other factors that mean I don't feel the lack of
printfs in situations like the above.  I use them, but normally while
investigating failed tests of components.  I.e.  I might print from
sumdice while testing it, but once that's done I would not worry about
the particular combination in question.

-- 
Ben.

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

#26127

Ben Bacarisse於 2012年9月8日星期六UTC+8上午11時06分45秒寫道：
> Seungbeom Kim <musiphil@bawi.org> writes:
> 
> 
> 
> > On 2012-08-29 14:27, Ben Bacarisse wrote:
> 
> >> 
> 
> >> * Finally, I prefer to avoid having extra variables.  Rather than:
> 
> >> 
> 
> >>     int sum;                    /* Sum of the dice. */
> 
> >>     int i;
> 
> >> 
> 
> >>     for (i = 0; i < maxrolls; i++) {
> 
> >>         sum = sumdice (NDICE);
> 
> >>         ++sums [sum];
> 
> >>     }
> 
> >> 
> 
> >> I'd write:
> 
> >> 
> 
> >>     for (i = 0; i < maxrolls; i++)
> 
> >>         ++sums[ sumdice(NDICE) ];
> 
> >
> 
> > On the other hand, some people prefer that one statement should
> 
> > do only one thing, and that also makes debugging easier: you can
> 
> > insert a printf to examine the return value of sumdice, and in a
> 
> > debugger you can pause the execution after calling sumdice but before
> 
> > incrementing sums (with a breakpoint or by line-by-line execution).
> 
> >
> 
> > I'd just limit the scope of the variable to the loop:
> 
> >
> 
> >     int i;      /* in case you're stuck to C90 */
> 
> >
> 
> >     for (i = 0; i < maxrolls; i++) {
> 
> >         int sum = sumdice (NDICE);
> 
> > 	/* you could do printf("%d\n", sum) here */
> 
> >         ++sums[sum];    /* you could set a breakpoint here */
> 
> >     }
>
I like your code to generate the normal distribution without any floating 
point operations.

This is very helpful for 8-16-32 bit CPUs with slow floating point operations.

You can even write your own uniform distribution by linear feed back 
registers with some randomized seeds.

Anyway there's a theorem in statistics that
any  continuous real random variable distribution can be transformed
from the unit distribution in [0,1), but this requires floating point 
operations. 




 






 

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

#26130

88888 Dihedral <dihedral88888@googlemail.com> writes:
<snip>
> I like your code to generate the normal distribution without any floating 
> point operations.

Do you mean you would like it to?  As it is, it generates a binomial
distribution.  (It's not my code, by the way, I was merely commenting on
it.)

> This is very helpful for 8-16-32 bit CPUs with slow floating point operations.

Extending dice-rolling to approximate a normal distribution (in effect
relying on the central limit theorem) is not regarded as a good method.
I don't think this assessment changes even when floating point is
expensive.

-- 
Ben.

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

#25456

"Udyant Wig" <udyantw@gmail.com> wrote in message 
news:87bohty09k.fsf@panda.goosenet.in...

> Being a novice, I request the readers of this newsgroup to look over the
> source to suggest improvements regarding readability, layout, style,
> correctness, idioms, etc.  I would appreciate it very much.

> http://pastebin.com/1PTVJrTN

Your code looks beautiful.

-- 
Bartc 

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

#25495

"BartC" <bc@freeuk.com> writes:
| Your code looks beautiful.
 Thank you.

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

#25482

Udyant Wig <udyantw@gmail.com> writes:
[...]
> I have placed the source files on Pastebin at this URL
> http://pastebin.com/1PTVJrTN
>
> In case anyone needs the Makefile, this is what I used:
>
>
> CC = clang
> FLAGS = -Wall -Wextra -std=c89 -pedantic
>
> gauss: gauss.o main.o utils.o
> 	$(CC) $(FLAGS) -o gauss gauss.o main.o utils.o
> gauss.o: gauss.c
> 	$(CC) $(FLAGS) -c gauss.c
> main.o: main.c
> 	$(CC) $(FLAGS) -c main.c
> utils.o: utils.c
> 	$(CC) $(FLAGS) -c utils.c
>
> clean:  
> 	rm *.o gauss

This isn't directly a C issue, but your Makefile doesn't reflect any
dependencies on the *.h files.  For example, if you edit gauss.h and
type "make", it won't rebuild anything.

And you might as well use "-std=c99", or even "-std=c11" if you have a
new enough version of clang.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#25498

Keith Thompson <kst-u@mib.org> writes:
| This isn't directly a C issue, but your Makefile doesn't reflect any
| dependencies on the *.h files.  For example, if you edit gauss.h and
| type "make", it won't rebuild anything.
 I will have to learn to do that, then.
 
| And you might as well use "-std=c99", or even "-std=c11" if you have a
| new enough version of clang.
 I have been focusing on ANSI C90, the language as described in K&R 2nd
 ed.  Sadly, there won't be new editions of K&R to expound the later C
 standards.
 
 I understand that some of the useful new features of C99 include:
 * variable length arrays
 * a Boolean type
 * C++ comments
 * `for' loop variable declaration
 * struct initialization
 * the  long long  type
 * complex numbers
 
 Does there exist learning material for C99 as there does for C90?
 Or would I be better off learning C99 as a `patch' for C90?


 

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

#25501

On Thursday, August 30, 2012 4:36:23 AM UTC, Udyant Wig wrote:
> Keith Thompson <kst-u@mib.org> writes:
> 
> | This isn't directly a C issue, but your Makefile doesn't reflect any
> | dependencies on the *.h files.  For example, if you edit gauss.h and
> | type "make", it won't rebuild anything.
> 
>  I will have to learn to do that, then.
> 

try my little Auto Makefile

https://github.com/jhlicc/Visual-Stupid-Makefile/blob/master/Makefile

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

#25534

lovecreatesbeauty <lovecreatesbeauty@gmail.com> writes:
|>  I will have to learn to do that, then.
|> 
|
| try my little Auto Makefile
|
| https://github.com/jhlicc/Visual-Stupid-Makefile/blob/master/Makefile
 That looks interesting.  It should prove useful.

 It says on line 3:

 # .c and Makefile in src, .h can be in include, no other directories.

 Do the headers need to be in  src  or beside it?

 

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

#25529

Udyant Wig <udyantw@gmail.com> writes:

> Keith Thompson <kst-u@mib.org> writes:
> | This isn't directly a C issue, but your Makefile doesn't reflect any
> | dependencies on the *.h files.  For example, if you edit gauss.h and
> | type "make", it won't rebuild anything.
>  I will have to learn to do that, then.
>  
> | And you might as well use "-std=c99", or even "-std=c11" if you have a
> | new enough version of clang.
>  I have been focusing on ANSI C90, the language as described in K&R 2nd
>  ed.  Sadly, there won't be new editions of K&R to expound the later C
>  standards.
>  
>  I understand that some of the useful new features of C99 include:
>  * variable length arrays
>  * a Boolean type
>  * C++ comments
>  * `for' loop variable declaration
>  * struct initialization

They are called "compound literals".  "Old" C has struct initialisation,
so that's not a good term for it.  What C99 adds is the ability to
"denote" an unnamed struct object:

  plot((struct point){3, 4});

>  * the  long long  type
>  * complex numbers
>  
>  Does there exist learning material for C99 as there does for C90?
>  Or would I be better off learning C99 as a `patch' for C90?

I'd do it that way.  If you find K&R's style suits you, there is
really no better way to start and C99's extras are small.

VLAs are the most involved, I think, and they have been made optional in
C11.  That's a crying shame to my mind, but that's how things have
panned out.  No one who's implemented VLAs will remove the support, but
it makes them a second-class feature of the language.

-- 
Ben.

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

#26236

On Thursday, August 30, 2012 12:44:04 PM UTC, Ben Bacarisse wrote:
> 
> VLAs are the most involved, I think, and they have been made optional in
> C11.  That's a crying shame to my mind, but that's how things have
> panned out.  No one who's implemented VLAs will remove the support, but
> it makes them a second-class feature of the language.
> 

The new introduced important "thread" feature is optional in C11.
The old VLA is made optional by C11 too.
This standard revision sucks.

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

#25502

On 08/30/12 01:55 PM, Keith Thompson wrote:
> Udyant Wig<udyantw@gmail.com>  writes:
> [...]
>> I have placed the source files on Pastebin at this URL
>> http://pastebin.com/1PTVJrTN
>>
>> In case anyone needs the Makefile, this is what I used:
>>
>>
>> CC = clang
>> FLAGS = -Wall -Wextra -std=c89 -pedantic
>>
>> gauss: gauss.o main.o utils.o
>> 	$(CC) $(FLAGS) -o gauss gauss.o main.o utils.o
>> gauss.o: gauss.c
>> 	$(CC) $(FLAGS) -c gauss.c
>> main.o: main.c
>> 	$(CC) $(FLAGS) -c main.c
>> utils.o: utils.c
>> 	$(CC) $(FLAGS) -c utils.c
>>
>> clean:
>> 	rm *.o gauss
>
> This isn't directly a C issue, but your Makefile doesn't reflect any
> dependencies on the *.h files.  For example, if you edit gauss.h and
> type "make", it won't rebuild anything.

A decent make should provide a means for automating this.  Otherwise 
where do you stop recursing up the include paths?

-- 
Ian Collins

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

#25523

On 08/30/2012 01:04 AM, Ian Collins wrote:
> On 08/30/12 01:55 PM, Keith Thompson wrote:
...
>> This isn't directly a C issue, but your Makefile doesn't reflect any
>> dependencies on the *.h files.  For example, if you edit gauss.h and
>> type "make", it won't rebuild anything.
> 
> A decent make should provide a means for automating this.  Otherwise 
> where do you stop recursing up the include paths?

I've used a "decent" make that was part of a configuration management
system called ClearCase, which fully automated the tracking of
dependencies, but by rather drastic means. Whenever clearmake executed
the build script for a given target, it would monitor the processes that
were executed, keeping track of ALL files that were opened during the
build. If they were versioned files managed by ClearCase, it identified
which version of the file was currently visible; for other files it just
looked at the file date. The next time that the same target was built,
it would check to see whether any of the files that had been opened the
last time had been changed, and if so, it assumed that the build script
had to be re-executed.

One of the key things that made this work was that the make facility was
tightly integrated with a special device driver that managed access to
disk space; only the use of files stored on disk volumes managed by that
driver could be detected.

After paying the rather hefty license fees for such sophisticated
software, guess how it was used: whenever we delivered new code, CM
would build it using the option that forced a complete re-build,
regardless of dependencies.
-- 
James Kuyper

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web