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

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

what is the best way

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

Contents

  what is the best way Andre <pas.mois@ailleur.be> - 2012-11-27 16:19 +0100
    Re: what is the best way Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-27 15:35 +0000
    Re: what is the best way Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-27 08:59 -0800
    Re: what is the best way James Kuyper <jameskuyper@verizon.net> - 2012-11-27 13:14 -0500
      Re: what is the best way Ian Collins <ian-news@hotmail.com> - 2012-11-28 08:43 +1300
        Re: what is the best way James Kuyper <jameskuyper@verizon.net> - 2012-11-27 15:02 -0500
          Re: what is the best way Ian Collins <ian-news@hotmail.com> - 2012-11-28 09:29 +1300
    Re: what is the best way Les Cargill <lcargill99@comcast.com> - 2012-11-27 12:48 -0600
      Re: what is the best way Ian Collins <ian-news@hotmail.com> - 2012-11-28 08:56 +1300
        Re: what is the best way Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-11-27 22:19 +0000
          Re: what is the best way Les Cargill <lcargill99@comcast.com> - 2012-11-27 18:21 -0600
            Re: what is the best way Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-28 05:08 -0800
              Re: what is the best way Les Cargill <lcargill99@comcast.com> - 2012-11-28 12:43 -0600
        Re: what is the best way Les Cargill <lcargill99@comcast.com> - 2012-11-27 18:15 -0600
          Re: what is the best way Ian Collins <ian-news@hotmail.com> - 2012-11-28 14:21 +1300
            Re: what is the best way Les Cargill <lcargill99@comcast.com> - 2012-11-27 20:06 -0600
              Re: what is the best way Ian Collins <ian-news@hotmail.com> - 2012-11-28 15:21 +1300
                Re: what is the best way Les Cargill <lcargill99@comcast.com> - 2012-11-27 20:31 -0600
                Re: what is the best way glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-28 04:00 +0000
                Re: what is the best way Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-28 05:17 -0800
                  Re: what is the best way Ian Collins <ian-news@hotmail.com> - 2012-11-29 08:30 +1300
                    Re: what is the best way Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-29 05:47 -0800
                      Re: what is the best way Ian Collins <ian-news@hotmail.com> - 2012-11-30 07:37 +1300
                        Re: what is the best way Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-11-29 11:35 -0800
      Re: what is the best way Keith Thompson <kst-u@mib.org> - 2012-11-27 17:25 -0800
        Re: what is the best way Les Cargill <lcargill99@comcast.com> - 2012-11-27 20:15 -0600
        Re: what is the best way pete <pfiland@mindspring.com> - 2012-11-27 23:48 -0500
      Re: what is the best way Sergio Durigan Junior <sergiodj@riseup.net> - 2012-11-28 03:06 -0200
        Re: what is the best way pete <pfiland@mindspring.com> - 2012-11-28 01:35 -0500
    Re: what is the best way pete <pfiland@mindspring.com> - 2012-11-28 00:13 -0500

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

#28745

Malcolm McLean wrote:
> On Wednesday, November 28, 2012 2:21:50 AM UTC, Ian Collins wrote:
>> Les Cargill wrote:
>>
>>> I dunno - at least conceptually, it's simpler for me if I hold
>>> to a separately compiled module being roughly a "class", where the
>>> header is the "interface".
>>
>> Ah, I see a different in metaphor here.
>>
>> I would describe the collection of source files (typically in their own
>> directory with a makefile) used to implement the interface declared in a
>> header as a module.  You appear to be describing an individual source
>> file as a module.
>>
> I try to keep one module per file.
>
> So, for example, lets say I'm writing a string-intensive program that does a
> lot of counting of characters. I might have one module that does DNA
> sequences, and another that does protein sequences.
> So they'll both have
>
> /* count the number of times ch appears in str */
> static int countchars(char *str, int ch)

You forgot the const :)

> defined in the source file, purely to keep modules as one file, depending
> on nothing else.

That looks like code duplication for the sake of a doctrine.  This 
sounds like a text book example of when to use a shared library.

> But if a file becomes too complex, I will reluctantly split it.

That depends on your definition of "too complex".  Another good reason 
for splitting is "too slow": when a monolithic file takes longer to 
compile than the equivalent set of smaller files.

-- 
Ian Collins

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

#28795

On Wednesday, November 28, 2012 7:30:21 PM UTC, Ian Collins wrote:
> Malcolm McLean wrote:
> 
> That looks like code duplication for the sake of a doctrine.  This 
> sounds like a text book example of when to use a shared library.
> 
It's not doctrine for the sake of doctrine. It's so I can take the file
dna.c, and have a list of functions that operate on dna sequences, which I
can use for another program. I can do the same with proteins.c. I can
take both files or one file, and they won't interact with each other.

-- 
Visit Malcolm's website
http://www.malcolmmclean.site11.com/www

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

#28809

Malcolm McLean wrote:
> On Wednesday, November 28, 2012 7:30:21 PM UTC, Ian Collins wrote:
>> Malcolm McLean wrote:
>>
>> That looks like code duplication for the sake of a doctrine.  This
>> sounds like a text book example of when to use a shared library.
>>
> It's not doctrine for the sake of doctrine. It's so I can take the file
> dna.c, and have a list of functions that operate on dna sequences, which I
> can use for another program. I can do the same with proteins.c. I can
> take both files or one file, and they won't interact with each other.

Or you could simply build a (shared) library.

-- 
Ian Collins

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

#28817

On Thursday, November 29, 2012 6:37:40 PM UTC, Ian Collins wrote:
> Malcolm McLean wrote:
> 
> > It's not doctrine for the sake of doctrine. It's so I can take the file
> > dna.c, and have a list of functions that operate on dna sequences, which I
> > can use for another program. I can do the same with proteins.c. I can
> > take both files or one file, and they won't interact with each other.
> 
> Or you could simply build a (shared) library.
> 
More trouble than it's worth.
You want to be able to distribute the source. The receiver can then compile 
it on his own system, hopefully just by typing cc *.c or an equivalent. He
doesn't want to have to mess about with libraries.

-- 
Visit Malcolm's website
http://www.malcolmmclean.site11.com/www

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

#28704

Les Cargill <lcargill99@comcast.com> writes:
[...]
> - Have this basic structure:
>
> thing.h:
>
> #ifndef _THING_H_
> #define _THING_H_ 1
> ...
> #endif
>
> guarding all header files.
[...]

Identifiers starting with an underscore and an uppercase letter
(or with two underscores) are reserved to the implementation for
any use; in other words, you should never use such identifiers in
your own code.

Just use this:

#ifndef THING_H
#define THING_H
...
#endif /* THING_H */

(or some scheme that maps reasonably well from file names to
identifiers without stepping on anything that's reserved).

Note that identifiers starting with E and either a digit or an
uppercase letter may be used for implementation-defined macros
in <errno.h>, so a header name that happens to start with E might
cause problems.  One way to avoid that is:

#ifndef H_THING
#define H_THING
...
#endif /* H_THING */

It's not terribly likely that an implementation is going to use
_THING_H_ or EXTRA_FOO for its own purposes, so you can very likely
get away with using such identifiers yourself, but if you avoid
reserved identifiers you have one less thing to worry about.

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

#28709

Keith Thompson wrote:
> Les Cargill <lcargill99@comcast.com> writes:
> [...]
>> - Have this basic structure:
>>
>> thing.h:
>>
>> #ifndef _THING_H_
>> #define _THING_H_ 1
>> ...
>> #endif
>>
>> guarding all header files.
> [...]
>
> Identifiers starting with an underscore and an uppercase letter
> (or with two underscores) are reserved to the implementation for
> any use; in other words, you should never use such identifiers in
> your own code.
>
> Just use this:
>
> #ifndef THING_H
> #define THING_H
> ...
> #endif /* THING_H */
>
> (or some scheme that maps reasonably well from file names to
> identifiers without stepping on anything that's reserved).
>


Excellent point. I *always* forget that. Apologies for the noise;
I simply meant "use guards on your header files."


> Note that identifiers starting with E and either a digit or an
> uppercase letter may be used for implementation-defined macros
> in <errno.h>, so a header name that happens to start with E might
> cause problems.  One way to avoid that is:
>
> #ifndef H_THING
> #define H_THING
> ...
> #endif /* H_THING */
>
> It's not terribly likely that an implementation is going to use
> _THING_H_ or EXTRA_FOO for its own purposes, so you can very likely
> get away with using such identifiers yourself, but if you avoid
> reserved identifiers you have one less thing to worry about.
>


--
Les Cargill

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

#28714

Keith Thompson wrote:
> 
> Les Cargill <lcargill99@comcast.com> writes:
> [...]
> > - Have this basic structure:
> >
> > thing.h:
> >
> > #ifndef _THING_H_
> > #define _THING_H_ 1
> > ...
> > #endif
> >
> > guarding all header files.
> [...]
> 
> Identifiers starting with an underscore and an uppercase letter
> (or with two underscores) are reserved to the implementation for
> any use; in other words, you should never use such identifiers in
> your own code.
> 
> Just use this:
> 
> #ifndef THING_H
> #define THING_H
> ...
> #endif /* THING_H */
> 
> (or some scheme that maps reasonably well from file names to
> identifiers without stepping on anything that's reserved).
> 
> Note that identifiers starting with E and either a digit or an
> uppercase letter may be used for implementation-defined macros
> in <errno.h>, so a header name that happens to start with E might
> cause problems.  One way to avoid that is:
> 
> #ifndef H_THING
> #define H_THING
> ...
> #endif /* H_THING */
> 
> It's not terribly likely that an implementation is going to use
> _THING_H_ or EXTRA_FOO for its own purposes, so you can very likely
> get away with using such identifiers yourself, but if you avoid
> reserved identifiers you have one less thing to worry about.

I use

#ifndef H_THING_H
#define H_THING_H

-- 
pete

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

#28716

On Tuesday, November 27 2012, Les Cargill wrote:

> Andre wrote:
>> to organize source in a multi soucres project.
>> Is a main.h file with every definition for every sources the best or
>> a each.h file for each.c file the best.
>> It's a verry loooong time last I used c.
>> André
>
>
> There is no "best". [...]

Agreed.

> - Have all the #includes needed for that .c file #included in the .h
> file. That way, if there are 7 c files, "grep "#include" *.c | wc "
> will
> be 7.

Not really sure I agree.  I prefer having my #includes in the .c,
because I believe the header file, if it needs to be included by other
.c files, must not interfere much with them, i.e., they shouldn't carry
other (possible obscure) header files that won't be needed for the .c
file(s).

But as you said, it's all IMO.  You suggestion still seems sensible to
me, much better than something I've read some days ago: "Why complicate?
Create one big .h file which #includes *everything* your project needs,
and then just #include it on the top of every .c file of your project".
Heh...

-- 
Sergio

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

#28721

Sergio Durigan Junior wrote:
> 
> On Tuesday, November 27 2012, Les Cargill wrote:
> 
> > Andre wrote:
> >> to organize source in a multi soucres project.
> >> Is a main.h file with every definition for every sources the best or
> >> a each.h file for each.c file the best.
> >> It's a verry loooong time last I used c.
> >> André
> >
> >
> > There is no "best". [...]
> 
> Agreed.
> 
> > - Have all the #includes needed for that .c file #included in the .h
> > file. That way, if there are 7 c files, "grep "#include" *.c | wc "
> > will
> > be 7.
> 
> Not really sure I agree.  I prefer having my #includes in the .c,
> because I believe the header file, if it needs to be included by other
> .c files, must not interfere much with them, i.e.,
> they shouldn't carry
> other (possible obscure) header files that won't be needed for the .c
> file(s).

I see it Sergio Durigan Junior's way.

If I'm writing <math.c>, then the text of <math.c> contains
#include <math.h>
#include <float.h>
#include <errno.h>
And the text of <math.h> contains no #includes.


But if I'm writing a *.h file 
that has size_t parameters in the function prototype declarations,
then *.h will have
#include <stddef.h>
and *.c will have
#include "*.h"

-- 
pete

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

#28717

Andre wrote:
> 
> to organize source in a multi soucres project.
> Is a main.h file with every definition for every sources the best or
> a each.h file for each.c file the best.
> It's a verry loooong time last I used c.
> André

I use main.h for two things:
1   declarations and definitions for main.c
2   declarations and definitions for each.h
Both or either of those things can be optional,
depending on how the program is written;
which is to say that there may or may not be a main.h

An example is here:

http://www.mindspring.com/~pfilandr/C/e_driver/

e_driver is a program in 6 files.
e_driver.h has typedefs, which all of the files use.

e_driver.h is #included in
e_driver.c, 
e_sort.h, and also in 
e_distributions.h

Here is a different example:

http://www.mindspring.com/~pfilandr/C/library/

libray is a program in 12 files.
There is a library.c, but there is no library.h

-- 
pete

[toc] | [prev] | [standalone]

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

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

csiph-web