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