[Interest] Hiding a shared lib? Linux of course.

[André Pönitz]

On Thu, Jul 04, 2013 at 08:11:28PM +0200, Allan Sandfeld Jensen wrote:
> On Thursday 04 July 2013, Thiago Macieira wrote:
> > On quinta-feira, 4 de julho de 2013 14.44.40, Diego Iastrubni wrote:
> > > I was thinking something similar a few days ago. This is out of scope
> > > for Qt5... but Qt6.. how about using namespaces to distinguish the Qt
> > > releases?
> > > 
> > > Qt6::MainWindow w = new Qt6::MainWindow();
> > > w->show();
> > > 
> > > using namespace Qt6;
> > > MainWindow w = new MainWindow();
> > > 
> > > This could prevent sush crashes in the future right? The symbol names
> > > will be differently, and in theory crazy people would be able to load
> > > Q5 and Qt6 into the same memory address. yes, we might need to rename
> > > also "a few" public functions... but this is doable, right?
> > 
> > Yes, it could, but it's unlikely we'll ever do that.
> > 
> > That would mean a full source-compatibility break.
> 
> Not necessarily I think. Wouldn't it be possible to let the headers declare 
> the namespaced classes 'using'? 
> 
> For instance:
> 
> namespace Qt6 {
>    class QString;
> }
> 
> using Qt6::QString.
> 
> This would mean the QString  would still work in the global namespace when 
> building but would be in the Qt6 namespace when linking

That you can get already today by running Qt's ./configure with -qtnamespace
Qt6 (and for completeness perhaps with -qtlibinfix)

The "problem" is that it's not completely invisible to user code, and there
is no way to make it so, as it clashes with class declarations on global
namespace scope. So if your application uses 'class QString;' somewhere,
it'd have a "problem".

[The solution is to wrap all such declarations in QT_BEGIN_NAMESPACE ...
QT_END_NAMESPACE which in this case would expand to 'namespace Qt6 {' and
'}'. It's doable, and used in practice, e.g. Qt Creator itself compiles
properly in such a setup]

Andre'