[Development] Question about QCoreApplicationData::*_libpaths

[Milian Wolff]

On Dienstag, 19. Januar 2016 16:09:48 CET Marc Mutz wrote:
> On Tuesday 19 January 2016 14:33:46 Giuseppe D'Angelo wrote:
> > On Tue, Jan 19, 2016 at 3:07 PM, Marc Mutz <marc.mutz at kdab.com> wrote:
> > > 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.
> > 
> > We can't "suddenly" break CoW, though. Who's going to review the millions
> > of lines of code where copies where happily taken assuming they were
> > cheap?
> 
> Who's reviewing the millions of lines of code where hidden detaches are
> happily incurred even though they are not cheap?
> 
> I'd say that if you took copies in a tight loop, you'll notice and the
> profiler will find it for you. And the rest don't matter, or they will be
> found by Clazy.
>
> I doubt many people actively use the fact that Qt containers are cheap to
> copy. But yes, Qt API needs to be reviewed with an eye towards this. Then
> again, Non-Qt C++ would be horribly slow if copying containers was so
> prohibitly expensive.

I completely agree with Marc here. But I think him mentioning Clazy is an 
important point:

Thanks to Clang, it is possible to write tools that automatically convert code 
from one version to another, taking the semantics into account. 

So another option is to write such a tool for Qt 6 that checks where copies 
are made and then notify the user about it so he can investigate it.


-- 
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5903 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160119/5b41284b/attachment.bin>