Namespace for cube programmer API

TMack.1 · ‎2024-06-13

I am using the cube programmer API in a Qt C++ windows application and hit a problem where there is clash in naming of the disconnect() function.

disconnect() is in both qobject.h and CubeProgrammer_API.h

I am not a C++ expert, so please tell me if I have something wrong, however my understanding is that I would normally deal with this using namespaces. However I see no namespace defined in CubeProgrammer_API.h.

I have worked around this by modifying CubeProgrammer_API.h to include a namespace. eg

#ifndef CUBEPROGRAMMER_API_H
#define CUBEPROGRAMMER_API_H

namespace CubeProgAPI
{
#ifdef __cplusplus
extern "C" {
#endif
.
.
.
#ifdef __cplusplus
}
#endif
}

This allow me to call the functions using the namespace ( eg CubeProgAPI::disconnect(); ) and it does build without error but my understanding is that is not correct as the CubeProgrammer_API.lib I am linking against does not have the namespace. In fact I don't understand why it doesn't failed to link as I am using a namespace the linker will not recognise?

So my questions are:
1) Am I correct that CubeProgrammer_API does not have a namespace, it is just straight C code?
2) Am I correct that my solution above is not a good idea, even if it appears to work?
3) Any other "proper" solution to this name clash?
On that last point, I guess I could generate my own C++ library (with namespace) as a wrapper around the CubeProgrammer_API but I would rather avoid this if possible.

Maryem · ‎2024-06-25

Hello @TMack.1 ,

Sorry for the late reply.

In response to your questions :

1. The CubeProgrammer_API.h does not define a namespace and is intended to be used with C linkage specified by extern "C".

2. Your solution to wrap the CubeProgrammer_API in a C++ namespace is not a good idea because the library is compiled as C code, which does not support namespaces. The extern "C" linkage specification in the header is used to prevent C++ name mangling when the C functions are linked in a C++ project. If you wrap the C functions in a namespace, the linker will expect the symbols to be mangled as C++ symbols, which they are not, leading to linker errors.

3. To resolve the naming conflict, I tried using the fully qualified name for the Qt disconnect function when calling it. You can try to specify the class name along with the function name using the scope resolution operator ::. For the disconnect function from the CubeProgrammer_API, you can call it directly without any qualification since it is a C function and does not belong to any namespace or class.

Maryem.

TMack.1 · ‎2024-06-26

Thanks, that confirms what I thought. Although I will say wrapping the c functions in a namespace does actually work. It compiles and links without warnings and runs correctly. As I said, I expected to fail at to link (as you also said) but in practice this did not happen.

Anyway, your solution of using fully qualified name for the qt disconnect function does not work (fails to compile) in my project. I suspect because the implicit namespace is a qt one so calls to just disconnect() are assumed to be the qt one. I have not investigated this further though.
I think the only robust solution is to write a C++ library wrapper round cube programmer one and link to that. However I don't have time for that right now.

Maryem · ‎2024-06-26

Hello @TMack.1 ,

Ok, understood.

From my side, I tried including the `"qobject.h"` header and explicitly using `QObject::disconnect(m_connection);` in the `Example1.cpp` file within the CubeProgrammer API folder. Then, I built the project and did not encounter any issues. Could you please confirm if you have tried the same approach and encountered the compilation error? In any case, could you please share your project?

Maryem.

TMack.1 · ‎2024-06-26

I have not tried exactly that and cannot share my project, it is many 1000s of lines of code.

I have just realised that, rather than creating a library wrapper it would be simpler to just create a class within my project that wraps the api but I am afraid I do not have time to look at this further at the moment. Thanks for your suggestions though.

Maryem · ‎2024-06-26

Got it. If ever you try it, I'd be interested to know how it works out for you.

Thanks for engaging !

Maryem.