[Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

On Tuesday 19 January 2016 13:42:16 Olivier Goffart wrote:
> On Dienstag, 19. Januar 2016 12:02:12 CET Knoll Lars wrote:
> > Things are not just black and white. But we can’t do a Qt6 that simply
> > removes all of them completely. We’d leave most of our users behind on Qt
> > 5 forever. So we have to find better, and maybe more incremental, ways
> > to handle this. With a radical 'let’s throw them all away' approach we
> > will leave all our current users behind.
> 
> Just an idea:
> 
> We deprecate them, so all our api use std::vector and such.
> We add a qt5support library which contains classes like:
> 
> template<typename T> class QVector : public std::vector<T>
> {
>   QVector(std::vector<T>); // implicit conversion from std::vector
>   /* All the Qt API  goes here */
> };
> 
> I believe this should be mostly source compatible.

I'd aggregate the std container instead of inheriting it, but yes, that's a 
good idea. I just wrote a mail suggesting essentially the same, only slower. 
But I'd have nothing against going all-in, either.

> This also assume we can use std in our ABI (which i think we should allow)

+1

> Marc Mutz wrote:
> > > E.g. QVector seriously needs to support move-only types (like
> > > unique_ptr) in a C++11 world. Oops... it never will... it's CoWed...
> 
> Actually, it might be possible, using SFINAE, to disable the copy
> constructor of QVector when the T is not copyable.  (and we also do not
> call detach for such T since it cannot be copyed and therefore cannot be
> shared)

It may, yes. With the current speed of Qt container development, though, I 
don't see this coming to fruition.

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts