[Development] QList

[Marc Mutz]

On 2017-03-29 18:57, Matthew Woehlke wrote:
> On 2017-03-29 11:28, Marc Mutz wrote:
>> Deep-copying does not write to the source object, and any number of
>> cores can share read access for a given cache line, each with its own
>> copy, so deep-copying scales linearly with the number of cores.
> 
> Deep copying is vectorized? Really?

No. Maybe you should read what you're replying to first. The benchmark 
was about concurrent copying from a const vector.

>> On 2017-03-29 16:41, Matthew Woehlke wrote:
>>> On 2017-03-29 07:26, Marc Mutz wrote:
>>>> (I just had to review _another_ pimpl'ed class that contained
>>>> nothing but two enums)
>>> 
>>> ...and what happens if at some point in the future that class needs
>>> three enums? Or some other member?
>> 
>> When you start with the class, you pack the two values into a 
>> bit-field
>> and add reserved space to a certain size. 4 or 8 bytes. When you run
>> out, you make a V2 and add an overload taking V2.
> 
> Um... I'm not even going to comment...

Keyword: inline namespaces. This is the C++ mechanism for API 
versioning. It allows to make that totally transparent. Why you find 
that so odd as to be lacking for words is beyond me.

>> This doesn't mean you should never use pimpl. But it means you
>> shouldn't use it just because you can.
> 
> Well, sure, but that's not how your original comment came across.
[...]
> Performance is not a primary goal of PIMPL. That doesn't mean you 
> should
> *never* use it, or that the goals it does achieve are worthless.

I have given pretty concrete suggestions in the past on when not to use 
it: if your class has no user-settable properties, don't pimpl it. If 
your class contains only two enums, even if you expect more later, don't 
pimpl it. If you construe that as saying "never use pimpl", from the 
author of the Pimp my Pimpl series of articles, then that's your 
problem.

> I think the main reason some many people disagree with you on CoW and
> related subjects is because you put performance above all else,
> including correctness and ease of use.

Interesting. My criticism of CoW is about correctness _and_ performance. 
I have given the iterator-into-copied-container example several times 
now. Correctness issue. I have also said that what I hate most about 
QList is how the memory layout depends on intricate details like the 
machine word size. Correctness issue.

> I know you're going to reply "but if the library doesn't do that, users
> that *do* value performance are SOL". That argument cuts both ways,
> however; if the library doesn't provide ease-of-correct-use, users that
> prefer *that* are equally SOL.

Given that QVector provides the same as std::vector, except exception 
safety, correct value semantics (iterator-into-copy), accurate 
complexity guarantees, move-only payload support, I would really, really 
like to know why QVector is easier to use? Because it has indexOf()? 
Seriously, now?

Thanks,
Marc