[Development] Question about QCoreApplicationData::*_libpaths
milian.wolff at kdab.com
Tue Jan 19 15:19:55 CET 2016
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
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
KDAB - The Qt Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5903 bytes
Desc: not available
More information about the Development