Organisation of C programs

[Richard Evans]

Hello,

I am unsure of whether is Question is apt for this group, but
that has never stopped anybody else.

I believe I have a good understanding of the C language since my
last post many years ago about passing pointers in functions.

So now I am looking for resources describing how to layout and
organize the parts of a program into subdirectories, how to
include exported library headers, local headers and the overall
collection of common includes, include guards, and preprocessor
statements.

I thought I would give people something different to talk about.

Thanks in advance.

Richard

[Thomas Matthews]

Richard Evans wrote:

Hello,

I am unsure of whether is Question is apt for this group, but
that has never stopped anybody else.

I believe I have a good understanding of the C language since my
last post many years ago about passing pointers in functions.

So now I am looking for resources describing how to layout and
organize the parts of a program into subdirectories, how to
include exported library headers, local headers and the overall
collection of common includes, include guards, and preprocessor
statements.

I thought I would give people something different to talk about.

Thanks in advance.

Richard

This becomes a religious issue: everybody has their own
belief as to what is correct.

A common layout is:
Project
|
+-------
| |
docs source
|
----- include
Where the source contains all the ".c" files and the
include contains all the ".h" or header files.

I favor grouping by theme:

|
+-------------+---+----+--------+------------->
| | | |
utilities Flash UART Containers

In my opinion, this allows for better reuse of code.
Just point the search path to the correct directories.
I believe that processor specific code should be in
sub-directories under the themes (such as utilities
using processor specific features or assembly language).

I've only had one shop agree to to this. Most prefer to
dump all the files into one directory per project. That
way all the files can be easily duplicated for another
project (that is their definition of code reuse).

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book

[Rowland]

"Thomas Matthews" <Th****************************@sbcglobal.net> wrote in
message news:ht*****************@newssvr19.news.prodigy.co m...

Richard Evans wrote:
<snip>

So now I am looking for resources describing how to layout and
organize the parts of a program into subdirectories, how to
include exported library headers, local headers and the overall
collection of common includes, include guards, and preprocessor
statements.

<snip> This becomes a religious issue: everybody has their own
belief as to what is correct.

A common layout is:
Project
|
+-------
| |
docs source
|
----- include
Where the source contains all the ".c" files and the
include contains all the ".h" or header files.

I favor grouping by theme:

|
+-------------+---+----+--------+------------->
| | | |
utilities Flash UART Containers

In my opinion, this allows for better reuse of code.
Just point the search path to the correct directories.
I believe that processor specific code should be in
sub-directories under the themes (such as utilities
using processor specific features or assembly language).

I've only had one shop agree to to this. Most prefer to
dump all the files into one directory per project. That
way all the files can be easily duplicated for another
project (that is their definition of code reuse).

--
Thomas Matthews

I really like that, and think I might start doing it that way in future.
I've always tended to do it on a per-project basis, like you first
described. I would store all my projects in their own subdirectories of
\dev\null, but, as you say, code-reuse was impossible...

[Christopher Benson-Manica]

Thomas Matthews <Th****************************@sbcglobal.net> spoke thus:

I've only had one shop agree to to this. Most prefer to
dump all the files into one directory per project. That
way all the files can be easily duplicated for another
project (that is their definition of code reuse).

To a large extent, that's the definition I'm working under, and it's
pretty pitiful.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Richard Evans]

Christopher Benson-Manica wrote:

Thomas Matthews <Th****************************@sbcglobal.net> spoke thus:

I've only had one shop agree to to this. Most prefer to
dump all the files into one directory per project. That
way all the files can be easily duplicated for another
project (that is their definition of code reuse).

To a large extent, that's the definition I'm working under, and it's
pretty pitiful.

I have come across a book "Large scale C++ software Design" by Lakos.
It discusses layout based on dependencies of class friendship,
procedural and variable privacy and is very terse reading focussed
it seems on the C++ issues rather than its C issues.

I was after something specifically focussed on C.
While I don't want to be unix centric, introductions to the
automake/conf tools seem to briefly define some structure. This seems
like a significant details to focus someones experience into discussing.

[Richard Evans]

Thomas Matthews wrote:

Richard Evans wrote:

Hello,

I am unsure of whether is Question is apt for this group, but
that has never stopped anybody else.

I believe I have a good understanding of the C language since my
last post many years ago about passing pointers in functions.

So now I am looking for resources describing how to layout and
organize the parts of a program into subdirectories, how to
include exported library headers, local headers and the overall
collection of common includes, include guards, and preprocessor
statements.

I thought I would give people something different to talk about.

Thanks in advance.

Richard

This becomes a religious issue: everybody has their own
belief as to what is correct.

Does this mean you have had this discussion before or read about it
in a group? I would like to read it if you know when and where.

Richard

[Malcolm]

"Richard Evans" <ra******@hotmail.com> wrote

I have come across a book "Large scale C++ software Design" by Lakos.
It discusses layout based on dependencies of class friendship,
procedural and variable privacy and is very terse reading focussed
it seems on the C++ issues rather than its C issues.
The most important concept for code reuse is dependency. The more
dependencies a piece of code has, the less likely you are to reuse it. This
is true in C as well as C++.
I was after something specifically focussed on C.
While I don't want to be unix centric, introductions to the
automake/conf tools seem to briefly define some structure. This seems
like a significant details to focus someones experience into discussing.

My technique is this. We divide the source files into four groups.

1) Many programs, any platform. (eg a quaternion function for graphics)
2) Many programs, this platform only (eg a fast screen clear for a console)
3) This program only, any platform (eg AI for a space invader)
4) This program only, this platform only (eg the user interface)

You try to write the code so that as much goes into group 1 as possible and
as little into group 4 as possible.

It's a very simple procedure, but keeps things fairly neat. The fly in the
ointment is when code that is essentially in a low group depends on a minor
function that has to go in a higher group.