Using #include for .c and .h files since DC 10.60

I’m about to embark on some restructuring of code I’ve inherited. And reading about the #include feature on DC 10.60 (I’m using 10.72) it seems I might be able to structure my code as a classic C program, using .c and .h files.

Does anyone have any experience to share with this method, rather than the DC tradition of #use and .lib? I would like to make my code more portable for the future, and I’d like to have a heads-up on the risks and rewards. I couldn’t find any discussion in these forums or the web.

Does using #include increase the amount of code compiled by including routines which may not be referenced, or is that feature maintained regardless? Are any other DC features compromised by moving away from the .lib model? Any best practices to share?

Thanks in advance.

I recently did this and was able to port some C software from a Visual Studio 2013 environment, and make the software able to compile on both platforms using the preprocessor to implement conditional builds.

I do not know if using #include increases the amount of code compiled if the dynamic C features are compromised, but the ability to use a common codebase on two platforms was worth it for me.

Some caveats about the dynamic C compiler.

  1. You must use include guards for every header. This is good practice in general, but especially important because the parser does not seem very sophisticated.

  2. Add your .h and .c files one by one and compile at each step to make sure you’ve done it correctly. The first time I tried it, I did it with multiple files at once, and I missed an #include guard. The the error message wasn’t that helpful, so I couldn’t find it. I went back and did it file by file and I was able to get the whole project to work.

  3. The IDE only accepts .c files as part of the project. This is different than modern IDE’s. Header files can be included using #include, but they won’t show up in the project explorer. This is an inconvenience.


@mbermal - I’m wondering what kind of minimal test case I could build to test the operation of this. As you mention, commonality across platforms is the impetus for this effort.

  1. Thanks for your advice on the header guards.

  2. I’ve got a large code base to convert and its going to be incremental across all our .lib’s, but the idea still holds.

  3. I agree, they must figure no-one wants to edit .h files :slight_smile: