CODEWITHSUNDEEP
c++winapidllnamingextern
Sanctus2099
Sanctus2099

Reputation: 1723

Question about c++ naming conventions

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

Upvotes: 1

Views: 318

Answers (5)

walt_r
walt_r

Reputation: 21

There is no "CreateQtThread" function in Qt, not even something similar. There's a QThread class, and it has constructors. If needed, you can put everything in a namespace.

Upvotes: 0

Ferruccio
Ferruccio

Reputation: 100658

Does your CreateThread use the stdcall calling convention (aka WINAPI)? If you use the cdecl calling convention, it should export the function name as _CreateThread and avoid the linkage conflict with the Win32 CreateThread function.

extern "C" _declspec(export) int _cdecl CreateThread(...

Upvotes: 1

shelleybutterfly
shelleybutterfly

Reputation: 3247

Well, I don't know whether you will like this as I know the C developers I worked with found it unaesthetic. But, it's very simple and prevents collisions like this. (More or less mentioned in this answer with the "their_lib_prefix_function" comment.)

So, whenever I was using C code, I used to basically 'namespace' my functions using an underscore. So, let's say your namespace is MegaAbstraction, then something like CreateThread becomes MegaAbstraction_CreateThread. Easy peasy. And no collisions, unless someone else has a namespace called MegaAbstraction in which case I recommend finding a namespace that's unlikely to be used by anyone else. ;)

Upvotes: 5

David Heffernan
David Heffernan

Reputation: 612964

Your decision to use extern "C" is sound in my view because it allows access from other languages, compilers etc. But doing so means you can't use namespaces so you simply must prefix your functions with something to identify them as being from your library, a poor man's namespace if you will.

This is the compromise you must make if you want to use extern "C".

Upvotes: 5

Yakov Galka
Yakov Galka

Reputation: 72479

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...

Upvotes: 5

Related Questions