[virgilp]

I developed an optimizing C++ compiler in my youth (one that was actually used in production, not just a pet project). I probably know the actual cost, and also know it may depend on compiler.

But that's not the point - the point is that smart pointers never claimed to be zero-cost abstractions, AFAIK.

[mehrdadn]

> But that's not the point - the point is that smart pointers never claimed to be zero-cost abstractions, AFAIK.

> I mean, who doesn't know that smart pointers can be slower than raw pointers?

Nobody... on what basis? If you're not in that set of people, that doesn't imply the set is small or empty. Googling suggests lots of people have given such advice, and, may I suggest, it's not because they were stupid.

[virgilp]

> Nobody... on what basis?

I don't understand the question (I didn't use the word "nobody"). I stand by the first claim (library writers & ISO C++ commitee never claimed that smart pointers are zero-cost abstractions; so why would people believe that? How did that claim start?).

The second (rhetoric) question... well, of course people would occasionally believe random stuff, for God's sake, we have (non-stupid!) people who believe COVID is a conspiracy. That said - there's no basis in the belief that smart pointers are zero-cost, so it's funny to make a talk "debunking" it - to me it looks similar to a talk that "COVID is real, guys!". I was genuinely surprised this talk is needed. I think if this is really a wide-spread belief, a more insightful talk would be about how it got to be a wide-spread belief :)

[UncleMeat]

Chandler is on the cpp committee and personally said he was surprised by this cost when passing unique ptr as a parameter, as were many on the committee.

So the evidence against your claim is literally within the talk.

[virgilp]

Ok, I guess I'll look at the talk/ didn't know the guy was in the C++ committee. Still, I personally had to fight the other way around - to convince people that "no, smart pointers don't have significant overhead over raw pointers; and the optimizations/ custom smart pointers that you're doing now, to the extent that they have any effect at all, will likely be rendered obsolete by future compiler versions & libraries".

I could understand a CPP committee member expecting a certain compiler to optimize a certain situation; however, the blanket statement that "smart pointer X is zero-cost" is more than strange, given the fact that it's always bound to be implementation-dependent, and there isn't one single C++ compiler (or even a "canonical" one) so that you could make that claim, at all. I find it really suspicious.

[edit] I watched the part of the talk - I think he was a bit surprised that has favorite compiler didn't perform that optimization, and it took him some investigation to see why. I don't think he truly expects smart pointers to be "zero-cost abstractions", I think he was just surprised that his compiler didn't optimize better that particular situation and had to dig in to find why. I still find the whole presentation a bit of a misleading stunt - there _are_ zero-cost abstractions (for some definitions of "cost" of course; and/or in some situations). E.g. in rust [1]. And even in C++ - a local unique_ptr is _probably_ a zero-cost abstraction!

BTW.. in his example - just use move semantics, put the pointer as the 5th argument, and you'll probably have the same runtime cost (ie both the raw pointer and smart pointer methods will compile to same code; since the ABI no longer allows you to pass the raw pointer via registers, it goes to the stack, so you have the additional load that bothered him in the raw pointer case, too).

[1] https://medium.com/ingeniouslysimple/rust-zero-cost-abstract...

[UncleMeat]

> BTW.. in his example - just use move semantics, put the pointer as the 5th argument, and you'll probably have the same runtime cost

He talks about this. C++ doesn't have destructive moves like rust does, which is the root cause of why you cannot make the unique_ptr cost zero. It'd take an ABI change to fix this. This is precisely why the scenario is interesting. A lot of people (including you) thought that "just use move semantics" would solve it.

[virgilp]

Thing is... talks like these give a wide body of application developers ammunition to say "smart pointers are slow, we need to use raw pointers!". Which is incredibly damaging. In many real-life situations, the difference literally doesn't matter (one more memory move? pfft... I'd take the whole complicated, exception-safe function body over knowing that in case of an exception I won't have a memory leak)

There are indeed cases where this sort of difference in performance matters; But those are a vanishingly small group of people; and as far as those people are concerned - they typically look at assembly anyway.

[mehrdadn]

I've been wondering why they don't permit destructor elision after a move into a newly constructed parameter. I have a hard time seeing how this would break reasonable code, and even then, we can probably find a backward compatible workaround (or rely on a compiler flag). Any idea?