On Tue, 6 Dec 2005, Ethan Dicks wrote: > On Tue, Dec 06, 2005 at 12:46:32PM -0800, Deepak Saxena wrote: > > I really think we need a rule in Documentation/CodingStyle that says > > "Thou shalt not #include .c files from .c files." > > Wow! And I thought that was universally understood as a Bad Idea. > > I'd endorse that rule.
It does make sense to #include .c files on occasion. The example I have in mind is a single very large source file that you would like to divide up into pieces for easier handling. You can break it up into separate .c files, compile each one individually, and then link them together; that's the more-or-less standard approach. It means creating public symbols for every variable and function needing an inter-file reference. It also means creating header files with declarations for all these things. Alternatively, you can #include all the source files into a single master. That doesn't provide any improvement in compile time (in fact compile times are now slightly worse), but it also doesn't generate a lot of new, unwanted public symbols. Personally, I don't see why anyone should think that #include-ing one .c file in another is any worse than physically merging the files. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
