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

#28682 — what is the best way

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é

[toc] | [next] | [standalone]

#28683

Andre <pas.mois@ailleur.be> writes:

| what is the best way
> 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.

The latter is more common and easier to understand later.

Not every .c file will have a .h file (the file defining main, for
example, very often will not define anything that other modules need to
see) and not all .h file will correspond to a .c file (for example a
. file that contains nothing but macros, types and inline functions).

-- 
Ben.

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

#28685

On Tuesday, November 27, 2012 3:19:24 PM UTC, 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.
> 
Arrange the functions logically in modules. Normally you'll only want to 
export a subset of the functions in each module, the others won't make
any sense except as subroutines to the other functions. 
Put these in a matching .h file. Add #include guards (#ifndef myfile_h
#define myfile_h /* prototypes here */ #endif ).
It's better to make each .h includeable on its own. So it needs to internally
#include any dependencies.

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

 

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

#28688

On 11/27/2012 10:19 AM, 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.

There's lots of different ways to do this. My own convention has been to
create one header file for each module, which will in general contain
multiple function definitions, but usually only one with external
linkage. The header file will provide declarations for every identifier
with external linkage defined in that module. If there are no such
identifiers (this is often the case for the module which defines
main()), no header is needed. The header will also contain definitions
for every typedef and every struct, union, or enumeration needed by
those declarations. If there are any special values associated with the
arguments or return value of any of the functions it declares, it will
#define macros for those values. Every #define and type definition will
appear explicitly only in one particular header file; they will be
#included into any other header where needed.
For libraries, the headers associated with each module in the library
are used only for compiling those modules. I prepare a special header
for users of the library, declaring only those identifiers with external
linkage that users are intended to access, along with the associated
types and macros.

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

#28691

James Kuyper wrote:
> On 11/27/2012 10:19 AM, 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.
>
> There's lots of different ways to do this. My own convention has been to
> create one header file for each module, which will in general contain
> multiple function definitions, but usually only one with external
> linkage.

Either I'm parsing that wrong, or you've written it wrong.  How and why 
would you have a function declaration in a (public) header if it doesn't 
have external linkage?

-- 
Ian Collins

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

#28693

On 11/27/2012 02:43 PM, Ian Collins wrote:
> James Kuyper wrote:
>> On 11/27/2012 10:19 AM, 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.
>>
>> There's lots of different ways to do this. My own convention has been to
>> create one header file for each module, which will in general contain
>> multiple function definitions, but usually only one with external
>> linkage.
> 
> Either I'm parsing that wrong, or you've written it wrong.  How and why 
> would you have a function declaration in a (public) header if it doesn't 
> have external linkage?

The "which will ..." clause was describing the module, not the header
file. I agree that I should have written that more clearly. How about this:

I generally create modules which may contain multiple function
definitions, but usually only one with external linkage. My convention
has been to create one header file for each module.

Is that better?

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

#28694

James Kuyper wrote:
> On 11/27/2012 02:43 PM, Ian Collins wrote:
>> James Kuyper wrote:
>>> On 11/27/2012 10:19 AM, 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.
>>>
>>> There's lots of different ways to do this. My own convention has been to
>>> create one header file for each module, which will in general contain
>>> multiple function definitions, but usually only one with external
>>> linkage.
>>
>> Either I'm parsing that wrong, or you've written it wrong.  How and why
>> would you have a function declaration in a (public) header if it doesn't
>> have external linkage?
>
> The "which will ..." clause was describing the module, not the header
> file. I agree that I should have written that more clearly. How about this:
>
> I generally create modules which may contain multiple function
> definitions, but usually only one with external linkage. My convention
> has been to create one header file for each module.
>
> Is that better?

Yes :)

-- 
Ian Collins

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

#28689

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". Still:

- Have one header .h per .c file.
- 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.

- Have this basic structure:

thing.h:

#ifndef _THING_H_
#define _THING_H_ 1
...
#endif

guarding all header files.

- Use "gcc -M *.c > .depend" ( or equivalent ) in your makefile. Then if
you want, use "source .depend" or "include .depend" at the bottom.

- Don't have an "includes" or "headers" directory for .h files unless
you somehow need to.

All IMO.


--
Les Cargill

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

#28692

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". Still:
>
> - Have one header .h per .c file.

That isn't necessarily a good idea.  If a header declares the interface 
to a module or library, the functions declared in the header are often 
defined in more than one C file.

How to manage interface declarations and implementations really depends 
on the the complexity of the application and the environment.  In most 
large projects I've seen or worked on there are a mix of public and 
module private headers.  OS libraries are a good example of this, there 
will be a public header which ends up being part of the end user 
distribution and private headers that never leave the private source tree.

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

This practice often causes more trouble than it is worth.

> - Have this basic structure:
>
> thing.h:
>
> #ifndef _THING_H_
> #define _THING_H_ 1

The 1 is unusual and superfluous.

-- 
Ian Collins

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

#28699

On Tue, 2012-11-27, Ian Collins wrote:
> 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". Still:
>>
>> - Have one header .h per .c file.
>
> That isn't necessarily a good idea.  If a header declares the interface 
> to a module or library, the functions declared in the header are often 
> defined in more than one C file.

I took it to be more of a rule of thumb.

> How to manage interface declarations and implementations really depends 
> on the the complexity of the application and the environment.
...

>> - 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.
>
> This practice often causes more trouble than it is worth.

Yes -- that seems highly unusual and impractical.  E.g. anyone who
wants to use the interface provided by foo.h will be poisoned by
everything needed to implement foo.c!

Note that this is distinct from the idea of idempotent header files --
the idea that foo.h doesn't have a secret "shopping list" of other
header files which must be included first to make '#include "foo.h"'
compile.

/Jorgen

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

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

#28701

Jorgen Grahn wrote:
> On Tue, 2012-11-27, Ian Collins wrote:
>> 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". Still:
>>>
>>> - Have one header .h per .c file.
>>
>> That isn't necessarily a good idea.  If a header declares the interface
>> to a module or library, the functions declared in the header are often
>> defined in more than one C file.
>
> I took it to be more of a rule of thumb.
>


That's the intention.

>> How to manage interface declarations and implementations really depends
>> on the the complexity of the application and the environment.
> ...
>
>>> - 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.
>>
>> This practice often causes more trouble than it is worth.
>
> Yes -- that seems highly unusual and impractical.  E.g. anyone who
> wants to use the interface provided by foo.h will be poisoned by
> everything needed to implement foo.c!
>


I've never found this to be a significant burden, but I do spend
some time in trying to make interfaces as clean as possible.

This was shop standard and was how some case tools did it, and
I never bothered to go back to the old way.

> Note that this is distinct from the idea of idempotent header files --
> the idea that foo.h doesn't have a secret "shopping list" of other
> header files which must be included first to make '#include "foo.h"'
> compile.

Yeah, I don't like that at all, and that's one reason I like having all
foo.c 's dependencies explicit in foo.h.

>
> /Jorgen
>

--
Les Cargill

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

#28729

On Wednesday, November 28, 2012 12:21:24 AM UTC, Les Cargill wrote:
> Jorgen Grahn wrote:
> 
> > Yes -- that seems highly unusual and impractical.  E.g. anyone who
> > wants to use the interface provided by foo.h will be poisoned by
> > everything needed to implement foo.c!
> 
> 
> I've never found this to be a significant burden, but I do spend
> some time in trying to make interfaces as clean as possible.
> 
> 
The problem is that whizzbanggui.c contains the typedef of a struct point.
You're implementing pythagoras, which takes two points. So naturally they
get passed as struct points. But now everyone has to pull in the whole of
whizzbanggui, just to use that trivial definition.
If you define your own struct Point / struct myPoint, then you need adapter
code to convert between two identical structures when calling pythagoras
and whizzbanggui from the same program. So that's not a good solution either. 

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

#28740

Malcolm McLean wrote:
> On Wednesday, November 28, 2012 12:21:24 AM UTC, Les Cargill wrote:
>> Jorgen Grahn wrote:
>>
>>> Yes -- that seems highly unusual and impractical.  E.g. anyone who
>>> wants to use the interface provided by foo.h will be poisoned by
>>> everything needed to implement foo.c!
>>
>>
>> I've never found this to be a significant burden, but I do spend
>> some time in trying to make interfaces as clean as possible.
>>
>>
> The problem is that whizzbanggui.c contains the typedef of a struct point.

Uh oh.

> You're implementing pythagoras, which takes two points. So naturally they
> get passed as struct points. But now everyone has to pull in the whole of
> whizzbanggui, just to use that trivial definition.

There's an entire ... discipline? in the art of stacking boxes
on top of other boxes so that everything is covered. Bad as I hate to 
admit it, to my ear, a "point" is an object and unless it has
exactly one client/user, it has to be published in a reasonable manner.

Maybe you have a "primiTypes.h". Maybe you have "point.h".

> If you define your own struct Point / struct myPoint, then you need adapter
> code to convert between two identical structures when calling pythagoras
> and whizzbanggui from the same program. So that's not a good solution either.
>

Or you could make "point" either completely independent in the two, or 
make "point" a standalone object, or....


--
Les Cargill

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

#28700

Ian Collins wrote:
> 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". Still:
>>
>> - Have one header .h per .c file.
>
> That isn't necessarily a good idea.  If a header declares the interface
> to a module or library, the functions declared in the header are often
> defined in more than one C file.
>


But it's easier for me to use it to publish only stuff that's in
one 'C' file. I realize people do this in other ways, but I've
never found a case where this didn't work out...

I have published libraries with *only* the constituent headers - an
example is a signals processing library I wrote which laid over fftw-3 
and libsndfile. If you want the "fft" part, you include fft.h; reverse
fft requires rfft.h

A library is, after all, just an archive...

> How to manage interface declarations and implementations really depends
> on the the complexity of the application and the environment.  In most
> large projects I've seen or worked on there are a mix of public and
> module private headers.  OS libraries are a good example of this, there
> will be a public header which ends up being part of the end user
> distribution and private headers that never leave the private source tree.
>

For an O/S or compiler library, that's quite a different thing - if
you're building under Unix path assumptions, then you are forced to
at least have public headers.

But IMO, everything in a ... non-infrastructure library
should be public and on the same level. And this convention
makes mixing 'C' and C++ much easier... plus it's much more grep-friendly.

'Course, if you're backing into somebody else's arrangement,
you are better off conforming...

>> - 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.
>
> This practice often causes more trouble than it is worth.
>
>> - Have this basic structure:
>>
>> thing.h:
>>
>> #ifndef _THING_H_
>> #define _THING_H_ 1
>
> The 1 is unusual and superfluous.
>

It's cheap :) Doesn't eat much.

--
Les Cargill

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

#28702

Les Cargill wrote:
> Ian Collins wrote:
>> Les Cargill wrote:
>>>
>>> There is no "best". Still:
>>>
>>> - Have one header .h per .c file.
>>
>> That isn't necessarily a good idea.  If a header declares the interface
>> to a module or library, the functions declared in the header are often
>> defined in more than one C file.
>
> But it's easier for me to use it to publish only stuff that's in
> one 'C' file. I realize people do this in other ways, but I've
> never found a case where this didn't work out...

Fair enough.  I prefer more smaller C files over one bigger one, so my 
public headers tend to cover a group of files.

> I have published libraries with *only* the constituent headers - an
> example is a signals processing library I wrote which laid over fftw-3
> and libsndfile. If you want the "fft" part, you include fft.h; reverse
> fft requires rfft.h
>
> A library is, after all, just an archive...

Take care with your terminology there, dynamic libraries are often 
different beasts from static archives.

>> How to manage interface declarations and implementations really depends
>> on the the complexity of the application and the environment.  In most
>> large projects I've seen or worked on there are a mix of public and
>> module private headers.  OS libraries are a good example of this, there
>> will be a public header which ends up being part of the end user
>> distribution and private headers that never leave the private source tree.
>>
>
> For an O/S or compiler library, that's quite a different thing - if
> you're building under Unix path assumptions, then you are forced to
> at least have public headers.
>
> But IMO, everything in a ... non-infrastructure library
> should be public and on the same level. And this convention
> makes mixing 'C' and C++ much easier...

I don't see why that would be the case.  C++ happily uses system C 
libraries and there's nothing to stop you witting a library with a C 
interface entirely or partially in C++.

 > plus it's much more grep-friendly.

find is your friend!

> 'Course, if you're backing into somebody else's arrangement,
> you are better off conforming...

Yep.

-- 
Ian Collins

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

#28708

Ian Collins wrote:
> Les Cargill wrote:
>> Ian Collins wrote:
>>> Les Cargill wrote:
>>>>
>>>> There is no "best". Still:
>>>>
>>>> - Have one header .h per .c file.
>>>
>>> That isn't necessarily a good idea.  If a header declares the interface
>>> to a module or library, the functions declared in the header are often
>>> defined in more than one C file.
>>
>> But it's easier for me to use it to publish only stuff that's in
>> one 'C' file. I realize people do this in other ways, but I've
>> never found a case where this didn't work out...
>
> Fair enough.  I prefer more smaller C files over one bigger one, so my
> public headers tend to cover a group of files.
>


I too prefer smaller ones. Perhaps working with CASE tools that
ended evolution in UML destroyed my good sense :), but that's
how they roll - lots of small files, each with a minimum
of side effects.

In the example I gave, I don't think any of the source or
header  files were over 100 lines, blank lines and comments
included.

>> I have published libraries with *only* the constituent headers - an
>> example is a signals processing library I wrote which laid over fftw-3
>> and libsndfile. If you want the "fft" part, you include fft.h; reverse
>> fft requires rfft.h
>>
>> A library is, after all, just an archive...
>
> Take care with your terminology there, dynamic libraries are often
> different beasts from static archives.
>

I suppose... although I can easily think of a .so or .dll as
nothing more than a fancier container... YMMV.

>>> How to manage interface declarations and implementations really depends
>>> on the the complexity of the application and the environment.  In most
>>> large projects I've seen or worked on there are a mix of public and
>>> module private headers.  OS libraries are a good example of this, there
>>> will be a public header which ends up being part of the end user
>>> distribution and private headers that never leave the private source
>>> tree.
>>>
>>
>> For an O/S or compiler library, that's quite a different thing - if
>> you're building under Unix path assumptions, then you are forced to
>> at least have public headers.
>>
>> But IMO, everything in a ... non-infrastructure library
>> should be public and on the same level. And this convention
>> makes mixing 'C' and C++ much easier...
>
> I don't see why that would be the case.  C++ happily uses system C
> libraries and there's nothing to stop you witting a library with a C
> interface entirely or partially in C++.
>

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

You don't want to overdo it, of course.

>  > plus it's much more grep-friendly.
>
> find is your friend!
>

Couldn't agree more! But it's slightly better if you don't
need to resort to it.

>> 'Course, if you're backing into somebody else's arrangement,
>> you are better off conforming...
>
> Yep.
>

--
Les Cargill

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

#28710

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.

So if that's the case, we both have one header per module :)

-- 
Ian Collins

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

#28711

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.
>
> So if that's the case, we both have one header per module :)
>


Well, there ya go. :)

--
Les Cargill

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

#28713

Ian Collins <ian-news@hotmail.com> wrote:

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

If you follow the source module goes to object module, and use
one procedure/method per file, then it is more obvious with one
source module per file.

Many languages separately compile procedures in one file, but C doesn't.
 
> So if that's the case, we both have one header per module :)

-- glen

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

#28731

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)

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

But if a file becomes too complex, I will reluctantly split it.
-- 
Visit Malcolm's homepage
http://www.malcolmmclean.site11.com/www
 

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web