[Development] Question about QCoreApplicationData::*_libpaths

Bubke Marco Marco.Bubke at theqtcompany.com
Tue Jan 19 14:23:33 CET 2016


On January 19, 2016 13:42:33 Olivier Goffart <olivier at woboq.com> 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.

But it is a behavior change which are the worst of all. You get  no clear feedback what is wrong but your code is suddenly slow. We should have a version with CoW too. 


> This also assume we can use std in our ABI (which i think we should allow)
>
> 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)
>
> -- 
> Olivier 
>
> Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Sent from cellphone, sorry for the typos



More information about the Development mailing list