On Tue, 2009-06-30 at 21:50 -0400, Duane Ellis wrote: > Zach> However, I would rather see you move some of the things in the C file > Zach> into the H file (all of the #defines and struct declarations, to > start). > Zach> Basically, use it as the driver's private header file. > > duane> None of those defines are *PUBLIC*. > duane> None of those structures are *PUBLIC*. > > zach> Read what I said again: "private header file". Just because > something is > zach> in a header file does not mean it is a public contract. However, > zach> putting this into your terms: moving those definitions to H file helps > zach> define the "contract" for the C file. > > I disagree 100% percent. You seem to suggest that major systems such as > GCC, GDB, the Linux Kernel, to name but a few - are wrong in this widely > used approach.
Private header files seem fairly standard way of separating declarations from definitions. I imagine that I could find some of what I have described in all of the projects that you mention. Heck, I have worked on patches for the Linux kernel that included private header files, and they were allowed for the reasons that should become clear below. > A header file is something any one can "#include", and thus defines a > public interface, there is no means to enforce the > 'this-is-private-do-not-touch' rule. There is no rule that prevents you from committing layering violations. The layers still need to be exposed, and it is your responsibility to understand how the pieces fit together and use them properly. How is this situation any different? There are small (if private) layers here. > How does this "help define the contract for the C file"? Changes to that file define the part and have impact on the entire module, whereas the C file implements using that the specification in the context of others (i.e. the flash interface). Using an H file separates declaration from definition clearly and aids future factoring efforts to improve modularity. Specifically, it allows this C module to be split into two pieces: "core" and "TCL command" modules. This then allows future development of alternative command modules (e.g. native C calls to the core flash module, or built-in command modules for other interpreted languages). In this way, I wrote a Linux kernel module that used a "private" header to share the "contract" between a USB device driver, its /proc driver, and other optionally configurable sub-modules. Sadly, that driver was killed because of GPL licensing issues with the device firmware, but it had passed review by GKH through private exchanges (back in '01, iirc). Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
