[Development] QtNetwork QtCS Session

[Rutledge Shawn]

On 13 Jun 2014, at 17:26, Thiago Macieira <thiago.macieira at intel.com> wrote:

> Em sex 13 jun 2014, às 05:52:57, Rutledge Shawn escreveu:
>>> It makes no sense to build Qt without any platform plugin, for example.
>>> The  plugins must stay with QtGui, which implies that QtCore, QtNetwork
>>> and QtDBus must too.
>> 
>> But maybe the platform plugins’ dependencies on d-bus could be made optional
>> and resolved at runtime, so that some features are missing if it is not
>> available but otherwise they continue to function?
> 
> I don't see how they'd do that. In order to dlopen anything, we need a C API. 

Supposedly it can be done even with C++, with some caveats:

http://stackoverflow.com/questions/1067346/alternatives-to-dlsym-and-dlopen-in-c
http://tldp.org/HOWTO/C++-dlopen
http://www.linuxjournal.com/article/3687

I tried the code from the last one.  Seems the main idea is that if you got a C++ object from the dlopen’d library, you are free to call methods on it (as long as the methods were declared in base classes to which the compiler had access already, and I suppose that could cause some code duplication), but you need an extern “C" function to get the object.  Maybe the plugins' usage of D-Bus could be made to fit that pattern then?

Sorry if I’m repeating an idea that was previously shot down, seems like it must have been brought up by now.  But I’ve always had a conceptual problem with the idea that dlopen doesn't work with C++.  If the world just needs a smarter way of doing run-time linking on-demand instead of at the application startup time, why wasn’t it written by now?