I work on AS/400 which is sometimes non-POSIX. We also need to compile our code on UNIX. We have an issue with something as simple as #include.
On AS/400, we need to write: #include "*LIBL/H/MYLIB"
On UNIX, we need to write #include "MYLIB.H"
At the moment we have this (ugly) block at the top of each C/C++ file:
#ifndef IS_AS400
#include "*LIBL/H/MYLIB"
/* others here */
#else
#include "MYLIB.H"
/* others here */
#endif
We would like a unified macro. Is this possible? I don't know how to write it.
Ideally, the resulting syntax would be: SAFE_INCLUDE("MYLIB") that would expand correctly on each platform.
Please advise.
You can simply #include some separate header in every of your source files containing that ugly #ifndef just once. It's a common practice anyway.
You can define prefixes for your platform as macro. Like
#define STRINGY(STR) #STR
#define SAFE_INCLUDE(HDR) STRINGY(HDR)
#ifndef IS_AS400
#define SAFE_INCLUDE(LIB) STRINGY(*LIBL/H/##LIB)
#else
#define SAFE_INCLUDE(LIB) STRINGY(LIB##.H)
#endif
and you can use this as
#include SAFE_INCLUDE(MYLIB)
There are two better solutions:
Use your Makefiles to properly set a path where compiler looks for includes.
For GCC you add to CFLAGS -I <path> (you can do that multiple times).
Wrap the non-compliant libraries with your own header files.
Related
I'm fairly new to programming in C. My problem is that I have two implementations of a function and I want to be able to switch between them easily.
Right now I define the two implementations of the function as function_implementation1 and function_implementation1 in the files "funtion_implementation1.h" and "funtion_implementation2.h" respectively. To switch between them I have the following file:
#define IMPLEMENTATION1
#ifdef IMPLEMENTATION_1
#include "funtion_implementation1.h"
#define myFunction function_implementation1
#endif
#ifdef IMPLEMENTATION_2
#include "funtion_implementation2.h"
#define myFunction function_implementation2
#endif
In order to switch from one implementation to the other I just have to change the first line. This approach works, and I was satisfied with it for a while, but now it is bugging me that I have to open this file so often. I have a parameters.h file where I define all my parameters and I would rather choose which implementation to use in that file. Sadly, moving the first line to that file does not work. If I do that myFunction is not defined.
What is the best way to do this?
you should include your parameters file where you use alias, macros, etc:
#include "Parameters.h"
also, all your headers files should start with:
#ifndef __FILE_H__
#define __FILE_H__
// definitions go there
#endif
This prevents nested include of header files
Use preprocessor options, specifically the -D option. If you wanted to use IMPLEMENTATION1, when you are compiling that file on the command line (or in IDE), add -D IMPLEMENTATION1. This defines that macro. Same works for any macro
I have a C program named coderTest.c in a directory. In a sub-directory, src, I have several files, one.c, two.c, three.c, and their associated header files one.h, two.h, three.h.
I want to use functions from one.c and two.c in coderTest.c. Both one.c and two.c use functions from three.c. Do I need to include three.c in coderTest.c, or will it take care of it's dependency on it's own?
I am using #include "src/one.h" for one and two.
Do I need to include three.c in coderTest.c, or will it take care of
it's dependency on it's own?
You don't need to include "src/three.h" in coderTest.c, but this does not mean, that compiler does handle dependency automagically. This header needs to be included in one.c, two.c and three.c. The last one is to confirm that header's declarations and definitions match with each other properly.
As a result, you project might look as:
coderTest.c:
#include "src/one.h"
#include "src/two.h"
// ...
src/one.c:
#include "one.h"
#include "three.h"
// ...
src/two.c:
#include "two.h"
#include "three.h"
// ...
src/three.c:
#include "three.h"
// ...
To prevent multiple includes of same header, use header guards for each header file individually.
In coderTest.c, include the following:
#include "src/two.h
#include "src/one.h
In one.c, include:
#include "src/three.h
In two.c, include:
#include "src/three.h
Do I need to include three.c in coderTest.c, or will it take care of it's dependency on it's own?
No you don't need to include three.c in coderTest.c, because one.c and two.c abstract it away.
As long as two.c and one.c properly #include "three.h" then the compiler will be able to chain the dependencies together without a problem. If you wanted to run something from three.c in coderTest.c it would want you to #include it in there as well.
Do your files have the preprocessor directives #IFNDEF, #DEFINE, and #ENDIFin place to prevent duplicate importing?
You can do what you want several ways as long as visibility to necessary prototypes is provided. In addition to where best to include header files, consider using wrappers to guarantee your header is used only once:
#ifndef _SOMEFILE_H_
#define _SOMEFILE_H_
the entire file
#endif /* SOMEFILE_H__SEEN */
Also consider readability. For example given: coderTest.c, one.c/.h, two.c/.h, three.c/.h are as you described:
1) You should include three.h in both one.c and two.c.
2) For coderTest.c, #include headers of all supporting headers either in the file itself, or perhaps in a collector header: conderTest.h:
coderTest.h:
#include "./src/one.h"
#include "./src/two.h"
#include "./src/three.h"
coderTest.c
#include "coderTest.h"
I am writing a simple c test framework. For simplicity, I only provide a single header file (containing all the function definitions), but I meet some problems. If I only include the header once, everything works fine. If I include the header twice, the gcc linker report duplicate symbol error (that is normal), so I add static prefix in every function in the header. This time it works, but the function is duplicate in the final binary. See bellow:
[heidong#HEIDONGVM ztest]$ nm m | grep __ct_hex_dump
0000000000400904 t __ct_hex_dump
0000000000401efc t __ct_hex_dump
Is there some way the made the function define only once?
Thanks a lot!!
Maybe someone needs the code, I just started a project in github: https://github.com/buf1024/test
Thanks again!!
What you have is in ct.h
static functions
static function definitions
In atest.c
// This is the first lot of definitions
#include "ct.h"
In main.c
// This is the second lot of definitions
#include "ct.h"
To fix
move the static function definitions to ct.c, remove the word static
Change all the prototypes in ct.h from static to extern
add ct.c to your link.
Edit: just delivering just ct.h
Change all the prototypes in ct.h from static to extern
Before the first function body add #ifdef __CT_C__
After the last function, add #endif
Tell the user that in the code that contains main, they need to #define __CT_C__ before they #include "ct.h"
Anything else that #include "ct.h" must not define __CT_C__.
Use compiler directives.
#IFNDEF MYFUNC
#DEFINE MYFUNC
myfunc();
#ENDIF
Everytime the compiler hits this directive, it will only go in once when MYFUNC is not defined and after defining it, it won't go in the statement again. No matter how many times you include the header file, it will always check if it's been defined before.
Coppiler directives is not part of the compiled code. It's just a directive.
If you absolutely need only one file, you can do it with preprocessor:
header.h
#ifndef HEADER_H
#define HEADER_H
#ifdef IMPLEMENT
#undef IMPLEMENT
void func(void) {
...
}
#else
void func(void);
#endif
#endif
In one file:
// Define
#define IMPLEMENT
#include "header.h"
In other files:
// Only declarations
#include "header.h"
Though I would choose a proper .c file instead.
I want to include the result of a macro expansion. It seems include only knows <> ""?
This fails:
#define audio sinwave
#ifdef audio
#include audio".c"
/*#include "sinwave.c"*/
#endif
But this works:
#ifdef audio
if(i==0){set_audio((char *)audio);return;}
#endif
You could do something like this:
#define audio audio
#define FF(X) #X
#define F(X) FF(X.c)
#ifdef audio
#include F(audio)
#endif
that is you'd have to append the .c before you place everything into a string. The usual concatenation "audio" ".c" -> "audio.c" of adjacent strings happens in a later compilation phase than preprocessing, so an #include directive cannot deal with this.
No. Preprocessor directives cannot be used like this. You can use macros to concatenate and stringify names, but that's another case. If you need this, you should most probably re-think your design because it's not good enough at the moment.
Maybe it's not clear to me... But I see a few different questions that you're asking...
I think your asking if you can include source files, yes you can, but its not the best idea; see here for a good discussion why.
If you're wondering about including files with "..." vs <...>, the difference is the quotes are when files are in your local directory (or you want to include the path to the file) the <> are for when the file is in your search path.
If you want to stringify the file name, then
Jens Guestedt answer is what you want... But I question the logic behind doing this...
Why not include the .c file in your project normally (add it to your makefile or whatever) then just wrap the code in question (or the while file) in the #ifdef? That's a much more standard way to conditionally compile the code.
I use a parser generator here, that unfortunately insists on putting a
#include <some/file.h>
at the top of every generated source file. The header has since long been renamed. While it is no problem forcing the compiler (gcc) to use the new header with -include new/header.h, removing the above directive from every generated file complicates the build-process.
Is there a way to tell gcc to simply ignore some/file.h?
No. You can post-process your generated file - I say: NO!!!
Or you can just add '.' to your system include directories (or whatever your local include path is - make sure it's also a <> system include path).
Then make a 'some' directory and stick your own permanent 'file.h' in there that has 1 line for #include and get rid of your -include.
I'm guess there's some reason that might not work - cause it seems like the more straight forward and understandable thing to do before using -include. Especially since you can comment the pass-through file to explain what's going on.
Replace some/file.h with an empty file.
Why not make a symlink from some/file.h to new/header.h, and remove the -include directive?
Try using preprocessor directives like #if and #ifdef and gcc -DSYMBOL=value command line flag.
In example, if you compile using gcc -DREQUIRE_STDC=1 -o myfile.o myfile.c, and your .c file contains:
#if defined(REQUIRE_STDC) && defined(__STDC__)
#include "some/file.h"
#else
#include "another/file.h"
#endif /* defined(REQUIRE_STDC) && defined(__STDC__) */
It will compile using "some/file.h" if have both STDC and REQUIRE_STDC symbols defined. Also your header may include the proper directive to avoid multiple inclusions of the same file:
#ifndef MY_HEADER_FILE
#define MY_HEADER_FILE 1
/* your C declarations here */
#endif /* MY_HEADER_FILE */
Also, you could the gcc preprocessor manual.
#include <some/file.h>
may start as something like
#ifndef _FILE_H_
#define _FILE_H_
If so, just add #define _FILE_H_ before the #include command and it should ignore it.
I'm not sure whether this is the best solution, though.