Printable View
CornedBee, you are probably right about OS specific code :(
Mats, I also tried to avoid globals and tried using functions that would set/get the variables.
Now as provided in the links I can do this on Windows but don't know how to do this on Linux & Mac.
Well on Linux i did not have to use any kind of trickery to access the functions from a .so file.
I just made a .c file with two functions in it, into a Linux .so file.
Then in .cpp i used those functions with this guard around prototypes:
Code:
#ifdef __cplusplus
extern "C" {
#endif
char* toUpper(char* str);
#ifdef __cplusplus
}
#endif
Now, the good news is for my small test, my .so files and functions within are easily used by the .cpp program i made.
But the bad news is, that it does not work with my project, which also have a similar situation (although already mentioned in my posts above) which i summraize here again:
The .c files ends up in a .so/.dll or anything OS specific (similiar for a dynamic library). And the program contains all .cpp files. Now the program uses this .dll/.so file (links with it) and needs some functions from it. On Windows there is this dllexport trickery involved. But on Linux nothing needed to be done and i was able to create a .so and access the functions just fine. Is there something more to it (involving .so files) on Linux, which i may be missing?
From my understanding, .so files exports everything by default, which means you have to do nothing to access everything in your file.
Windows dlls are different. They export nothing by default. You have to use either __declspec(export) or a definition file (.def) to export your variables/functions to use them elsewhere.