Question

I’m trying to create a abstraction layer for platforms such as win32, mac os, linux, iOs etc.
I want this to be dynamically linked. On platforms that don’t support this it shouldn’t be a problem since from what I’ve seen everything that can be compiled as a dynamic library can be compiled as a static one as well with minimum impact on the code.

Now, to get to the point of this:

I created a interface named IThread and a class named CThread. I use a function named CreateThread that’s defined with extern “C” to be able to export it and call it outside the library. The problem here is that in win32 for example there already is a function named CreateThread and thus I get a linker error. I understand the error and why it’s appearing but I’m not sure of a good way to avoid this. I don’t really like to use weird naming as qt uses like CreateQtThread.
Another idea I have would be is to create a thread manager/factory that creates instances of CThread but I’m not sure this would be a great idea.

What do you guys think about this? I’m asking because I don’t want to rush on important organizing problems like this.

Thank you very much

Answer 1

I use a function named CreateThread that’s defined with extern “C” to be able to export it and call it outside the library.

This is bad. I can’t talk for other platforms, but on windows it’s perfectly fine to export C++ functions. They are just get mangled, and you get some sanity checking in case someone changes the declaration. In fact, it’s the only correct way to export a function that is C++. If you declare it as extern “C” you get no namespaces, no overloading, and someone who compiles with /EHsc will be in trouble if an exception escapes from your function.

Preferred solution: Do not declare them as extern “C”, and put them in a namespace.

The only other solution: well, guess why all those C libraries prefix their functions with their_lib_prefix_function…