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]

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]

Richard Evans wrote:

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

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]

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.

 

[Richard Evans]

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]

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]

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.

 

[Joona I Palaste]

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

I suppose a subdirectory could be named \dev\null, but you'd have to
type it as \\dev\\null in the shell. However, it is as valid a
subdirectory as any other.
Or are you thinking of another punctuation mark? People keep telling me
there is nothing bad about two OSes having different path separators,
but I'm not so sure about that...