Interface depends on QtCore4.dll
-
Hello Community,
As it turns out, the project our team works on is built on a C ++ interface that we can not influence. This interface is precompiled and requires the QtCore4.dll. We have already experienced many difficulties and are now looking for a solution that allows us to use Qt5 in our project. Can this be guaranteed by using all Qt5 objects and methods in a separate namespace? Has anyone already tried something similar?
wrote on 14 Nov 2018, 10:14 last edited by@odd.citizen.ape
You seem to be saying you want your application to "mix" using part Qt5 and part Qt4? I don't see how that's possible to link. See e.g. https://stackoverflow.com/a/36452023/489865 -
@odd.citizen.ape
You seem to be saying you want your application to "mix" using part Qt5 and part Qt4? I don't see how that's possible to link. See e.g. https://stackoverflow.com/a/36452023/489865wrote on 14 Nov 2018, 10:20 last edited by@JonB the idea was to separate the linker includes (Qt5) in our application by using a namespace from those of the interface (Qt4) which is a library we are including.
-
@JonB the idea was to separate the linker includes (Qt5) in our application by using a namespace from those of the interface (Qt4) which is a library we are including.
wrote on 14 Nov 2018, 10:26 last edited by@odd.citizen.ape
I don't understand. Qt5 & Qt4 themselves are already compiled. They use whatever namespace they have been compiled with. Putting e.g. a namespace in your own code won't affect which namespace Qt is in. -
@odd.citizen.ape
I don't understand. Qt5 & Qt4 themselves are already compiled. They use whatever namespace they have been compiled with. Putting e.g. a namespace in your own code won't affect which namespace Qt is in.wrote on 14 Nov 2018, 10:32 last edited by@JonB sorry - just to make sure I've got you right - if one is working on a Qt5 project, he can not use a library, which needs QtCore4.dll to work right?
-
@JonB sorry - just to make sure I've got you right - if one is working on a Qt5 project, he can not use a library, which needs QtCore4.dll to work right?
wrote on 14 Nov 2018, 10:36 last edited by@odd.citizen.ape
That is my understanding/presumption, yes. However I am not a Qt expert as some people are here, and I don't even use C++ for Qt, so take that onboard!It would be nice/kind if a Qt "expert" would care to comment here, in case I am misleading you...?
-
@JonB sorry - just to make sure I've got you right - if one is working on a Qt5 project, he can not use a library, which needs QtCore4.dll to work right?
@odd.citizen.ape I don't see how you can use Qt4 and Qt5 in same application. Both Qt versions are not compatible with each other. Why do you want to have such a mix?
-
@odd.citizen.ape I don't see how you can use Qt4 and Qt5 in same application. Both Qt versions are not compatible with each other. Why do you want to have such a mix?
wrote on 14 Nov 2018, 12:20 last edited by@jsulm as I mentioned above, our project depends on a interface (library) which is using QtCore4.dll. This interface is not our product. We can not influence/manipulate or recompile it with Qt5. But it is necessary to establish communication between our application and the numeric control unit.
-
@jsulm as I mentioned above, our project depends on a interface (library) which is using QtCore4.dll. This interface is not our product. We can not influence/manipulate or recompile it with Qt5. But it is necessary to establish communication between our application and the numeric control unit.
wrote on 14 Nov 2018, 12:47 last edited by JonB@odd.citizen.ape
What precisely do you mean byBut it is necessary to establish communication between our application and the numeric control unit.
If you mean have them in the same process, as @jsulm & I have suggested we do not think that is possible. But if you only mean "inter-process communication" between the two that could be accomplished....
-
wrote on 14 Nov 2018, 12:59 last edited by
Hi,
have you tried making a new Qt5 project calling your interface library to test it out? I see what you are saying, the interface library depends only on Qt4 but the main app which calls the library you want to have its dependency on Qt5. If you haven't tried yet it would be worth a shot.
The other solution which @JonB has started to allude to is to wrap your library up in some listening socket server and then connect to that application using sockets. In which case you have a minimized application dependent on Qt4 which sends and receives messages through sockets (or something like that). You can develop your main app in Qt 5 and have it talk to your Qt4 library through those means.
-
Hi,
have you tried making a new Qt5 project calling your interface library to test it out? I see what you are saying, the interface library depends only on Qt4 but the main app which calls the library you want to have its dependency on Qt5. If you haven't tried yet it would be worth a shot.
The other solution which @JonB has started to allude to is to wrap your library up in some listening socket server and then connect to that application using sockets. In which case you have a minimized application dependent on Qt4 which sends and receives messages through sockets (or something like that). You can develop your main app in Qt 5 and have it talk to your Qt4 library through those means.
wrote on 14 Nov 2018, 13:30 last edited by@JonB @jsulm thanks, so that's clear for now - there is no way how I could make these components work together in the same process, no matter how I try to separate them (namepaces etc.).
Hello @MrShawn ,
I've already tried to combine a Qt5 project with a component which uses a Qt4Core.dll and the behavior was pretty undefined : ). I guess, things worked just as long, as the methods/object I used haven't conflicted with each other (e.G. QString methods haven't changed much recently).
However, your idea with the listening socket server sounds makeable. Thanks for that, I'll definitely give it a shot.Thank you all guys.
Have I nice day! -
@JonB @jsulm thanks, so that's clear for now - there is no way how I could make these components work together in the same process, no matter how I try to separate them (namepaces etc.).
Hello @MrShawn ,
I've already tried to combine a Qt5 project with a component which uses a Qt4Core.dll and the behavior was pretty undefined : ). I guess, things worked just as long, as the methods/object I used haven't conflicted with each other (e.G. QString methods haven't changed much recently).
However, your idea with the listening socket server sounds makeable. Thanks for that, I'll definitely give it a shot.Thank you all guys.
Have I nice day!wrote on 14 Nov 2018, 13:38 last edited by JonB@odd.citizen.ape said in Interface depends on QtCore4.dll:
I guess, things worked just as long, as the methods/object I used haven't conflicted with each other (e.G. QString methods haven't changed much recently).
Yes, even if you can make the thing link somehow, assuming you need to pass some sort of
QOBJECTs or similar across the interface between your Qt5 & the other thing's Qt4 I would have said you would have no chance --- binary/in-memory layout/behavioural compatibility will not be possible across Qt major versions.If you can do the IPC I suggested and @MrShawn clarified how you would approach (i.e. sockets, probably) that by-passes these issues. However, IPC is incredibly slow/inefficient compared to same-process. That could be fine for occasional "communication" (e.g. perhaps yours boils down to a separation between UI in one and back-end in the other?), but you cannot architect like you would if you just had functions to call directly. You must look at the frequency of your cross-process exchanges.
-
@odd.citizen.ape said in Interface depends on QtCore4.dll:
I guess, things worked just as long, as the methods/object I used haven't conflicted with each other (e.G. QString methods haven't changed much recently).
Yes, even if you can make the thing link somehow, assuming you need to pass some sort of
QOBJECTs or similar across the interface between your Qt5 & the other thing's Qt4 I would have said you would have no chance --- binary/in-memory layout/behavioural compatibility will not be possible across Qt major versions.If you can do the IPC I suggested and @MrShawn clarified how you would approach (i.e. sockets, probably) that by-passes these issues. However, IPC is incredibly slow/inefficient compared to same-process. That could be fine for occasional "communication" (e.g. perhaps yours boils down to a separation between UI in one and back-end in the other?), but you cannot architect like you would if you just had functions to call directly. You must look at the frequency of your cross-process exchanges.
wrote on 14 Nov 2018, 13:51 last edited by@JonB said in Interface depends on QtCore4.dll:
However, IPC is incredibly slow/inefficient compared to same-process. That could be fine for occasional "communication" (e.g. perhaps yours boils down to a separation between UI in one and back-end in the other?), but you cannot architect like you would if you just had functions to call directly. You must look at the frequency of your cross-process exchanges.
Well, that makes the thing look less attractive since a higher frequency of cross-process exchanges is one of our main targets. Sounds like we'll have to stay with Qt4 to accomplish out needs.
-
@JonB said in Interface depends on QtCore4.dll:
However, IPC is incredibly slow/inefficient compared to same-process. That could be fine for occasional "communication" (e.g. perhaps yours boils down to a separation between UI in one and back-end in the other?), but you cannot architect like you would if you just had functions to call directly. You must look at the frequency of your cross-process exchanges.
Well, that makes the thing look less attractive since a higher frequency of cross-process exchanges is one of our main targets. Sounds like we'll have to stay with Qt4 to accomplish out needs.
wrote on 14 Nov 2018, 14:07 last edited byhigher frequency of cross-process exchanges
1 time per second or 1,000,000 times per second?
-
higher frequency of cross-process exchanges
1 time per second or 1,000,000 times per second?
wrote on 14 Nov 2018, 14:12 last edited by@JonB it is not static and depends on the configuration of each user/instance. Possible setup - 100 variables each 15 milliseconds.
11/15