Philippe wrote:
> On Sat, 1 Jun 2019 14:36:12 +0200
> André Pönitz <apoen...@t-online.de> wrote:
>
>> So it might make even sense to step back further and start with
>> asking "What should Qt be?" before trying to find out on whether
>> a specific API is poorly designed or not, as that decision depends
>> on the purpose.
>
> I second a recent quote from Lars Knoll :
>
>> Qt has always had a somewhat different philosophy. Make C++ easy to use,
>> no need to use Java. The fact is that 95% of the source code our users
>> write will not be performance critical. You don't want to make the pay
>> the price of having a difficult to use API for those 95% of the code.
>
> And I wish to add: the vast majority of Qt developers I have met, are
> not C++ wizards.
Indeed. One case in point: All this confabulation about move constructors
etc. misses the point that the gain of moving compared to shallow copying
with CoW is typically irrelevant for those 95% of non-performance-critical
code. But using explicit move semantics correctly is significantly harder
and more prone to misuse than using Qt's implicit CoW.
To avoid a deep copy STL-style, you have to use std::move explicitly. To
avoid the deep copy Qt-style, you just assign the Qt container and it will
automatically be just a shallow copy. And the Qt idiom is more flexible
because it does not force you to invalidate the original reference.
(That said, at least there *is* a way to avoid the deep copy in STL now. In
C++98, e.g., returning an STL container from a function was just a no-go.)
And yes, I know that there are corner cases where std::move can help on CoW
types, saving some atomic operations, or even avoiding a detach because the
old reference was invalidated by std::move. But I still would NOT call
incomplete implementation of move semantics a showstopper in a CoW data
structure API (unlike some of the self-proclaimed "C++ wizards" here).
Kevin Kofler
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
