[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-chat] HowTo split a program into several files ?
From: |
Bernard Fouché |
Subject: |
Re: [avr-chat] HowTo split a program into several files ? |
Date: |
Mon, 12 Sep 2005 19:30:48 +0200 |
User-agent: |
Mozilla Thunderbird 1.0.2 (Windows/20050317) |
Till Harbaum wrote:
Hi,
On Monday 12 September 2005 18:10, Vincent Trouilliez wrote:
Okay I changed the <foo.c> for "foo.c" and the compiler is now
happy ! :o)
--
Vince, who can now keep his programs very tidy...
Uhm ... unfortunately noone told you, that this isn't the way to split
programs ... it works, but it's soooooo ugly.
Also:
- Use #include <...> when you want to include a header coming with the
system (i.e: provided by the compilation environment). Paths processed
by the preprocessor for '<..>' are defined in the preprocessor itself
and usually it's '/usr/include' plus eventually some others. You can add
paths to this with the -I option. For instance: -I/my/include/dir. The
point of "<..>" is to think that files included this way are well-known
ones and you don't really care where there are stored.
- Use #include "..." for files related to the application being compiled.
If you develop an application framework, and others programmers will use
it, then usually you do something like:
- /home/appframework/include <- will hold all .h related to the
application framework you provide. Inside you can have subdirs for
different 'modules' (for instance include/communications , include/setup
, etc)
- you will tell to programmers wanting to use your frame work that they
must add -I/home/appframework/include in their makefiles and use
#include <..> (of course you have to provide documentation telling what
include is needed to get what function prototype, etc)
- if such a programmer needs to make his/her own .h file, this file will
be included with #include "..."
- you will probably also provide /home/appframework/lib with libraries
to include (-L/home/appframework/lib -llibname..)
A big part of learning C is knowing these habits. If you known them and
stick to them, you'll feel at home very quickly when moving to a
compilation environment to another.
Another unsaid rule is that someone using a compilation environment or
an application framework requiring use of '<...>' to include /h files
must not modify these .h files since they can be upgraded at any time by
the provider of the application framework or compilation environment.
For instance there are actually a lot of talks about changing the API of
avr-libc. If you stick to the habit of including the avr-libc .h files
without modifying them, and locate all your own stuff and possible
changes in your own .h files, then chances are great that the API
changes will be transparent to you. Otherwise it can be a nightmare.
Other usuals C habits:
- use a #define each time you need a constant. For instance:
for(i=0;i<3;i++) is no good but
#define NBR_OF_NEEDED_SCANS
for(i=0;i<NBR_OF_NEEDED_SCANS;i++) is better
(this will document your source files in some way)
- Of course you locate all #define's in .h files
- use enums in any state machine using a switch/case system. Enums will
of course be defined in a .h file.
- constants are always in uppercase. Variable may have uppercases
letters but must has lower cases also.
- names beginning with '_' are reserved for the system designers.
- Do not allocate memory in a .h file, just define structures types,
typedef, enums, etc and make the memory allocation in a .c file.
For instance:
x.h:
enum toto { START, MIDDLE, END };
struct foo {
enum toto shmoo;
int bar;
int wuz;
}:
x.c
#include "x.h"
struct foo myfoo;
- etc.
C allows you to mess up everything since there are nearly no mandatory
requirements to organise your work. So some kind of organisation has to
exist and if you use the same one used by C programmers for decades
you'll spare a lot of time, it will help you feel that code you run into
that has been written by others could have been written by you.
Bernard
- [avr-chat] HowTo split a program into several files ?, Vincent Trouilliez, 2005/09/12
- Re: [avr-chat] HowTo split a program into several files ?, Andy Warner, 2005/09/12
- Re: [avr-chat] HowTo split a program into several files ?, Francisco Silva, 2005/09/12
- Re: [avr-chat] HowTo split a program into several files ?, Vincent Trouilliez, 2005/09/12
- Re: [avr-chat] HowTo split a program into several files ?, Vincent Trouilliez, 2005/09/12
- Re: [avr-chat] HowTo split a program into several files ?, Till Harbaum, 2005/09/12
- Re: [avr-chat] HowTo split a program into several files ?, Vincent Trouilliez, 2005/09/12
- Message not available
- Re: [avr-chat] HowTo split a program into several files ?, Vincent Trouilliez, 2005/09/12
- Re: [avr-chat] HowTo split a program into several files ?, Joerg Wunsch, 2005/09/12
- Re: [avr-chat] HowTo split a program into several files ?, Vincent Trouilliez, 2005/09/12
- Re: [avr-chat] HowTo split a program into several files ?, Vincent Trouilliez, 2005/09/12