I am troubling myself with the following.
I have a file foo.c
that includes foo.h and does some stuff.
The tricky thing is this one. I would like to remap foo.h to my_foo.h. So when the compiler sees foo.h it should go to my_foo.h.
One thing that could work is to include my_foo.h to foo.h. Any other suggestions?
No I cannot include in foo.c my_foo.h
Thank you all in advance
Alter the include path to use a directory controlled by you before it uses the directory holding "foo.h"
In the directory controlled by you make a symlink called "foo.h" which points to "my_foo.h" as the target
Depending on which system you work, you might have no symlinks.
But maybe you can create a foo.h with the following content:
#include "my_foo.h"
What an interesting issue. I'd love to know what you're doing with it.
So if you have control over foo.h, here's a variation on a trick that is used when sharing header files between kernel code and user code in the Linux kernel.
/* File: foo.h */
#ifdef USE_MY_FOO_H
#include <my_foo.h>
#else
#define OVERRIDABLE_FOO_MACRO do { stuff() } while(0)
int overridable_foo_func();
#endif
int not_overridable_foo_func();
Then in your Makefile
/* File: Makefile */
default: foo.c foo.h
$(CC) foo.c -o foo
use_my_foo_h: foo.c foo.h my_foo.h
$(CC) -DUSE_MY_FOO_H foo.c -o foo
BTW, this is not really a great way to form your Makefile, it just demonstrates the compiler commands you can use to switch between the two foo.h files.
Related
I have three classes and corresponding header files, user.c, foo.c, and util.c. util.c contains functions that foo.c depends on, but I would prefer that user.c not call. Ideally, user.c would only be calling functions in foo.c. Right now, user.h/.c includes foo.h/.c, which includes util.h/.c, so all of the util functions are included transitively in user.c.
I don't need to keep the util.c contents hidden from the user, but I was wondering if there was a way to throw a compiler error/warning (or something like that) with clang if user.c ever calls something from util.c. Is this possible?
I've seen some things about PIMPL to hide private headers, but would rather not handle the additional memory and other tradeoffs of that.
I have the following includes:
user.c
#include user.h
foofunction(); //can call both of these just fine
utilfunction(); //would like to have a compiler warning if this is called
user.h
#include foo.h
foo.c
#include foo.h
void foofunction(){utilfunction();};
foo.h
#include util.h
void foofunction();
util.h
#include util.c
void utilfunction();
util.c
//no includes, just some functions
void utilfunction(){};
For C, there isn't any protection to any API/variables as long as it is global. In order to not expose API in other files you should:
Should not include private file in .h. All includes are perform in .c file
In case don't want user include private .h file, it is possible that you created a #define and check for the existence in private .h file and throw #error if not existence.
I have a folder which contains 3 files:
main.c
file1.c
file2.c
The idea is to compile only one file basing on a symbol if it's defined or not.
in main.c, I added the following lines:
#ifdef MY_SYMBOL
#include "file1.c"
#else
#include "file2.c"
#endif
The problem that I found is that when MY_SYMBOL is defined, file1.c is compiled twice because in the makefile it's mentionned to compile all source files inside each folder.
The limitation is that I shouldn't modify the makefile! So, to avoid that I modified the extension of file1.c and file2.c to file1.h and file2.h respectively, by keeping their content (definition of all private functions), and I updated the content of main.c as following:
#ifdef MY_SYMBOL
#include "file1.h"
#else
#include "file2.h"
#endif
Taking into account the above limitation, is the last proposal the best way ?
Note that file1.c and file2.c contain the same functions but with different implementation.
Among others, C programers usually do not expect one of the following:
.h-files that contain function implementations or variable definitions
.c-files that get included.
So I'd say with both ways you will somehow "surprise" others.
If you must not alter the makefile (BTW: why?), you could encapsulate the implementation variants in your .c-files within preprocessor-directives:
// file1.c (OR: file_mysym_implementation.c):
#ifdef MY_SYMBOL
// code goes here
#endif
// file2.c (OR: file_non_mysym_implementation.c):
#ifndef MY_SYMBOL
// code goes here
#endif
Additionally, you will need one header file which declares all the functions exposed by the respective implementation.
I am a newbie in C. I have two simple source code files f1.c and f2.c.
f1.c looks like:
#include <stdio.h>
#include "f.h"
void f1(void) {
// some code ...
}
function f2() in f2.c relies on f1() in f1.c.
#include <stdio.h>
#include "f.h"
void f2(void) {
f1();
}
f1.c and f2.c share a same header f.h,
void f1(void);
void f2(void);
There are no main() access, I just want to compile these two file into a .o file without linker (using -c option),
gcc -c f1.c f2.c -o f2.o
then I got,
clang: error: cannot specify -o when generating multiple output files
but when I mentioned only f2.c, it works well,
gcc -c f2.c -o f2.o
So what's the problem? Thanks!
You should look into the compilation process for C. The first stage is compiling the .c source code into .o object files. The .c files do not need to see the other .c files; they are accepting as fact what you've told them about the existence of external functions. It's not until the linker comes in that it really needs to see the function because the implementation details don't matter to your .c file, just the interface, which you've presumably given it in the header.
What you can do, if you like, is drop the -o flag specifying the output file you want to create. Just compile with
gcc -c f1.c f2.c
and it will know to create f1.o and f2.o which will be able to link against each other when the time comes that you do want to go through with the linking process.
I am curious, however, what your intentions may be for wanting to compile these without linking. I only ask as you refer to yourself as a newbie, so I am wondering if maybe there is an end goal you have in mind and perhaps aren't asking the right question.
I'm encountering a classic error but still don't get why it occurs...
Below is the simplified explanation
Apparently I have two C files main.c and support.c
in support.c i have one function void bla(int input);
in main.c i have several functions using bla from support.c, and i included
#include<support.c>
at the top of main.c
However I cannot compile the project because of the error multiple definition of bla, first defined here (eclipse points to the definition of bla in support.c)
I know that optimally I would have to create header file support.h and gives prototype extern void bla(int input) there, but for this I have to include the .c file.
Thanks in advance.
The preprocessor will copy the contents of support.c, and paste it to main.c to replace the line #include<support.c>. So there are two definition of the function bla, one in support.c, the other in main.c.
The solution is, don't include an source file. Put the declarations of functions that you want to export in a header file support.h, and include the header file in main.c:
#include "support.h"
You don't include source files into other source files. Instead you make a header file (with the extension .h) that contains declarations of functions, i.e. function prototypes. Then you build both source files separately, and link them together to form the final executable.
So a header file support.h like
#ifndef SUPPORT_H
#define SUPPORT_H
void blah(void);
#endif
(The preprocessor #ifdef/#define/#endif things are for include guards, to protect from multiple inclusion in the same source file.)
Then the support.c source file
#include "support.h"
void blah(void)
{
/* Some code here... */
}
And finally the main.c source file
#include "support.h"
int main(void)
{
blah();
return 0;
}
If you have an IDE (like Visual Studio) if you add these files to your project the IDE will make sure everything is built and linked properly. If you're compiling on the command line, compile each source file into an object file (usually using an option like -c (used for GCC and clang)) and then link the two object files together to create the executable.
Command line example with GCC:
$ gcc -Wall -c main.c -o main.o
$ gcc -Wall -c support.c -o support.o
$ gcc main.o support.o -o my_program
The above three commands will first compile the source files into object files, and then link them together.
What compiler are you using?
When compiling, make sure you do this:
gcc main.c support.c -o yourProgram
I have a source file foo.c and a header file bar.h. How can I just expand the macros in bar.h without expanding macros in other header files?
$ cat foo.c
#include <stdio.h>
#include "bar.h"
int main()
{
#ifdef BAR_FUNC
printf("bar func\n");
#else
printf("foo func\n");
#endif
return 0;
}
$ cat bar.h
#define BAR_FUNC 1
What I want is:
$ EXPAND_MAGIC foo.c
#include <stdio.h>
int main()
{
printf("bar func\n");
return 0;
}
If I use `gcc -E, it expands <stdio.h> as well. But I just want to expand macros in bar.h. Is there an option in gcc doing that? If not, are there any other tools that can do such preprocessing?
Update: Above foo.c/bar.h is just an example. In reality, I have a few hundreds of macros defined in bar.h (pls consider config.h generated by autoconf in a fairly large project). And what I want is to expand all (and ONLY) these macros in more than 10K source files. Any suggestions?
You might look into the program sunifdef which is mentioned in the answer to this question. It allows you specify macro definitions on the command line, and it eliminates #ifdef lines appropriately. Note that it doesn't do macro expansion.
That said, you shouldn't use a tool like this for general development, but it's quite useful for decoding or cleaning up a code that has gotten messy with many unused #ifdefs's over the years.
Unfortunately for you the proeprocessos is all-or-nothing. Either you run it and it includes all requested files and expands all macros.
However you can kind of work around it by using the conditional compilation features of the preprocessor:
#ifndef INCLUDE_ONLY_BAR
# include <stdio.h>
#endif
#include "bar.h"
int main()
{
#ifdef BAR_FUNC
printf("bar func\n");
#else
printf("foo func\n");
#endif
return 0;
}
You can "compile" it as such:
$ gcc -E -DINCLUDE_ONLY_BAR foo.c
You can use an IDE like eclipse. It disables the part of the code which is not compiled. You might not be able to see 'exactly' what you want to see, but you can see a clear difference between disabled code and normal code. Please ignore this option if you don't have luxury of using GUI.
Eclipse also helps in expanding macros which can be very handy when you have complex macros.
Try:
Normally compile: gcc -include stdio.h -imacros bar.h foo.c
Compile to expand ONLY MACROS in bar.h: gcc -E -imacros bar.h foo.c