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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
