[sdiy] OT (but very synthy): C question

[Tim Daugard]

>> I use LFO_H_ because it's easy to remember. A declaration xxx_H_
>> is only defined in the header file that contains it. That way any
>> file that needs that function can include it. I.E.
> 
> This works until your UTILS_H_ (or every generic name) collides with
> someone else's UTILS_H_ deep in a dependency. Hence the idea of adding
> a path or project-specific prefix to each header guard.

I like the idea of project specific prefix. All my work lately
 is programing for the MSP430 series chips. So i'm trying to create
 a generic series of headers to work with the various flavors
 of those chips.

I also have to stuff as much into headers as possible because I can't
 afford a lot of subroutine calling. Every subroutine call eats
 up 1/25? (approx) of all avaliable RAM. Inlining and tight
 definitions save me RAM. 

>> This should be at a higher level either the main.c
>> or a sub-level that includes both MIDI.h and LFO.h.
> 
> I think every public function related to midi should be declared in
> midi.h and implemented in midi.c ; and avoiding forward declarations
> is not a good reason to change this. To me, headers only have a

I agree. My comment is midi functions shouldn't contain pointers or
 structures for LFOs, VCOs etc. MIDI functions should receive a pointer
 to the data to be sent or return data received. Adding LFO functions in
 a midi.h or .c file is an invitation to later forget and have to search
 to fix a problem.   

> declarative value, hence they should contain only what is necessary to
> allow the declarations to be done. Another advantage of lightweight
> headers - with as many forward declarations as possible - and as
> little nested .h as possible - is the reduced number of dependencies.

Agree.

> This avoids the "contamination" of a change in the declaration of a
> struct to all the source files that only pass around a
> reference/pointer of this struct and which are not really bothered by
> the change. This doesn't really matter on an embedded project, but on
> projects with 100+ source files this helps a lot - so it's a good
> habit to take.

Actually, I find my self with far more source files for the embedded
 projects than I ever used on a normal computer. The files are small,
 but there are many to gather all the details. Each pin of the chip
 ends up with at least one file (except ground and power). It makes
 it easier to toubleshoot. It doesn't help that each pin of the
 MSP430 has multiple functions.

Tim,