Text 24, 84 rader
Skriven 2004-07-27 18:54:38 av George White (2:250/501.3)
     Kommentar till text 13 av Jasen Betts (3:640/1042)
Ärende: [C] Code File Structure
===============================
Hi Jasen,

On 26-Jul-04, Jasen Betts wrote to Bruce Partridge:

 BP>> I'm a long time programmer, but I have only been using C for the
 BP>> last couple of years.

 BP>> I'm interested in finding a document or book that explains how to
 BP>> split modules into files.  I have done several different things,
 BP>> and none of them seem perfect.

There is _no_ perfect way.

 BP>> Global and local variables seem to be obvious, but where is the
 BP>> "normal" place to put hardware defines.  For example, I use
 BP>> hardware defines that only apply if I have a certain type of
 BP>> temperature sensor.  A different sensor uses different defines.
 BP>> Should these be in a global hw.h file or in the module code file.

 JB> putting them in the module code or in a temp_hw.h file that only
 JB> the terperature module uses will save the module being rebullt is
 JB> only some other hardware is changed. (and save other hardware
 JB> modules being rebuilt if ont the temperature harware is changed) -
 JB> I'm assuming you've got some sort of "make" or other
 JB> dependancy-savvy system doing your builds..

I would put them in a "temp_hw.h" file.

 BP>> And where do you define enums that are used in several modules.

 JB> in a header file (.h) that's included by all the modules that use
 JB> that that enum type

Yep...

 JB> global variables can be declared "extern" in the same header, as
 JB> long as exactly one module (.c) declares them for real

I prefer to put my "extern"s in the body of the file rather than a
header file. It's very much a personal choice.

 JB> there may be some instances where there's stuff that's in the
 JB> header that not all modules want. but that's hopefully no big
 JB> deal... look at all the crud in <stdlib.h> or <stdio.h>
 JB> sometime.

Provided it does not instantiate it's no problem at all...
Most of my headers have prototypes and defines for stuff that most
modules don't need, but have to be there because of other modules.
Unless you build your code on the "one function, one header" approach
that is inevitable. I prefer to put closely related functions
together, I find it more convenient _for_ _me_. Or routines that use a
common variable that nothing else needs to see. It's very much a
matter of personal choice :-).

 BP>> I also have questions about reusable code, and how to optimally
 BP>> split up the files.

 JB> that's a slippery one, by my tow cents - eitther develop your
 JB> resuable stuff lika a "library" or set of libraries.  (eg the
 JB> stuff in the math library "libm") whaere there's a single .h file
 JB> that covers the application priggrammer's interface (API if it's
 JB> just random bits you (not relating to the same sort of tasks) that
 JB> you feel might be handy, just make them easy to find the next time
 JB> you'l want them. after reusing them via cut and paste a few times
 JB> they mayevolve into something general enought for their own
 JB> library...

I put my re-useable code into separate modules as much of it is
controlled by #defines in a site.h header files via #ifdef, #if,
#elif and #else clauses, or set constants that change between builds for
different customers. I leave the "make" to sort it all out for me
(that includes the differences between production builds, with symbol
info stripped out as well as certain test convenience code disabled,
and development builds - ie. "CTL-Q" will shutdown a development build
but not a production one). So I don't have a personal library of code
for the product, it could be built that way but it didn't suit my
personal development style.


George

--- Terminate 5.00/Pro 
 * Origin: George's Country Point (2:250/501.3)