[Development] QList

Matthew Woehlke mwoehlke.floss at gmail.com
Wed Mar 29 18:57:44 CEST 2017


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?

> 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...

> 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.

>> What, exactly, do you find objectionable about PIMPL in "modern C++"? It
>> can't be that it's inefficient, because performance was never a goal of
>> PIMPL.
> 
> Performance is always a goal in C++. Even in Qt. Otherwise QRect would
> be pimpled, too.

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 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.

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.

-- 
Matthew




More information about the Development mailing list