3

I'm writing a project that I want to keep small in the sense of being very densely-coded and a single source file.

But it's growing large enough that navigating the file is becoming tiresome, so I want to break it up into several parts. But I think I can keep the number of files small by not having a separate header file but instead using preprocessor directives to designate sections:

#ifdef EXPORT
#define blah Blah Blah Blah
void prototype(void);
#else /* IMPLEMENTATION */

void prototype(void){
     //blah
}

#endif /* IMPLEMENTATION */

and to include the "header":

#define EXPORT
#include "module.c"
#undef EXPORT

Are there any drawbacks to this that I'm just not seeing? Aside from the fact that I've never heard of anybody doing this?

  • 2
    You could just have one C file, without such tricks – Basile Starynkevitch Jun 16 '15 at 4:48
  • Hmm. Yeah. That would fit better with the code, which is very highly coupled. So partitions could/should have a different extension, since it's not a header, nor a complete source, sth like .inc. – luser droog Jun 16 '15 at 5:14
  • highly coupled == bad design. the C compiler can recognize a number of file extensions and a makefile can extend the range of usable extension. However, Such layout is a very bad idea. Suggest redesign to remove coupling. separate functionality into separate functions/files (both .c and .h) Do NOT #include .c files. There is nothing wrong with having lots of small files. The trick your trying to do will come back to turn your hairs gray when the project needs maintenance in the future. – user3629249 Jun 17 '15 at 4:01
4

Compilation dependencies are from file to file. By separating the declarations into a separate header file, you are free to change the source without causing a recompilation of other code that depends on the header.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.