Re: [Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Marc Mutz wrote:
> best of three runs, core i7-2720QM, GCC 5.3

What OS and C library are you running those benchmarks on? The performance 
of realloc is vastly different between operating systems, so this is 
important information.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Thiago Macieira wrote:
> The copy constructor is called once, then the move constructor. If
> value_type's move constructor is not noexcept, then it may throw after the
> container resized.

Throwing an exception in a move constructor is really, really horrible. I 
can see why a copy constructor would throw (out of memory, failure to 
duplicate some other resource), but a move?

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Marc Mutz wrote:
> He's standing at the front[1] of the queue
> 
> This item has top priority.
> 
> Get it?

The item has top priority, which makes is stand at the front of the priority 
queue and be the head of the priority queue. :-)

Sure, I understand where "top" comes from. It still does not fit the queue 
metaphor.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Bubke Marco wrote:
> So you optimized the container for growing with allocations. I don't think
> it is the most common case. Having cache misses in traversing the
> container can be much worse and is much harder to fix than a reserve.

Almost all my containers grow with allocations. How should I know in advance 
how much memory to reserve? It'd just waste an arbitrary amount of memory 
and then still end up reallocating because it'll inevitably be exceeded at 
some point. Variable-size containers are variable-size for a reason.

I consider reserve() to be a technical detail and a micro-optimization I 
really should not have to bother with in 99+% of the cases.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Thiago Macieira]

On Thursday 21 January 2016 05:33:51 Kevin Kofler wrote:
> Marc Mutz wrote:
> > You can lock a mutex in the function and unlock it in the shared_ptr's
> > deleter.
> 
> How can that possibly be faster than atomic reference counting? You have the
> same cross-thread dependence plus a potential wait for the thread to
> actually do its work. Not to mention that mutexes can cause deadlocks,
> atomic reference counts can't.

It can't be because the simplest mutex lock operation is equivalent to an 
atomic operation, ditto for unlock.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

On Thursday 21 January 2016 05:24:35 Kevin Kofler wrote:
> Marc Mutz wrote:
> > On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote:
> >> All these are horrible and error-prone hacks that have obvious lifetime
> >> issues. You are complaining about Qt containers because the detaching
> >> can invalidate iterators. Well, the lifetime issues you introduce with
> >> the above proposed solutions are much worse! And a caching mutable
> >> member also destroys thread-safety (in addition to the obvious lifetime
> >> issue that the next call surprisingly invalidates your existing
> >> reference).
> > 
> > One word: QModelIndex.
> 
> And that class is the source of innumerable bugs. The fact that one Qt
> class has such broken semantics is no excuse for putting them everywhere.

So how would you have designed it, then?

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[André Somers]

Op 21/01/2016 om 08:00 schreef Marc Mutz:

On Thursday 21 January 2016 05:24:35 Kevin Kofler wrote:

Marc Mutz wrote:

On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote:

All these are horrible and error-prone hacks that have obvious lifetime
issues. You are complaining about Qt containers because the detaching
can invalidate iterators. Well, the lifetime issues you introduce with
the above proposed solutions are much worse! And a caching mutable
member also destroys thread-safety (in addition to the obvious lifetime
issue that the next call surprisingly invalidates your existing
reference).

One word: QModelIndex.

And that class is the source of innumerable bugs. The fact that one Qt
class has such broken semantics is no excuse for putting them everywhere.
Indeed, it is. You will find cases where QModelIndex is stored somewhere 
in many places, also in code writen by people who should know better.

So how would you have designed it, then?

I would have designed something that stays valid. But that's another 
discussion for another thread.


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[André Somers]

Op 21/01/2016 om 05:35 schreef Thiago Macieira:

On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote:

Thiago Macieira wrote:

The copy constructor is called once, then the move constructor. If
value_type's move constructor is not noexcept, then it may throw after the
container resized.

Throwing an exception in a move constructor is really, really horrible. I
can see why a copy constructor would throw (out of memory, failure to
duplicate some other resource), but a move?

Indeed.

But the class in question may not have a move constructor. In the absence of
one, the copy constructor gets called.

I generally don't care. If I can't copy anymore due to running out of 
memory, I'm pretty much done anyway. No reliable way to recover from 
that. Might as well terminate the program.


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Marc Mutz wrote:

> On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote:
>> All these are horrible and error-prone hacks that have obvious lifetime
>> issues. You are complaining about Qt containers because the detaching can
>> invalidate iterators. Well, the lifetime issues you introduce with the
>> above proposed solutions are much worse! And a caching mutable member
>> also destroys thread-safety (in addition to the obvious lifetime issue
>> that the next call surprisingly invalidates your existing reference).
> 
> One word: QModelIndex.

And that class is the source of innumerable bugs. The fact that one Qt class 
has such broken semantics is no excuse for putting them everywhere.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Thiago Macieira]

On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > The copy constructor is called once, then the move constructor. If
> > value_type's move constructor is not noexcept, then it may throw after the
> > container resized.
> 
> Throwing an exception in a move constructor is really, really horrible. I
> can see why a copy constructor would throw (out of memory, failure to
> duplicate some other resource), but a move?

Indeed.

But the class in question may not have a move constructor. In the absence of 
one, the copy constructor gets called.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Binding evaluation during ListView delegate remove animation

[André Somers]

Op 21/01/2016 om 00:45 schreef Andrew den Exter:



On Thu, Jan 21, 2016 at 2:11 AM, Stephen Kelly 
> wrote:




And there are the obvious runtime costs to building and
maintaining a cache that is of little or no use to most people
most of the time, which is I think a strong argument for it being
an off by default feature if implemented.



I think the cost would need to be measured before letting it
influence design decisions. We are not talking about monstrous
amounts of data.


Famous last words.  I have to assume any cache is going to be 
pre-populated with data from every role provided by the model and 
refreshed every time dataChanged is emitted for that row, because the 
views have no knowledge about what roles a delegate queries until 
after the fact, and any binding with a conditional statement in it 
opens up the possibility that a role won't be accessed until after the 
row is removed making on access caching a flaky solution.  How third 
parties implement their models and delegates is a big factor in the 
potential cost of an effective cache, a model with many roles and 
costly access to some of those but with a delegate that only accesses 
a few in bindings may work fine now, but be absolutely hammered by an 
aggressive cache.   And I obviously don't want to see views which 
don't hit this relatively rare combination of circumstances pay that cost.



Actually, I think it would not need to be quite as bad.
For starters, you really only need to cache the actual items being 
removed. At the moment the model emits the AboutToBeRemoved signal, the 
data should still be there in any well-behaved model, right? _That_ is 
the moment you do your caching.


While it is possible that because of conditionals in the binding roles 
are accessed only during the removing, it does not sound very likely. 
One could provide an API to specifically add roles to the caching 
manually, but otherwise only cache roles that have been accessed 
already. Or just only set the roles manually and use that as the on/off 
switch for the whole feature that Andrew requested. Realistically, for 
most models, this would be something like perhaps an image and a couple 
of strings for an item. And these would only need to live for a short 
time, because once the remove animation is done, the data can be removed 
again.


I think it is certainly worthwhile to investigate.

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Mathias Hasselmann]

Am 21.01.2016 um 08:00 schrieb Marc Mutz:

On Thursday 21 January 2016 05:24:35 Kevin Kofler wrote:

Marc Mutz wrote:

On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote:

All these are horrible and error-prone hacks that have obvious lifetime
issues. You are complaining about Qt containers because the detaching
can invalidate iterators. Well, the lifetime issues you introduce with
the above proposed solutions are much worse! And a caching mutable
member also destroys thread-safety (in addition to the obvious lifetime
issue that the next call surprisingly invalidates your existing
reference).


One word: QModelIndex.


Sorry Marc, no. Really.

QModelIndex is entirely unrelated to the problem Eike raised.

I highly reward your expertise and what you are doing for Qt, and I 
really don't want my high opinion of you being spoiled. So please grab 
fine cup of tea, take a comfortable seat and spent some time on 
understanding, why this discussion took such dramatic shift away from 
its initial topic, why you are receiving such heat. Also please take 
some time to recall what other properties but performance are important 
when designing general purpose libraries.



And that class is the source of innumerable bugs. The fact that one Qt
class has such broken semantics is no excuse for putting them everywhere.


So how would you have designed it, then?


One other widespread toolkit actually has tried to implement a 
long-lived model index. This is what those guys came up with:



https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#gtk-tree-row-reference-new

https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#gtk-tree-path-new

https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#gtk-tree-model-get-iter

And no, let's not follow that example. Dealing with GtkTreeModel is just 
painful. QModelIndex is perfectly fine if you use it as intended, as 
short lived reference into a tree model.



Ciao,
Mathias
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Marc Mutz]

On Thursday 21 January 2016 02:02:11 Thiago Macieira wrote:
> On Thursday 21 January 2016 02:37:43 Marc Mutz wrote:
> > On Wednesday 20 January 2016 21:52:49 Thiago Macieira wrote:
> > > On Wednesday 20 January 2016 21:08:07 Pau Garcia i Quiles wrote:
> > > > Replacing QThread with std::thread? Please don't.
> > > 
> > > Unlike the containers or even futures/promises vs QtConcurrent, we can
> > > easily  argue that QThread provides a lot more functionality than
> > > std::thread. In just one word: signals.
> > 
> > What happened to "you're doing it wrong!"? :) AFAIU that blog post,
> > you're supposed to use the signals of QObjects living in that thread,
> > not the QThread itself.
> 
> You can use the signals and the slots of the QThread itself. The wrong part
> was deriving from QThread, adding slots to it and then doing
> moveToThread(this) so those slots got called in the thread that it manages.
> 
> Other uses of QThread are fine. You can derive from it and override run.
> You can even add more signals to it. It's new slots that are suspicious.

Having had to teach this stuff to customers when this came out in Qt 4, I can 
tell you this distinction will not register with most Qt-newbies. Allowing 
such ease of wrong API use is against my reading Qt's own design principles 
("make it hard to use an API incorrectly"). That QThread is a QObject is a 
bug, not a featuee. It would be better as a non-QObject, adding QThreadWatcher 
a la QFutureWatcher to enable singals. In that case, QThread can be replaced 
with std::thread without much loss of generality.

> > And that's perfectly possible with std::thread, too:
> >  auto po = new ProcessingObject();
> >  connect(po, ...);
> >  po->moveToThread(nullptr); // enable "pulling" moveToThread()
> >  auto t = std::thread([po, gui = QThread::currentThread()]() {
> >  
> >  QEventLoop loop;
> >  po->moveToThread(QThread::currentThread());
> >  connect(po, ..., , ::quit);
> >  loop.exec();
> >  po->moveToThread(gui);
> >  // or: delete po;
> >  
> >  }
> > 
> > Am I missing something?
> 
> How do you interrupt the event loop from outside (QThread::quit)? You can't
> create that QEventLoop before the lambda because it would live in the wrong
> thread. You could use this:
> 
>   po->thread()->quit();

That's racy.

You could pass a shared_ptr by reference and use event posting to 
avoid the race.

I'm not saying we don't need new API should we replace QThread with 
std::thead. I'm saying that all the hard, impressive, work is already done. It 
seems to be mostly a question of API now.

> but note how you used QThread. If you're going to use QThread anyway, you
> may as well use it to start the thread.
> Even if you didn't do this, your example uses QThread
> (QThread::currentThread(), which returns a QAdoptedThread pointer). And
> even if you didn't moveToThread(), you created a QObject in that thread
> (the QEventLoop), which will create the QThreadData and the event
> dispatcher machinery.
> 
> At that point, QThread is a simple wrapper full of convenience functions.
> 

I've used current API on purpose to show that it's possible already. All that 
event loop, cross-thread signal/slots and event handling already works for 
std::threads. 

How we'd represent a thread if QThread was dropped is a different question, but 
easily resolved once we get there (QThreadHandle, or even re-using QThread, 
but not as a QObject subclass).

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote:
> Marc Mutz wrote:
> > In those cases where it does matter, you'd return by const-&. Or an
> > array_view. And no, that doesn't restrict your freedom to implement the
> > function in any meaningful way, because you can always keep a caching
> > mutable member to hold the result for the next call to the function
> > (memoisation or however it's called), without any loss except the space
> > required for the member.
> 
> All these are horrible and error-prone hacks that have obvious lifetime
> issues. You are complaining about Qt containers because the detaching can
> invalidate iterators. Well, the lifetime issues you introduce with the
> above proposed solutions are much worse! And a caching mutable member also
> destroys thread-safety (in addition to the obvious lifetime issue that the
> next call surprisingly invalidates your existing reference).

One word: QModelIndex. 

> > What about non-arrays? By the time we get around to all this, there will
> > be no containers other than array-compatible ones left, because nothing
> > else will provide the required speed.
> 
> Sorry, but that is just utter nonsense. Replacing a hash table with an
> array will NOT make your code more efficient. Replacing a linked list with
> an array can also make your code slower if you do enough
> insertions/removals.

In 90s text books, yes. In reality, no. The factors are so large these days 
that big-O complexity is only valid for really, really large containers. The 
vast majority of containers never grow big enough to offset that factor. 
find_if 
even beats lower_bound on a vector, for a large range of sizes (and a cheap 
comparator).

Even in the 90s, Effective STL and Alex Stepanov recommended to use vector 
unless the profiler tells you otherwise. In the past 20 years, the gap has only 
widened.

> In the end, your real issue is not with the containers, but with the
> slowness of the malloc you use. Which means we need faster allocations, not
> containers that minimize allocations at all costs, including worse
> asymptotic algorithmic complexity.

QLinkedList ll = generateRandomLL();
ll.sort();

// no more memory allocs beyond this point

QElapsedTimer timer;
timer.start();
for (int i = 0; i < 1000; ++i)
for (int e : ll)
some cheap payload processing
timer.elapsed();

Then do the same benchmark with a QVector.

If you don't understand why this is slow _as hell_ I suggest you run it on a 
cache profiler. 

Or monitor
  https://www.youtube.com/user/MeetingCPP/playlists
for
  http://meetingcpp.com/index.php/vl15/items/10.html
to become available.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Thiago Macieira]

On Thursday 21 January 2016 02:37:43 Marc Mutz wrote:
> On Wednesday 20 January 2016 21:52:49 Thiago Macieira wrote:
> > On Wednesday 20 January 2016 21:08:07 Pau Garcia i Quiles wrote:
> > > Replacing QThread with std::thread? Please don't.
> > 
> > Unlike the containers or even futures/promises vs QtConcurrent, we can
> > easily  argue that QThread provides a lot more functionality than
> > std::thread. In just one word: signals.
> 
> What happened to "you're doing it wrong!"? :) AFAIU that blog post, you're
> supposed to use the signals of QObjects living in that thread, not the
> QThread itself.

You can use the signals and the slots of the QThread itself. The wrong part 
was deriving from QThread, adding slots to it and then doing 
moveToThread(this) so those slots got called in the thread that it manages.

Other uses of QThread are fine. You can derive from it and override run. You 
can even add more signals to it. It's new slots that are suspicious.

> And that's perfectly possible with std::thread, too:
> 
>  auto po = new ProcessingObject();
>  connect(po, ...);
>  po->moveToThread(nullptr); // enable "pulling" moveToThread()
>  auto t = std::thread([po, gui = QThread::currentThread()]() {
>  QEventLoop loop;
>  po->moveToThread(QThread::currentThread());
>  connect(po, ..., , ::quit);
>  loop.exec();
>  po->moveToThread(gui);
>  // or: delete po;
>  }
> 
> Am I missing something?

How do you interrupt the event loop from outside (QThread::quit)? You can't 
create that QEventLoop before the lambda because it would live in the wrong 
thread. You could use this:

po->thread()->quit();

but note how you used QThread. If you're going to use QThread anyway, you may 
as well use it to start the thread.

Even if you didn't do this, your example uses QThread 
(QThread::currentThread(), which returns a QAdoptedThread pointer). And even 
if you didn't moveToThread(), you created a QObject in that thread (the 
QEventLoop), which will create the QThreadData and the event dispatcher 
machinery.

At that point, QThread is a simple wrapper full of convenience functions.

> > We should provide QThread::makeThread() taking a lambda and some other
> > niceties, though.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Ziller Eike]

> On Jan 20, 2016, at 3:12 PM, Marc Mutz  wrote:
> 
> On Wednesday 20 January 2016 11:48:20 Bubke Marco wrote:
>> I think it would be productive for the discussion to build story of what we
>> want to do. A story of the big picture. Maybe as a first step we can show
>> how we tackle problems with Qt 5 and what are the proposed technologies in
>> the future C++ standard. 
> 
> For me, Qt always was "the C++ standard library that C++ lacked". Ever since 
> Qt 3, it also integrated pretty well with the rest of the standard library. 
> That was easy, because pretty much the only thing that the standard library 
> had and Qt didn't were the algorithms, and Qt and the STL algorithms 
> integrated well. And there were conversion functions for pretty much 
> everything to/from std.
> 
> We even deprecated our algorithms when we started requiring full C++98 
> support 
> in 5.0.
> 
> We used to roll our own atomics, but dropped them in 5.7 when we required 
> partial C++11 support. We rolled our own foreach, and now it looks like we're 
> dropping it in favour of range-for.
> 
> I would like that trend to continue. The likely next candidates are threads, 
> futures and locks.

+1

> Now that C++ punches out a new standard every three years, I would change 
> that 
> into "Qt is the part of the C++ standard library that C++ sill lacks". I 
> would 
> like Qt to continue to integrate well with the standard library and phase out 
> its own solutions as the standard library catches up.
> 
> We have been doing that in the past. It's just as C++ standardisation 
> accelerates, so will the need to phase out Qt features that got superseded.
> 
> I perceive, however, that for many people, Qt is what makes them forget 
> they're working on C++, a language they would not otherwise poke at with a 
> long stick. They probably also cannot tolerate writing std::sort(v.begin(), 
> v.end()) instead of qSort(v).

I find it much nicer and more readable if I can just write sort(v).

Or "const List foos = transformed(myThings, ::foo);"
instead of "List foos; std::transform(myThings.begin(), myThings.end(), 
std::back_inserter(foos), std::mem_fn(::foo));”
(notice that “foos” is also not const in the “pure" std version)

We started some experiments with convenience wrappers for std algorithms for 
use in Qt Creator when we started requiring C++11:
http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/algorithm.h

>  But Qt is available in D and Python, too, so ... 
> why do they use C++ if they so hate it?

Maybe they don’t hate it, but still wished it had a less verbose API if you 
don’t need the verbosity.

Br, Eike

-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[André Somers]

Op 20/01/2016 om 15:48 schreef Ziller Eike:

On Jan 20, 2016, at 3:12 PM, Marc Mutz  wrote:

On Wednesday 20 January 2016 11:48:20 Bubke Marco wrote:

I think it would be productive for the discussion to build story of what we
want to do. A story of the big picture. Maybe as a first step we can show
how we tackle problems with Qt 5 and what are the proposed technologies in
the future C++ standard.

For me, Qt always was "the C++ standard library that C++ lacked". Ever since
Qt 3, it also integrated pretty well with the rest of the standard library.
That was easy, because pretty much the only thing that the standard library
had and Qt didn't were the algorithms, and Qt and the STL algorithms
integrated well. And there were conversion functions for pretty much
everything to/from std.

We even deprecated our algorithms when we started requiring full C++98 support
in 5.0.

We used to roll our own atomics, but dropped them in 5.7 when we required
partial C++11 support. We rolled our own foreach, and now it looks like we're
dropping it in favour of range-for.

I would like that trend to continue. The likely next candidates are threads,
futures and locks.

+1


Now that C++ punches out a new standard every three years, I would change that
into "Qt is the part of the C++ standard library that C++ sill lacks". I would
like Qt to continue to integrate well with the standard library and phase out
its own solutions as the standard library catches up.

We have been doing that in the past. It's just as C++ standardisation
accelerates, so will the need to phase out Qt features that got superseded.

I perceive, however, that for many people, Qt is what makes them forget
they're working on C++, a language they would not otherwise poke at with a
long stick. They probably also cannot tolerate writing std::sort(v.begin(),
v.end()) instead of qSort(v).

I find it much nicer and more readable if I can just write sort(v).

Or "const List foos = transformed(myThings, ::foo);"
instead of "List foos; std::transform(myThings.begin(), myThings.end(), 
std::back_inserter(foos), std::mem_fn(::foo));”
(notice that “foos” is also not const in the “pure" std version)

We started some experiments with convenience wrappers for std algorithms for 
use in Qt Creator when we started requiring C++11:
http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/algorithm.h


Nice, thanks for the link.

At a previous job, I ended up defining a macro called all (and a 
constAll) that just expanded to begin(v), end(v). That already helped in 
how verbose the calls to algorithms looked.


std::sort(all(v))

vs

std::sort(begin(v), end(v));

Sure, a macro is ugly, but it did the trick. When you need more control, 
you can specify begin and end explicitly, of course.





  But Qt is available in D and Python, too, so ...
why do they use C++ if they so hate it?

Maybe they don’t hate it, but still wished it had a less verbose API if you 
don’t need the verbosity.
Indeed. After watching some courses by Stephanov, I actually learned to 
appreciate it. But I stil dislike the API in many places. C++11 makes 
much of the std easier to digest though.


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Jędrzej Nowacki]

On Tuesday 19 of January 2016 13:51:56 Marc Mutz wrote:
> On Tuesday 19 January 2016 11:15:43 Milian Wolff wrote:
> > On Dienstag, 19. Januar 2016 11:51:42 CET Marc Mutz wrote:
> > > I missed one:
> > > 
> > > On Monday 18 January 2016 23:43:37 Marc Mutz wrote:
> > > > #include 
> > > > #include 
> > > > 
> > > > int main() {
> > > > 
> > > > QVector l;
> > > > int oldC = l.capacity();
> > > > for (int i = 0; i < 1000; ++i) {
> > > > 
> > > > char buf[std::numeric_limits::digits + 1];
> > > > sprintf(buf, "%d", i);
> > > > l.push_back(buf);
> > > > int newC = l.capacity();
> > > > if (newC != oldC)
> > > > 
> > > > qDebug("%d", newC);
> > > > 
> > > > oldC = newC;
> > > > 
> > > > }
> > > > 
> > > > }
> > > > 
> > > > $ time ./test
> > > > 
> > > > real0m1.769s
> > > > user0m1.572s
> > > > sys 0m0.192s
> > > 
> > > Same with std::vector:
> > > 
> > > real0m1.776s
> > > user0m1.616s
> > > sys 0m0.156s
> > > 
> > > > best of three runs, core i7-2720QM, GCC 5.3
> > > 
> > > Ditto.
> > > 
> > > So... is realloc actually the optimisation everyone (incl. me) expected
> > > it to be?
> > 
> > Did you run it through a profiler? Where is the time actually spent?
> 
> No. It's not the IO, though. Removing the qDebug() and capacity tracking, it
> performs the same, within error margins.

Hi, 

  I can not reproduce the numbers on gcc version 5.3.1 20151219 (Debian 
5.3.1-4). But there is a bug in the benchmark, std::vector and QVector have 
different grow model, at least I do not see the same count of qDebug messages.
In addition I think the benchmark may be affected by heap allocation executed 
on each l.push_back.

 The feature is also used in QVariant which tries to avoid allocations. That 
was confirmed as important optimization.

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebEngine on x86 without SSE2

[Kevin Kofler]

Allan Sandfeld Jensen wrote:
> We made the same decision in Qt to not use X86 without SSE2 by default.

I know. Fedora builds Qt with -no-sse2, and portions where it is important 
are built twice the same way I'm doing with V8 (e.g., QtDeclarative and 
QtWebKit to take advantage of the V4 resp. JSCore JIT, which both require 
SSE2).

> That it is linux only also doesn't bother me, SSE2 are already a hard
> requirements for the OSX and Windows platforms we support. This is really
> only an issue for Linux distros that have outdated minimum requirements.
> 
> Of course it might be might be easier to keep it as a distro patch only
> since it looks like an original chromium patch ported to qtwebengine.

Yes, to be honest, I don't expect you to carry this in Qt. It touches mostly 
Chromium code, where you are trying to keep the delta minimal. (But if 
you're willing to do so, I can submit it in the appropriate way.) I 
developed my patch for QtWebEngine specifically, but about half of it is a 
cumulative revert of upstream Chromium patches, and most of it can be reused 
for Chromium packages. (Obviously, the changes to .pro/.pri files are 
QtWebEngine-specific.)

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Marc Mutz]

On Wednesday 20 January 2016 16:03:17 André Somers wrote:
> Op 20/01/2016 om 15:48 schreef Ziller Eike:
> >> On Jan 20, 2016, at 3:12 PM, Marc Mutz  wrote:
> >> 
> >> On Wednesday 20 January 2016 11:48:20 Bubke Marco wrote:
> >>> I think it would be productive for the discussion to build story of
> >>> what we want to do. A story of the big picture. Maybe as a first step
> >>> we can show how we tackle problems with Qt 5 and what are the proposed
> >>> technologies in the future C++ standard.
> >> 
> >> For me, Qt always was "the C++ standard library that C++ lacked". Ever
> >> since Qt 3, it also integrated pretty well with the rest of the
> >> standard library. That was easy, because pretty much the only thing
> >> that the standard library had and Qt didn't were the algorithms, and Qt
> >> and the STL algorithms integrated well. And there were conversion
> >> functions for pretty much everything to/from std.
> >> 
> >> We even deprecated our algorithms when we started requiring full C++98
> >> support in 5.0.
> >> 
> >> We used to roll our own atomics, but dropped them in 5.7 when we
> >> required partial C++11 support. We rolled our own foreach, and now it
> >> looks like we're dropping it in favour of range-for.
> >> 
> >> I would like that trend to continue. The likely next candidates are
> >> threads, futures and locks.
> > 
> > +1
> > 
> >> Now that C++ punches out a new standard every three years, I would
> >> change that into "Qt is the part of the C++ standard library that C++
> >> sill lacks". I would like Qt to continue to integrate well with the
> >> standard library and phase out its own solutions as the standard
> >> library catches up.
> >> 
> >> We have been doing that in the past. It's just as C++ standardisation
> >> accelerates, so will the need to phase out Qt features that got
> >> superseded.
> >> 
> >> I perceive, however, that for many people, Qt is what makes them forget
> >> they're working on C++, a language they would not otherwise poke at with
> >> a long stick. They probably also cannot tolerate writing
> >> std::sort(v.begin(), v.end()) instead of qSort(v).
> > 
> > I find it much nicer and more readable if I can just write sort(v).
> > 
> > Or "const List foos = transformed(myThings, ::foo);"
> > instead of "List foos; std::transform(myThings.begin(), myThings.end(),
> > std::back_inserter(foos), std::mem_fn(::foo));” (notice that
> > “foos” is also not const in the “pure" std version)
> > 
> > We started some experiments with convenience wrappers for std algorithms
> > for use in Qt Creator when we started requiring C++11:
> > http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/alg
> > orithm.h
> 
> Nice, thanks for the link.
> 
> At a previous job, I ended up defining a macro called all (and a
> constAll) that just expanded to begin(v), end(v). That already helped in
> how verbose the calls to algorithms looked.
> 
> std::sort(all(v))
> 
> vs
> 
> std::sort(begin(v), end(v));
> 
> Sure, a macro is ugly, but it did the trick. When you need more control,
> you can specify begin and end explicitly, of course.
> 
> >>   But Qt is available in D and Python, too, so ...
> >> 
> >> why do they use C++ if they so hate it?
> > 
> > Maybe they don’t hate it, but still wished it had a less verbose API if
> > you don’t need the verbosity.
> 
> Indeed. After watching some courses by Stephanov, I actually learned to
> appreciate it. But I stil dislike the API in many places. C++11 makes
> much of the std easier to digest though.

Then now is the time to chime in on the C++ ranges proposal and voice your 
opinion(s).

"Let him speak now or forever hold his peace" :)

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Binding evaluation during ListView delegate remove animation

[Stephen Kelly]

On 20/01/16 01:23, Andrew den Exter wrote:
On Wed, Jan 20, 2016 at 2:13 AM, Stephen Kelly 
> wrote:


The solution could be to cache data retrieved from the model.


That's a more complex solution than you might think.  It's a pretty 
popular pattern to populate a model with QObjects for example and with 
a naive cache of QVariants what was an admittedly annoying binding 
evaluation error becomes a much more severe dereference of a dangling 
pointer.




Indeed. What I have been considering is limiting the types which are 
cached to those which can directly be put into a user interface element 
- built in types like strings, numbers, colors etc. Maybe even any gadget.


It could be possible to special case model data which is-a OQbject 
pointer (QMetaType has API for that) and cache that too, but then we'd 
just be caching null pointers, so thinking this through leads me to 
think that's not useful.


That's the kind of design discussion that I would like to have in this 
thread though (as it is easier in email than in gerrit), so thanks for that.


And there are the obvious runtime costs to building and maintaining a 
cache that is of little or no use to most people most of the time, 
which is I think a strong argument for it being an off by default 
feature if implemented.




I think the cost would need to be measured before letting it influence 
design decisions. We are not talking about monstrous amounts of data.


If you do have this problem, right now the solution is to bind the 
model value to a property in your delegate and use the property in 
your binding.


Indeed. That is an ad-hoc cache that a client can implement. It doesn't 
really scale well as a design, or as guidance for a team of developers.


  The property binding will only be re-evaluated when the model data 
changes so it won't ever try and access the model after the row has 
been removed.




Yes, semantically this is quite similar to what I propose, but is not 
scalable.


It is an issue and by all means investigate a solution, but there is a 
simple means to deal with it at a user level and I'm personally wary 
of the complexity and repercussions of fixing it in the views.


I don't think that solution is

* intuitive
* maintainable in a changing team
* easy to get right/hard to get wrong

so I don't really agree that it is 'simple'.

Thanks,

Steve.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtWebEngine on x86 without SSE2

[Allan Sandfeld Jensen]

On Wednesday 20 January 2016, Kevin Kofler wrote:
> Hi,
> 
> distribution packagers may be interested in this experimental patch:
> http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/tree/qtwebengin
> e-opensource-src-5.6.0-beta-no-sse2.patch which should make QtWebEngine
> work on 32-bit x86 (i686) CPUs without SSE2 (and also without MMX nor SSE
> 1), while detecting SSE2 (and SSE 1 and MMX) at runtime wherever possible.
> V8 is built as a shared library, twice (once with the x87 backend and once
> with the SSE2 one), and the GNU/Linux ld.so feature where it will
> automatically look under an sse2 subdirectory of the rpath for a
> SSE2-enabled library on SSE2 machines is taken advantage of.
> 
> The floating-point issues in the media player that made Chromium upstream
> require SSE2 should already be worked around by this upstream commit:
> https://crrev.com/d2c745b13c93ecff5108bed57d8e052126715492
> so x87 should really be fine again. If not, the fix would be to build
> individual parts of the code with -ffloat-store.
> 
> I verified that this builds on GNU/Linux on i686, on x86_64 (where SSE2 is
> part of the baseline and can thus be assumed safely) and on ARM (where SSE2
> does not exist at all and so the patch should have no effect). I have not
> done runtime testing yet.
> 
> I did not try other platforms yet. The dual V8 trick will not work on
> platforms that do not have the same ld.so SSE2 feature, and my code that
> handles the V8 trick also hardcodes the .so extension. So you would
> probably have to remove those parts and just live with x87 V8.
> 
> Unfortunately, since this is an override of a deliberate upstream Chromium
> decision and partly a cumulative revert of several upstream Chromium
> commits, I do not expect this to be accepted upstream, ever.
> 

We made the same decision in Qt to not use X86 without SSE2 by default.

That it is linux only also doesn't bother me, SSE2 are already a hard 
requirements for the OSX and Windows platforms we support. This is really only 
an issue for Linux distros that have outdated minimum requirements.

Of course it might be might be easier to keep it as a distro patch only since 
it looks like an original chromium patch ported to qtwebengine.


Best regards
`Allan Jensen
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt3d: Scene32d framebuffer size

[Łukasz Korbel]

Hi!

I'm not sure of the source of problem so first quick introduction:

1. I want to set Camera properly to show object in Scene3d which is smaller
then QWindow.
2. I want to make proper mapping between qml view 2d coordinates and scene
3d coordinates (for example place some 3d object at location pointed by
mouse click).

I've solved those two issue in example qml code attached to the message.
This example lead to my actual question:

It looks like Scene3d frame buffer is somehow bound to dimension of
QWindow. So If I set Scene3d to be smaller it shows only fragment of
framebuffer. More precisely its part cut from left-bottom corner of buffer
matching scene size. Does it expected behaviour for this class? It leads to
few "funny", additional computations in order to set camera properly.

If I making some mistake by mentioning frame bufffer in this context then I
apologize. Still hope that my example explains what is a problem. I guess
it is worth discussing with someone involved in development and maybe its
not a bug, so I've raised topic here.

Regards,

*Łukasz Korbel *
Senior Software Developer
Email: lkor...@milosolutions.com
Skype: lukasz_korbel
*Milo Solutions*
www.milosolutions.com | Facebook 
| Twitter 
Disclaimer: This e-mail and any attachments contain information that may be
privileged or confidential and is the property of Milo Solutions. If you
are not the intended recipient, please notify me immediately by replying to
this e-mail, and then delete it. Any unauthorised
dissemination, distribution, copying or use of this communication is
strictly prohibited. The contents of an attachment to this e-mail may
contain software viruses, which could damage your own computer system.
Although this e-mail and any files attached to it may have been checked
with virus detection software before transmission you should carry out your
own virus checks before opening the attachment. No liability can be
accepted for any damage which you may sustain as a result of software
viruses.
import QtQuick 2.0
import QtQuick.Window 2.0
import QtQuick.Scene3D 2.0
import Qt3D 2.0
import Qt3D.Renderer 2.0

Rectangle {
id: win
width: 1280; height: 800
visible: true
color: "black"

property real alpha: 50
property real ratio: width/height

//area to be full shown in scene
property real area_width: 326
property real area_height: 176

//scene central point
property real center_x: area_width / 2 + (height-scene.height)*dx/height
property real center_y: area_height / 2 - (width-scene.width)*dy/width
property real center_z: 0.5 * (win.height/scene.height) * area_width / Math.tan(alpha*Math.PI/360) + position_z

//distance from center to border of visible range
property real dx: (center_z-position_z) * Math.tan(alpha*Math.PI/360)
property real dy: ratio*dx

//scene offset on view y-axis
property real off_y: height > scene.height ? height-scene.height : 0;

//position of sphere
property real position_x: center_x+dx-off_y*2*dx/win.height
property real position_y: center_y+dy
property real position_z: 0

Scene3D {
x: 425; y: 175
width: 300; height: 500
focus: true
aspects: "input"
id: scene

Entity {
id: root

components: FrameGraph {
activeFrameGraph: Viewport {
id: viewport
rect: Qt.rect(0, 0, 1, 1)
clearColor: "white"
CameraSelector {
   id : cameraSelector
   camera: camera
   ClearBuffer {
  buffers : ClearBuffer.ColorDepthBuffer
   }
}
}
}

Camera {
id : camera
projectionType: CameraLens.PerspectiveProjection
fieldOfView: alpha
aspectRatio: ratio
nearPlane : center_z-position_z - 100
farPlane :  center_z-position_z
position: Qt.vector3d(center_x,center_y,center_z)
upVector: Qt.vector3d(1.0, 0.0, 0.0)
viewCenter: Qt.vector3d(center_x,center_y,0)
}

 PhongMaterial {
id: material
}
SphereMesh {
id: sphereMesh
radius: 10
}
Transform {
id: sphereTransformation
Translate{ translation: Qt.vector3d(position_x,position_y,position_z)}
}

Entity {
components: [sphereMesh, sphereTransformation, material]
}

CuboidMesh{
id: ground
xExtent: area_width
yExtent: area_height
zExtent: 1
xyMeshResolution: Qt.size(2,2)
xzMeshResolution: Qt.size(2,2)
yzMeshResolution: Qt.size(2,2)
}
Transform {
id: groundTransformation
Translate{ translation: 

Re: [Development] What kind of airplane we want to build?

[charleyb123 .]

Thiago sayeth:


> So no, I don't think we risk becoming irrelevant against other airplane
> makers
> anytime soon. Our competitor are those transatlantic heavyweight ships
> (HTML5).
>
,

LOL!!!

That's actually a very good point (in addition to the fact that I really
did Laugh-Out-Loud).

C++ is growing, and native-client apps are growing (mobile, embedded,
desktop, cloud).

The Qt value-proposition gets you native on that platform better than
anything else, including the C++ Standard (which is merely a language
standard, and not a technology platform).

We would likely get quite a few blank stares when walking into a bar for
programmers (do those exist?) and shouting, "C++ is easily approachable!"
 However, we'd get many nods-of-agreement saying the same about Qt.

--charley
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Marc Mutz wrote:
> And if API consistency makes QVector have a prepend(), and QHash::iterator
> have it + n, something got out of hand...

I appreciate that Qt makes those operations possible (without having to code 
them by hand). I know that operations such as QVector::prepend are not 
efficient. That's clearly documented, and follows directly from even the 
roughest description of how the class is implemented. (That said, for the 
particular case of QVector::prepend, that could easily be fixed with the 
same trick used in QList.) Sometimes, a given container is clearly the most 
efficient for the parts of the application that run 99% of the time, having 
a single O(n) operation in the remaining 1% is not going to hurt overall 
efficiency.

As for adding n to a QHash::iterator, sure, most people won't use it, but 
then it doesn't really hurt to have it there. And there may even be use 
cases where it makes sense. (For example, to divide a hash table into n hash 
tables minimizing the hash collisions. Taking every n-th element sounds like 
a reasonable approach there.)

I consider STL's inconsistent APIs from one container to the other to be a 
major annoyance. And it is not even always about efficiency: e.g., 
std::queue and std::priority_queue are implemented in the SAME header 
, both are queues, yet std::queue calls its head element front(), 
std::priority_queue calls it top().

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Thiago Macieira wrote:
> We can only do that efficiently if we drop CoW. Creating an adapting API
> is easy; making sure we don't do unnecessary copies because we've lost CoW
> is the hard part.

Would it be possible to wrap a QSharedDataPointer, where 
class VectorData : public QSharedData, public std::vector? That would 
still be layered above std::vector (and d.data() would give you something 
that is-a std::vector) yet CoW. Or are there reasons why such an approach 
would not be workable for std::vector?

Now I think the current QVector implementation is fine, but I'm also not 
convinced wrapping std::vector requires dropping CoW. The problems would 
probably show up somewhere else.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Bo Thorsen wrote:
> Den 19-01-2016 kl. 15:00 skrev Marc Mutz:
>> In Qt 6:
>> 1. ... dropping CoW ...
> 
> I'm against any change that does this.
> 
> I know you hate and loathe them. I don't. I think this alone makes Qt
> containers worth while. And it doesn't matter what arguments you give, I
> already know and understand them. The pros of CoW to me outweigh the
> cons. We disagree on this, and that's perfectly okay.

So far, we completely agree (and I disagree with Marc Mutz).

> However, there are also things in this argument where I agree with you.
> I do think there are more containers in Qt than necessary. It's not
> necessarily the case that Qt needs to have all types of lists, for
> example. And I would like to see Qt offer the use of std:: containers in
> the API.

But there, I don't follow:
* To the user, this would effectively remove CoW support for the containers
  you want to drop from Qt.
* The API would also result in an inconsistent mess.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Marc Mutz wrote:
> No-one, not even experts understand QList, really. So it may appear to be
> easy to use, but is actually a container only absolute experst should use.

QList gives people who just don't care about the internals something closer 
to optimal than any of the containers optimized for a specific use case. The 
worst case for QList operations is O(n+m) (for a list of n elements of size 
≤ m each), rather than O(n m) as for QVector or std::vector (with the 
obvious exception of sorting, which, assuming that 2 elements can be 
compared in O(1), is O(m n log(n)) for QVector and std::vector and only
O(n log n) for QList). So I think it is a GOOD class for beginners to use.

Of course one can use a std::vector, but then you lose the value 
semantics.

> And a QVector provides exactly the same guarantees as a std::vector. How
> come one is easier to use than the other? Because QVector has indexOf()?
> And what about those cases where the user wants to find an element by just
> a field? They will write for loops, most likely, and not use algorithms.

Sure, algorithms are more flexible in theory, but they are also less 
intuitive than a straightforward API such as indexOf. That's the very reason 
people are tempted to write loops rather than using algorithms. There's 
nothing preventing people from using algorithms on QVector, is there? The 
indexOf method surely isn't it.

> The crucial point here is that there's no "better" Qt API for this than
> what exists on std::vector. Instead, there's a much more complicated API
> by sheer volume and duplication, without being near extensive enough for
> even very simple tasks. At some point, the question must be asked whether
> CoW and append() vs. push_back() do not become more of a burden than a
> merit. And whether we need three names for size().

What you call "volume", I call "completeness". And most of the "duplication" 
is compatibility with the ugly STL names (source compatibility, template 
algorithm compatibility). So it's the STL's fault that we have duplication. 
Just don't use the ugly STL names, ever. (push_back does not even comply to 
Qt naming guidelines. Always use append/prepend/removeLast/removeFirst 
instead of push_back/push_front/pop_back/pop_front. And Qt also has a real 
pop unlike the misleadingly-named STL one: takeLast/takeFirst.)

And the reason the STL API is horrible is not only the incompleteness, but 
also the terse, inconsistent (e.g., std::queue::front vs. 
std::priority_queue::top) and misleading (e.g., pop* methods that do not 
return the popped element) names.

>> The main question IMO is how we can bring these two worlds closer
>> together for Qt 6 (or maybe even to some extent in Qt 5.x).
> 
> My answer would be to use std containers exclusively, and write a
> wagonload full of Qt-level docs about them, ie. integrate them into the Qt
> docs.

And my answer would be to ban the std containers from Qt entirely and 
restore support for QT_NO_STL.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

On Wednesday 20 January 2016 20:48:42 Kevin Kofler wrote:
> I consider STL's inconsistent APIs from one container to the other to be a 
> major annoyance. And it is not even always about efficiency: e.g., 
> std::queue and std::priority_queue are implemented in the SAME header 
> , both are queues, yet std::queue calls its head element front(), 
> std::priority_queue calls it top().

He's standing at the front[1] of the queue

This item has top priority.

Get it?

I guess you'll also find these terms in text books.

[1] Yes, "head". I guess Alex Stepanov can be excused for picking this one 
"wrong". With head(), the other-end function would have had to be tail() and 
that's just wrong for a person, as he was, coming from Lisp. A list's tail is 
the rest of the list, after the head.

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Marc Mutz wrote:
> I doubt many people actively use the fact that Qt containers are cheap to
> copy.

Count me as a person who does (and not only for the obvious return value 
case, where compiler optimizations or move semantics might possibly help). 
For example, I have written a parser where the whole sharing of parse 
subtrees is based on implicitly-shared data structures.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Pau Garcia i Quiles]

On Wed, Jan 20, 2016 at 3:25 PM, Bo Thorsen  wrote:


>
> Why do you think people hate C++? I love C++ but I hate the string
> classes. I like some part of the std containers, I don't like their API.
>
>
Spot on.

People run scared from Boost-like C++. That kind of code is very performant
but it's neither easy to write, understand or, in many cases, figure out.

On the other hand, Qt is usually love at first sight. Makes C++ look
doable. Even easy. Sure, some people who have spent a lot of time writing
C++ move on from Qt and like Boost-like code the better but that kind of
code, those APIs, are to blame for the very bad opinion many people have on
C++. They hurt C++ jobs.

Replacing QThread with std::thread? Please don't.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Matthew Woehlke]

On 2016-01-20 15:08, Pau Garcia i Quiles wrote:
> Replacing QThread with std::thread? Please don't.

Uh... that had *better* not happen, come to think of it. QThread is a
QObject, which means it has signals/slots and an event loop. It is a LOT
more featureful than std::thread, which is (mostly) just a handle. (That
said... having a QThread member to *get* the std::thread may be a good
idea...)

Mutexes and the like are another matter.

-- 
Matthew

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Bubke Marco]

On January 20, 2016 21:08:50 Pau Garcia i Quiles  wrote:

> On Wed, Jan 20, 2016 at 3:25 PM, Bo Thorsen 
> > wrote:
>
>
> Why do you think people hate C++? I love C++ but I hate the string classes. I 
> like some part of the std containers, I don't like their API.
>

I really think professional developers are not driven by their emotions but by 
reason and arguments. I think as a productive developer you should always train 
your ability to get in a new context. 

>
> Spot on.
>
> People run scared from Boost-like C++. That kind of code is very performant 
> but it's neither easy to write, understand or, in many cases, figure out.

Yes but with const expressions and concepts the code gets  readable again. 

> On the other hand, Qt is usually love at first sight. Makes C++ look doable. 
> Even easy. Sure, some people who have spent a lot of time writing C++ move on 
> from Qt and like Boost-like code the better but that kind of code, those 
> APIs, are to blame for the very bad opinion many people have on C++. They 
> hurt C++ jobs.

It really depends, not everything in boost its bad. The futures are nice. And 
the big problem are templates but concept should make templates easier to 
program. 

> Replacing QThread with std::thread? Please don't.

I think it is more a question of maintenance. I prefer std::tread because it is 
quite simple. 

>
> --
> Pau Garcia i Quiles
> http://www.elpauer.org
> (Due to my workload, I may need 10 days to answer)

--
Sent from cellphone, sorry for the typos
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Thiago Macieira]

On Wednesday 20 January 2016 21:08:07 Pau Garcia i Quiles wrote:
> Replacing QThread with std::thread? Please don't.

Unlike the containers or even futures/promises vs QtConcurrent, we can easily 
argue that QThread provides a lot more functionality than std::thread. In just 
one word: signals.

We should provide QThread::makeThread() taking a lambda and some other 
niceties, though.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Thiago Macieira]

On Wednesday 20 January 2016 20:48:42 Kevin Kofler wrote:
> (That said, for the 
> particular case of QVector::prepend, that could easily be fixed with the 
> same trick used in QList.)

In Qt 6. Due to the way QArrayData is currently designed, you cannot reserve 
space at the beginning without making the container (QString, QByteArray, 
QVector) think that they're operating on foreign data (fromRawData).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Corentin Jabot]

First of, it should be ensured future planes fit on the tarmac and that
people now how to fly these things. Major breakage are a huge pain.
Unavoidable minor breakage are painful enough, we always seem to
underestimate the cost of any stack change. The plane metaphor still holds.
You need to rebuild your production line, teach your staff, assert the damn
thing and then you spend the next tens year working all the kinks. It's
easier for Qt, but still a cost.

That being said...

The Qt framework, the whole KDE environment and all the app using Qt are a
massive part of the C++ ecosystem. And yet there is this great divide
between Qt and the rest of the C++ world. It funnily goes both ways. It
would be great if the Qt community was more involved with C++, whether by
participating in the standardization process, conferences and such. And
maybe that would in turn help the greater C++ community have a better
understanding of Qt ?

A few days ago I learned KDAB was a member of the vulkan group. how cool is
that ? But when I think about it, it's nothing but the logical move.

Then, there is moc. I observed C++ devs outside of the Qt community will
often use moc as an argument in favor of not using Qt. It seems more of an
ideological argument that anything else. Whereas where I stand, moc is what
make Qt great. Of course I which moc was more flexible and more easily
integrated with a foreign build system but still. I don't think C++ will
ever have half of the introspection Qt provides. And don't even get me
started on CopperSpice. Ugh.

On the other hand, qmake should probably not be recommended way to build a
Qt app in the future.

I cannot point to specific apis or pain points because again, I value a
smooth / pragmatic evolution. Take QSharedPointer. it really do not have a
reason to be beside the fact removing it will do nothing but cost thousands
of hours to get rid of across the industry.

Overall, the current approach of allowing idiomatic C++ apis when doable is
quite good. Qt do age quite well. Maybe using the std in example/snippets
more ?

The Standard has great engines. Qt has comfy seats. Lets have a plane with
great engines and comfy seats.













2016-01-20 20:16 GMT+01:00 charleyb123 . :

> Thiago sayeth:
> 
>
>> So no, I don't think we risk becoming irrelevant against other airplane
>> makers
>> anytime soon. Our competitor are those transatlantic heavyweight ships
>> (HTML5).
>>
> ,
>
> LOL!!!
>
> That's actually a very good point (in addition to the fact that I really
> did Laugh-Out-Loud).
>
> C++ is growing, and native-client apps are growing (mobile, embedded,
> desktop, cloud).
>
> The Qt value-proposition gets you native on that platform better than
> anything else, including the C++ Standard (which is merely a language
> standard, and not a technology platform).
>
> We would likely get quite a few blank stares when walking into a bar for
> programmers (do those exist?) and shouting, "C++ is easily approachable!"
>  However, we'd get many nods-of-agreement saying the same about Qt.
>
> --charley
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Thiago Macieira]

On Wednesday 20 January 2016 20:05:08 Kevin Kofler wrote:
> Thiago Macieira wrote:
> > We can only do that efficiently if we drop CoW. Creating an adapting API
> > is easy; making sure we don't do unnecessary copies because we've lost CoW
> > is the hard part.
> 
> Would it be possible to wrap a QSharedDataPointer, where
> class VectorData : public QSharedData, public std::vector? That would
> still be layered above std::vector (and d.data() would give you something
> that is-a std::vector) yet CoW. Or are there reasons why such an approach
> would not be workable for std::vector?

This causes double indirection to the data, something we've worked hard to 
avoid. The most common operation you do on a vector is access an element, so 
that should be fast.

Here's what the begin() const functions look like:

libc++: return __make_iter(this->__begin_);
libstdc++:return const_iterator(this->_M_impl._M_start);
QVector:return d->constBegin();
->  return data();
->  return static_cast(QArrayData::data());
->  return reinterpret_cast(this) + offset;
(all inline)

or in my implementation, QArrayDataPointer::data() does:
return ptr;

The important thing to note is that there's exactly one pointer dereferenced 
at all: this. Current QVector already loses a little by having 
QArrayData::offset added.

But if we did what you suggest, then here's what QVector::begin() const would 
look like:

typename std::vector::const_iterator begin() const
{ return this->d->begin(); }

Now we needed to dereference this *and* the d pointer. This means potentially 
two cachelines being read from and there's a data dependency, which in turn 
means potential pipeline stall.

> Now I think the current QVector implementation is fine, but I'm also not
> convinced wrapping std::vector requires dropping CoW. The problems would
> probably show up somewhere else.

The options are:
 a) accept the extra dereferencing
 b) not wrap std::vector, but continue with our own array management
 c) drop CoW

As I told Lars last night / this morning over IRC, what I would love to have 
is an improved version of Qt 5's unsharable containers mode:

templateusing QVector = QtTools::Vector;
using QString = QtTools::String;

where QtTools::Vector can do both CoW and non-CoW modes. You'd be 
able to write code like:

QString foo()
{
QtTools::String s(size, Qt::Uninitialized);
fill(s.data(), size);   // no useless detach() emitted!
foreach (auto ch : s)   // ditto
process(ch);
return s;   // move-construction "steals" 
buffer
}

QtTools::String s = foo();  // move-construction attempts to steal

The Unsharable modes for the containers would have the same complexity and 
behaviour as the Standard Library counterparts. But they'd do more, since 
they'd interoperate with the CoW containers too.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Thiago Macieira]

On Wednesday 20 January 2016 13:17:35 Thiago Macieira wrote:
> return s;   // move-construction
> "steals" buffer }
> 
> QtTools::String s = foo();  // move-construction attempts to
> steal

And in case the consequence isn't clear from the comment: the *stealing* 
prevents us from using actual std::vector for being the backend of our 
containers, not without having the double indirection the first part of the 
email talked about.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Thiago Macieira]

On Wednesday 20 January 2016 22:25:27 Kevin Kofler wrote:
> And Qt also has a real 
> pop unlike the misleadingly-named STL one: takeLast/takeFirst.

In the Standard Library's defence: the pop() function does not return the 
element due to exception-safety. Example:

value_type takeLast() { value_type v = last(); remove(size() - 1); return 
v; }

The copy constructor is called once, then the move constructor. If 
value_type's move constructor is not noexcept, then it may throw after the 
container resized.

You could add this overload to solve it:

void pop(value_type ) { where = back(); pop(); }

But then your code looks like:

Element e;  // may throw, allocate resources, etc.
v.pop(e);

instead of:

Element e = v.back();   // move-constructed
v.pop();

Also note that this overload would keep the integrity of the container, but 
not necessarily your data.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Marc Mutz wrote:
> In those cases where it does matter, you'd return by const-&. Or an
> array_view. And no, that doesn't restrict your freedom to implement the
> function in any meaningful way, because you can always keep a caching
> mutable member to hold the result for the next call to the function
> (memoisation or however it's called), without any loss except the space
> required for the member.

All these are horrible and error-prone hacks that have obvious lifetime 
issues. You are complaining about Qt containers because the detaching can 
invalidate iterators. Well, the lifetime issues you introduce with the above 
proposed solutions are much worse! And a caching mutable member also 
destroys thread-safety (in addition to the obvious lifetime issue that the 
next call surprisingly invalidates your existing reference).

> What about non-arrays? By the time we get around to all this, there will
> be no containers other than array-compatible ones left, because nothing
> else will provide the required speed.

Sorry, but that is just utter nonsense. Replacing a hash table with an array 
will NOT make your code more efficient. Replacing a linked list with an 
array can also make your code slower if you do enough insertions/removals.

In the end, your real issue is not with the containers, but with the 
slowness of the malloc you use. Which means we need faster allocations, not 
containers that minimize allocations at all costs, including worse 
asymptotic algorithmic complexity.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Thiago Macieira]

On Wednesday 20 January 2016 23:43:07 Giuseppe D'Angelo wrote:
> This poses further questions down the line, such as whether it's "ok" 
> having an index API based on signed integers. (It is for convenience, it 
> is not for correctness, but I guess that's all the topic here, isn't it? :))

Current guidance from the standards committee is that you should use signed 
integers unless you specifically need modulo-2 overflow.

> > And my answer would be to ban the std containers from Qt entirely and
> > restore support for QT_NO_STL.
> 
> Which is never going to happen since the STL containers are superior in
> performance and code size and we want to use them extensively inside Qt.
> If/how/when expose STL types in our APIs is all to be seen...
> 
> ... can we go back thinking about that?

We can't get QT_NO_STL for more reasons than this. We've deprecated our 
algorithms library, for good reason. With C++11, there are some things you 
just cannot do without the Standard Library, like  and 
.

And yes, we're using the Standard Library containers in our own code.

However, let me also say that our source code is product, so we need to have 
readable code. We *will* trade some performance off for more readable code, 
where "more readable" means Qt-like code that users of our API will 
understand.

So whenever I see a std::erase with nested std::remove_if, I cringe. It's 
highly efficient, but a sore in the eye.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Thiago Macieira]

On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote:
> In the end, your real issue is not with the containers, but with the 
> slowness of the malloc you use. Which means we need faster allocations, not 
> containers that minimize allocations at all costs, including worse
> asymptotic algorithmic complexity.

Adding a slice allocator was part of João's plans back in 2012. That's why 
QArrayData::deallocate receives the object size. (the alignment is for another 
reason)

We never got that far.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

On Wednesday 20 January 2016 16:03:00 Jędrzej Nowacki wrote:
> On Tuesday 19 of January 2016 13:51:56 Marc Mutz wrote:
> > On Tuesday 19 January 2016 11:15:43 Milian Wolff wrote:
> > > On Dienstag, 19. Januar 2016 11:51:42 CET Marc Mutz wrote:
> > > > I missed one:
> > > > 
> > > > On Monday 18 January 2016 23:43:37 Marc Mutz wrote:
> > > > > #include 
> > > > > #include 
> > > > > 
> > > > > int main() {
> > > > > 
> > > > > QVector l;
> > > > > int oldC = l.capacity();
> > > > > for (int i = 0; i < 1000; ++i) {
> > > > > 
> > > > > char buf[std::numeric_limits::digits + 1];
> > > > > sprintf(buf, "%d", i);
> > > > > l.push_back(buf);
> > > > > int newC = l.capacity();
> > > > > if (newC != oldC)
> > > > > 
> > > > > qDebug("%d", newC);
> > > > > 
> > > > > oldC = newC;
> > > > > 
> > > > > }
> > > > > 
> > > > > }
> > > > > 
> > > > > $ time ./test
> > > > > 
> > > > > real0m1.769s
> > > > > user0m1.572s
> > > > > sys 0m0.192s
> > > > 
> > > > Same with std::vector:
> > > > 
> > > > real0m1.776s
> > > > user0m1.616s
> > > > sys 0m0.156s
> > > > 
> > > > > best of three runs, core i7-2720QM, GCC 5.3
> > > > 
> > > > Ditto.
> > > > 
> > > > So... is realloc actually the optimisation everyone (incl. me)
> > > > expected it to be?
> > > 
> > > Did you run it through a profiler? Where is the time actually spent?
> > 
> > No. It's not the IO, though. Removing the qDebug() and capacity tracking,
> > it performs the same, within error margins.
> 
> Hi,
> 
>   I can not reproduce the numbers on gcc version 5.3.1 20151219 (Debian
> 5.3.1-4). But there is a bug in the benchmark, std::vector and QVector have
> different grow model, at least I do not see the same count of qDebug
> messages. In addition I think the benchmark may be affected by heap
> allocation executed on each l.push_back.

That's weird. qAllocMore() uses 2^N-const, const > 0, in my tests, while 
std::vector uses 2^N. I specifically used a count that is a power of 10 so that 
this difference would not cause a different number of reallocations:

1
3
7
15
31
63
127
255
511
1023
2047
4095
8191
16383
32767
65535
131071
262143
524287
1048575
2097151
4194303
8388607
16777215

(for QVector with a movable std::string)

1
2
4
8
16
32
64
128
256
512
1024
2048
4096
8192
16384
32768
65536
131072
262144
524288
1048576
2097152
4194304
8388608
16777216

(for std::vector)

>  The feature is also used in QVariant which tries to avoid allocations.
> That was confirmed as important optimization.

Well, halving the time spent on reallocation is an optimisation, I guess. It's 
just that that particular problem is easily worked around with reserve(). 
QVariant is a different matter, indeed.

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Giuseppe D'Angelo]

Il 20/01/2016 22:25, Kevin Kofler ha scritto:

Marc Mutz wrote:

No-one, not even experts understand QList, really. So it may appear to be
easy to use, but is actually a container only absolute experst should use.


QList gives people who just don't care about the internals something closer
to optimal than any of the containers optimized for a specific use case. The
worst case for QList operations is O(n+m) (for a list of n elements of size
≤ m each), rather than O(n m) as for QVector or std::vector (with the
obvious exception of sorting, which, assuming that 2 elements can be
compared in O(1), is O(m n log(n)) for QVector and std::vector and only
O(n log n) for QList). So I think it is a GOOD class for beginners to use.



This kind of measurement is way too approximative for the real world. 
You should measure quantities that actually make a difference, for 
instance: how many cache misses do you get when doing these various 
operations? How many allocations/deallocations? How big is each allocation?



And a QVector provides exactly the same guarantees as a std::vector. How
come one is easier to use than the other? Because QVector has indexOf()?
And what about those cases where the user wants to find an element by just
a field? They will write for loops, most likely, and not use algorithms.


Sure, algorithms are more flexible in theory, but they are also less
intuitive than a straightforward API such as indexOf. That's the very reason
people are tempted to write loops rather than using algorithms. There's
nothing preventing people from using algorithms on QVector, is there? The
indexOf method surely isn't it.


This poses further questions down the line, such as whether it's "ok" 
having an index API based on signed integers. (It is for convenience, it 
is not for correctness, but I guess that's all the topic here, isn't it? :))




The crucial point here is that there's no "better" Qt API for this than
what exists on std::vector. Instead, there's a much more complicated API
by sheer volume and duplication, without being near extensive enough for
even very simple tasks. At some point, the question must be asked whether
CoW and append() vs. push_back() do not become more of a burden than a
merit. And whether we need three names for size().


What you call "volume", I call "completeness". And most of the "duplication"
is compatibility with the ugly STL names (source compatibility, template
algorithm compatibility). So it's the STL's fault that we have duplication.
Just don't use the ugly STL names, ever. (push_back does not even comply to
Qt naming guidelines. Always use append/prepend/removeLast/removeFirst
instead of push_back/push_front/pop_back/pop_front. And Qt also has a real
pop unlike the misleadingly-named STL one: takeLast/takeFirst.)

And the reason the STL API is horrible is not only the incompleteness, but
also the terse, inconsistent (e.g., std::queue::front vs.
std::priority_queue::top) and misleading (e.g., pop* methods that do not
return the popped element) names.


Renaming a function is not a big deal (heck, we could even provide a 
std::vector subclass with convenience functions! Would that make 
everyone happy?). Having "a real pop" is the consequence of Qt not being 
exception safe. Since you can't build an exception-safe pop that returns 
the popped value, the STL (which cares about exception safety and wants 
containers with the strong guarantee) does not provide pop-and-return 
functions. So, seeing the glass half empty: Qt containers are unsound 
for general-purpose storage.



The main question IMO is how we can bring these two worlds closer
together for Qt 6 (or maybe even to some extent in Qt 5.x).


My answer would be to use std containers exclusively, and write a
wagonload full of Qt-level docs about them, ie. integrate them into the Qt
docs.


And my answer would be to ban the std containers from Qt entirely and
restore support for QT_NO_STL.


Which is never going to happen since the STL containers are superior in 
performance and code size and we want to use them extensively inside Qt. 
If/how/when expose STL types in our APIs is all to be seen...


... can we go back thinking about that?

Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Thiago Macieira]

On Wednesday 20 January 2016 10:48:20 Bubke Marco wrote:
> So let use an airplane as metaphor. We built a fine piston engine airplane
> on that little bit cumbersome piston engine called C++. But now we see Jet
> engines coming up but all our technology is built the old piston engine
> technology so the adaption of jet engines is not that cheap. The jet
> engines are different but we are not sure about their advantages but we are
> sure it would be a big investment to change to them. So people propose
> different designs. Some say we should minimize investments and only apapt
> slowly other proposed to build a hyper mach airplane. 

Let me continue that metaphor.

We build a piston engine airplane while everyone is working on jet engines. 
It's not that you can't use a jet engine on our airplanes, but if you do you 
have to do some conversion wiring and fuel pumps to adapt.

However, while everyone delivers an empty airframe, with no bulkheads or 
seats, our airplanes come with customiseable bulkheads, multiple options of 
seats that you can install and a high quality entertainment system. No one 
else delivers that.

So no, I don't think we risk becoming irrelevant against other airplane makers 
anytime soon. Our competitor are those transatlantic heavyweight ships 
(HTML5).

That is not to say we should stick to piston engines forever. We should 
discuss improving what we have.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Kevin Kofler]

Marc Mutz wrote:
> QString foo() { return QStringLiteral("foo"); }
> QString bar() { return Q3DeepCopy(QStringLiteral("foo")); }
> 
> You will _never_ have the plugin-unloading problem with 'bar', only with
> 'foo', and the reason is CoW: suggesting value semantics where there
> aren't any.

No, the issue is with the specific (ab)use of CoW by QStringLiteral, that 
inserts a pointer to a data segment (rather than to the heap as normal) into 
the CoW container.

Kevin Kofler

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Binding evaluation during ListView delegate remove animation

[Andrew den Exter]

On Thu, Jan 21, 2016 at 2:11 AM, Stephen Kelly 
wrote:

>
> And there are the obvious runtime costs to building and maintaining a
> cache that is of little or no use to most people most of the time, which is
> I think a strong argument for it being an off by default feature if
> implemented.
>
>
> I think the cost would need to be measured before letting it influence
> design decisions. We are not talking about monstrous amounts of data.
>

Famous last words.  I have to assume any cache is going to be pre-populated
with data from every role provided by the model and refreshed every time
dataChanged is emitted for that row, because the views have no knowledge
about what roles a delegate queries until after the fact, and any binding
with a conditional statement in it opens up the possibility that a role
won't be accessed until after the row is removed making on access caching a
flaky solution.  How third parties implement their models and delegates is
a big factor in the potential cost of an effective cache, a model with many
roles and costly access to some of those but with a delegate that only
accesses a few in bindings may work fine now, but be absolutely hammered by
an aggressive cache.   And I obviously don't want to see views which don't
hit this relatively rare combination of circumstances pay that cost.


Andrew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Marc Mutz]

On Wednesday 20 January 2016 08:19:04 Thiago Macieira wrote:
> On Wednesday 20 January 2016 08:12:58 André Somers wrote:
> > Where is this qAsConst coming from? When was it introduced? Where is it
> > documented?
> 
> Commit 264c72837d6ff717a248dd180c2dfb45391c6aab, in dev. No api docs.

It was intended as private API for use within Qt. If the sentiment is that it 
should be public, I'll add proper docs.

If the sentiment is also that we should start to discourage the use of 
Q_FOREACH, then I'll add a \note to its docs pointing at qAsConst + range-for.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Smith Martin]

Here is a JIRA task for it:
https://bugreports.qt.io/browse/QTBUG-50548


From: Development  on behalf of Marc Mutz 

Sent: Wednesday, January 20, 2016 11:58 AM
To: development@qt-project.org
Subject: Re: [Development] QStringLiteral vs QLatin1String ,foreach vs for 
range

On Wednesday 20 January 2016 08:19:04 Thiago Macieira wrote:
> On Wednesday 20 January 2016 08:12:58 André Somers wrote:
> > Where is this qAsConst coming from? When was it introduced? Where is it
> > documented?
>
> Commit 264c72837d6ff717a248dd180c2dfb45391c6aab, in dev. No api docs.

It was intended as private API for use within Qt. If the sentiment is that it
should be public, I'll add proper docs.

If the sentiment is also that we should start to discourage the use of
Q_FOREACH, then I'll add a \note to its docs pointing at qAsConst + range-for.

Thanks,
Marc

--
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] What kind of airplane we want to build?

[Bubke Marco]

Hello

After the exciting discussions in the last time with all the energy spend on 
them I want to try to make a short summary.  Maybe we can transform the heat on 
some steam to progress further. ;-)

I think many feel that C++ is rapidly changing. With C++ 17 on the horizon 
there is some excitement but also fear that Qt will not stay relevant if we not 
adapt. But there are arguments too about existing users who would be left in 
the cold we we change to much. 

So let use an airplane as metaphor. We built a fine piston engine airplane on 
that little bit cumbersome piston engine called C++. But now we see Jet engines 
coming up but all our technology is built the old piston engine technology so 
the adaption of jet engines is not that cheap. The jet engines are different 
but we are not sure about their advantages but we are sure it would be a big 
investment to change to them. So people propose different designs. Some say we 
should minimize investments and only apapt slowly other proposed to build a 
hyper mach airplane. 

The metaphor is not perfect but I hope it is productive enough. 

I think the big elephant is the massive move of the processing technology to 
multi cores,  massive multi cores formerly known as GPUs and the new parallel 
mechanism which are proposed to utilize them. Resumable functions, ranges, 
parallel stl and how they all are called. This will change how C++ looks but 
how can we change Qt in that picture to utilize this new technologies. 

I think it would be productive for the discussion to build story of what we 
want to do. A story of the big picture. Maybe as a first step we can show how 
we tackle problems with Qt 5 and what are the proposed technologies in the 
future C++ standard. 

Maybewe see that we don't have to change so much.  Maybe we find out the change 
would be so massive that we cannot call it Qt 6 anymore. There are many maybes 
because the future is uncertain but we handled uncertainty in the past so why 
we should not do it in the future?

I really believe that before we make little changes like the containers etc. we 
have to find a story. A story how the future Qt should look, a story for the 
long run. In my opinion we have to build the story TOGETHER and this story 
should be build on actual experience and measured facts. We should be careful 
about emotions like doubt,  fear or excitement. I think we should be stay calm.

So we can try now this new C++ prototypes, find out how they fit with our 
technology like signal/slots,  CoW etc.. And later if they are getting momentum 
we can provide our magic sauce on top to make our users more productive. 

And if we want change Qt much we have to provide a technology to make the 
adaptation of our users easy and reliable. So the gain should be bigger than 
the cost. I think Clang based technologies provide us some possible tools but 
we have to find out. It is not only about providing the tool kit for new shine 
projects but for existing ones too. Some maybe they don't want to change and 
that is a respectable decision but for the user who want and need to adapt we 
should make it easy. 

I know this sounds like common sense but after all the discussions in last time 
I think we should step back and get a bigger picture before starting detailed 
discussions again. 

So lets go out,  start prototypes,  gain experience and come back to fruitful 
discussions.  ;-)

--
Sent from cellphone, sorry for the typos
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Ziller Eike]

> On Jan 19, 2016, at 10:40 PM, Marc Mutz  wrote:
> 
> On Tuesday 19 January 2016 19:56:38 Mathias Hasselmann wrote:
>> Am 19.01.2016 um 15:21 schrieb Ziller Eike:
 On Jan 19, 2016, at 16:09, Marc Mutz  wrote:
 I doubt many people actively use the fact that Qt containers are cheap
 to copy.
>>> 
>>> Each and every developer that uses Qt uses the fact that Qt containers
>>> are cheap to “copy"
>>> 
>>> class A
>>> {
>>> 
>>> public:
>>> QVector something() const;
>>> 
>>> private:
>>> QVector m_something;
>>> 
>>> };
>>> 
>>> QVector A::something() const
>>> {
>>> 
>>> return m_something;
>>> 
>>> }
>> 
>> Good point Eike, thank you.
>> 
>> Marc, wow would one avoid invocation of the copy constructor here?
>> Without handing out pointers or references. Of course.
> 
> It's funny how the same people who think nothing of the per-element memory 
> allocation of QList suddenly become vehement performance critics when it 
> comes 
> to CoW :)

Well, passing around a list and doing something based on its elements happens a 
lot more than actually constructing lists.

But the point is not that you cannot write efficient code with std containers, 
but that changing from CoW to non-CoW _will_ potentially effect basically all 
existing Qt based code.
Even if only N% of the uses are actually noticeably effected, these still need 
to be found and fixed.
Any fix in the API will require investigating and potentially fixing the 
callers of that API. If a Qt-based product is a library, that responsibility is 
then
pushed to Qt’s customers’ customers.

We still haven’t even managed to automatically test for performance regressions 
in _Qt_, afaik?
I think that the argument that people will notice performance issues that 
matter and fix them, and the rest don’t matter or will be found by some tool, 
is too optimistic.

> It likely just doesn't matter, the rest of the C++ community has been working 
> with containers that don't do CoW for the past 20 years and have survived.
> 
> In those cases where it does matter, you'd return by const-&. Or an 
> array_view. And no, that doesn't restrict your freedom to implement the 
> function in any meaningful way, because you can always keep a caching mutable 
> member to hold the result for the next call to the function (memoisation or 
> however it's called), without any loss except the space required for the 
> member.

That awfully sounds like re-implementing CoW logic by hand everywhere where 
someone providing an API thinks it might be worth the effort.

> What about non-arrays? By the time we get around to all this, there will be 
> no 
> containers other than array-compatible ones left, because nothing else will 
> provide the required speed. And if there are, you can write a _view for 
> those, 
> too.
> 
> -- 
> Marc Mutz > | Senior Software 
> Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> ___
> Development mailing list
> Development@qt-project.org 
> http://lists.qt-project.org/mailman/listinfo/development 
> 
-- 
Eike Ziller, Principle Software Engineer - The Qt Company GmbH
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range

[Knoll Lars]

On 20/01/16 11:58, "Development on behalf of Marc Mutz" 
 wrote:

>On Wednesday 20 January 2016 08:19:04 Thiago Macieira wrote:
>> On Wednesday 20 January 2016 08:12:58 André Somers wrote:
>> > Where is this qAsConst coming from? When was it introduced? Where is it
>> > documented?
>> 
>> Commit 264c72837d6ff717a248dd180c2dfb45391c6aab, in dev. No api docs.
>
>It was intended as private API for use within Qt. If the sentiment is that it 
>should be public, I'll add proper docs.
>
>If the sentiment is also that we should start to discourage the use of 
>Q_FOREACH, then I'll add a \note to its docs pointing at qAsConst + range-for.

+1 to both. Let's encourage people to use range-for and qAsConst instead of 
foreach.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about QCoreApplicationData::*_libpaths

[Milian Wolff]

On Tuesday, January 19, 2016 9:37:39 AM CET Thiago Macieira wrote:
> On Tuesday 19 January 2016 17:48:48 Giuseppe D'Angelo wrote:
> > On Tue, Jan 19, 2016 at 5:07 PM, Thiago Macieira
> > > 
> > wrote:
> > > std::string someString()
> > > {
> > > 
> > > return constexpr_string("foo");
> > > 
> > > }
> >  
> >  "constexpr_string" should very likely return a const std::string, so this
> > 
> > will copy and not move...
> 
> Right, which would make the entire thing pointless.

It should remove a `const std::string&` and then it is not pointless.

-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Marc Mutz]

On Wednesday 20 January 2016 11:48:20 Bubke Marco wrote:
> I think it would be productive for the discussion to build story of what we
> want to do. A story of the big picture. Maybe as a first step we can show
> how we tackle problems with Qt 5 and what are the proposed technologies in
> the future C++ standard. 

For me, Qt always was "the C++ standard library that C++ lacked". Ever since 
Qt 3, it also integrated pretty well with the rest of the standard library. 
That was easy, because pretty much the only thing that the standard library 
had and Qt didn't were the algorithms, and Qt and the STL algorithms 
integrated well. And there were conversion functions for pretty much 
everything to/from std.

We even deprecated our algorithms when we started requiring full C++98 support 
in 5.0.

We used to roll our own atomics, but dropped them in 5.7 when we required 
partial C++11 support. We rolled our own foreach, and now it looks like we're 
dropping it in favour of range-for.

I would like that trend to continue. The likely next candidates are threads, 
futures and locks.

Now that C++ punches out a new standard every three years, I would change that 
into "Qt is the part of the C++ standard library that C++ sill lacks". I would 
like Qt to continue to integrate well with the standard library and phase out 
its own solutions as the standard library catches up.

We have been doing that in the past. It's just as C++ standardisation 
accelerates, so will the need to phase out Qt features that got superseded.

I perceive, however, that for many people, Qt is what makes them forget 
they're working on C++, a language they would not otherwise poke at with a 
long stick. They probably also cannot tolerate writing std::sort(v.begin(), 
v.end()) instead of qSort(v). But Qt is available in D and Python, too, so ... 
why do they use C++ if they so hate it?

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] extending QtMacExtras?

[Sorvig Morten]

> On 18 Jan 2016, at 11:02, René J.V. Bertin  wrote:
> 
> 
> One thing that's really missing from Qt at the moment is a way for an 
> application that is not the foreground application to post a window in the 
> foreground  (cf. also my thread on extending QProcess). To my knowledge this 
> can only be done by forcing the application to the foreground using the same 
> technique also used by the QCocoaIntegration ctor. Crude, but sometimes 
> required.

I still don’t understand what the general-purpose API in Qt would do. Perhaps 
you
should just write a prototype implementation? Though I’m skeptical about adding 
a
complex solution for this issue to Qt. I don’t want to launch a background 
process.

> 
> A variant could take a WId and activate the application owning the 
> corresponding window or widget. I'm not sure to what extent that would be 
> trivial or even possible to implement (Jake? Morten?). It would allow to 
> simulate things that can currently be done (only?) on Unix/X11:

> 1) hand off a request from a foreground application ("A") to a background 
> process or daemon ("D"), providing it a target WId

But if WIds can’t be used in cross-application contexts (which is true for Qt 
on OS X,
they are NSView pointers), then you can’t send them to a background process 
either. (?)

Regards,
Morten
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] OS X SDK set via configure is not used during build (dev branch)

[Tor Arne Vestbø]

Host tools will build with the latest SDK you have, regardless of what 
you pass to -sdk, which may explain what you're seeing.


You don't need to pass an explicit -sdk macosx10.11 though, just skip 
the -sdk argument entirely and make sure your .qmake.* files are wiped.


We should really just remove the -sdk argument and always build with the 
latest SDK. Is there any reason not to?


tor arne

On 13/01/16 02:14, Mikkel Krautz wrote:

On Wed, Jan 13, 2016 at 12:55 AM, Thiago Macieira
 wrote:

On Wednesday 13 January 2016 00:36:14 Mikkel Krautz wrote:

Hi,

I'm currently on 10.10, Yosemite, using Xcode 7.1.1 (as of this writing).

This version of Xcode only ships with the 10.11 SDK. But I am on 10.10.

When I built Qt (dev branch), by passing -sdk macosx10.11 -- the only
SDK I have -- to configure, I get build failures.

Inspecting the compiler flags, I see that the OS X 10.10 SDK is being
used (-isysroot, etc.).


Remove all .qmake.{cache,super} files you may have. The build stores the
version of the SDK it found when you first ran qmake and won't check again.
This wasn't a problem in the past because Apple used to provide the same SDK
for more than one version of Xcode, so you were unlikely to upgrade and lose
the SDK you last had.


I am pretty sure I had the files cleaned before trying this, so I tried again:

$ cd qt5
$ git submodule foreach --recursive git clean -dfx -f
$ find . | grep qmake.cache
./qtbase/qmake/cachekeys.h
./qtbase/tests/auto/tools/qmake/testdata/export_across_file_boundaries/.qmake.cache
$ find . | grep qmake.super
$

Building:

$ cd qtbase
$ OPENSSL_LIBS="-L${MUMBLE_PREFIX}/lib -lssl -lcrypto" ./configure
-developer-build -opensource -nomake examples -sdk macosx10.11 -I
${MUMBLE_PREFIX}/include -openssl-linked
$ make

Full output at https://gist.github.com/mkrautz/2041003a8aeb63a792b8

Initially, I had MAKEFLAGS set to -j8.

When I did that, I observed that *some* clang++ invocations correctly
used the 10.11 SDK.

Here's me running "make -j8", right after I ran "make":

https://gist.github.com/mkrautz/d96d5329807addf8abc2

So, some things are using the correct sysroot.


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] What kind of airplane we want to build?

[Bo Thorsen]

Den 20-01-2016 kl. 15:12 skrev Marc Mutz:

On Wednesday 20 January 2016 11:48:20 Bubke Marco wrote:

I think it would be productive for the discussion to build story of what we
want to do. A story of the big picture. Maybe as a first step we can show
how we tackle problems with Qt 5 and what are the proposed technologies in
the future C++ standard.


For me, Qt always was "the C++ standard library that C++ lacked". Ever since
Qt 3, it also integrated pretty well with the rest of the standard library.
That was easy, because pretty much the only thing that the standard library
had and Qt didn't were the algorithms, and Qt and the STL algorithms
integrated well. And there were conversion functions for pretty much
everything to/from std.

We even deprecated our algorithms when we started requiring full C++98 support
in 5.0.

We used to roll our own atomics, but dropped them in 5.7 when we required
partial C++11 support. We rolled our own foreach, and now it looks like we're
dropping it in favour of range-for.

I would like that trend to continue. The likely next candidates are threads,
futures and locks.


It sounds like everyone completely agrees on this. But that doesn't mean 
it has to happen for every single class that might be implemented in STL.



Now that C++ punches out a new standard every three years, I would change that
into "Qt is the part of the C++ standard library that C++ sill lacks". I would
like Qt to continue to integrate well with the standard library and phase out
its own solutions as the standard library catches up.

We have been doing that in the past. It's just as C++ standardisation
accelerates, so will the need to phase out Qt features that got superseded.


I agree with this, but there might be problems with the release cycle of 
Qt here. It's impossible to keep backwards compatibility while we switch 
to new C++ versions. So either the Qt major releases will start 
happening more often, or there are features that will just have to wait. 
Thiagos list of things he has already implemented for Qt 6 is a good 
example of this.



I perceive, however, that for many people, Qt is what makes them forget
they're working on C++, a language they would not otherwise poke at with a
long stick. They probably also cannot tolerate writing std::sort(v.begin(),
v.end()) instead of qSort(v). But Qt is available in D and Python, too, so ...
why do they use C++ if they so hate it?


Why do you think people hate C++? I love C++ but I hate the string 
classes. I like some part of the std containers, I don't like their API.


In the same category of argument, I love Qt, but I hate that we don't 
use exceptions.


Bo Thorsen,
Director, Viking Software.

--
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development