This is a good example. When you say that the received and verified data needs to be "stored in various places", I think you're implying that there are several different SpecificBuffer[]s, and that each one will have a dedicated loop like the one in your "small embedded" example to copy contents of the GlobalSerialBuffer[] to the corresponding SpecificBuffer[].

If I've correctly understood what you're suggesting, then there are several points to be made:

• The first is the answer to your "WHY" question. The reason to spend some number of machine cycles on the overhead of the function call is so that you can hide the implementation of GlobalSerialBuffer[] from the other modules. Say that something changes and you suddenly have to accommodate a ten-byte message preamble that's sitting in the buffer, ahead of the 1024 bytes of data that the other modules care about. Or suppose that you want to change GlobalSerialBuffer[] from a linear buffer to a circular buffer of some kind.
  
  If your other modules pluck the data from GlobalSerialBuffer[] directly like you're suggesting, then you have to find and fix every single place that references the buffer. This creates a lot of redundant work, along with a corresponding number of opporunities to make silly mistakes. But if GlobalSerialBuffer[] is really just plain old SerialBuffer[], hidden from outside in its own module, and you access it through a getCharacter() function, you only have to change getCharacter().


• Your estimate of "something like 20*1024 machine cycles" for the function overhead is high by roughly 20*(1024-1) machine cycles, because you would not want to grab the characters one by one if you knew you were sometimes going to need them in big chunks. In that case, your serial module should provide a function with a prototype something like this:
  
  Save This Code

   
  void GetSerialData(char *pointerToCallersBuffer, int HowManyBytes);
   

  
  so that you get a whole buffer's worth of data with one call to the serial module. If the transfer was in fact a simple byte-to-byte copy, GetSerialData() could be a macro that translates into a call to the library routine memcpy(), which might be written in assembly language and might therefore be a little faster than code generated by the compiler. Otherwise (in the case of a circular buffer, for example) GetSerialData() would be a you-written function inside the serial module.


• I don't think you should dismiss the value of effort towards a design that is "pretty" and "safe". Those qualities contribute to programs that are robust and maintainable every bit as much as things like proper variable names, good comments, and careful formatting of the source code. And if you wind up "wasting" a few machine cycles on "pretty" and "safe", so what? Chances are really good that those machine cycles were going to be truly wasted in an idle loop somewhere anyway.

This is just plain wrong. Simply grouping related functions together into files is a step in the right direction, but that by itself doesn't buy you much of anything beyond making it easier to remember which file contains which functions.

The big point of modular programming is to make the modules independent, 1) so that changes in one of them don't break one or more of the others, and 2) so that you can extract a module from one project and reuse it elsewhere without having to drag along half of the first project to just to make it work. You simply cannot do these things if you allow your modules to muck around with each others' data.

-- Russ