[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