Heh, I assumed he was referring to "Scott the Woz" Scott Wozniak, a vintage-gaming youtuber. I assumed that the GP took a more literal attack on "only one 'Woz'", hile you took a more symbolic "only one engineer of such quality". In the context of Apple, sure "Scott" is Scott Forstall, but that's not necessarily the context.
My first computer was an Apple IIGS and everything since then has been a Mac. "Scott" doesn't bring anyone specific to mind for me. Maybe that connection is automatic for newcomers who immediately think "iPhone" when they hear "Apple."
I had a very long career at Apple. I have also met and spent time with Woz on multiple occasions. I have some bias here.
Possibly my assumption was incorrectly based more on people who actually worked at Apple vs what the normal public thinks of when they hear “Scott” and “Woz” in the context of Apple.
It would make sense that people on the inside would be a lot more aware of him. Forstall was obviously a pretty big name in the community but not to the point of getting a shorthand name like that. And he was mostly forgotten pretty quickly after he left.
This is not exactly right. True, $8B is not earth shattering because of the US's enormous debt. But by removing a potential $8B owner, it is a reduction in demand, and thus a tiny reduction in price. This is literally the first rule of pricing: "supply and demand".
Sure, someone else is on the other side of the deal. But their demand is also satiated at a certain price point. Hell, if they wanted to buy from other sellers then it's not like T bills were not liquid.
Would you say the same if Norway's wealth fund offloaded their $181B? At those scales it would be more likely that it'd be visibly price affecting, and therefore affect the US's ability to borrow at existing cost.
So yes, when you sell your one NVDA, you are reducing demand and thus price. Epsilon, but nonzero.
The difference in performance in the kind of compute workloads I'm interested in are so improved by SIMD/Vector that there isn't even any point evaluating non-RVV hardware.
It makes me sick to see London bragging about this. This is last century technology, and other cities managed to retrofit this just fine, including of course using leaky cable in the tunnels.
That it took 20-30 years longer than everyone else is through absolute incompetence and mismanagement. It would have been in place at least 10 years ago if they hadn't screwed up the RFP that Huawei won.
And it's not even shared infra! Vodafone is WAY behind the other networks.
I have worked with these things. There's no valid excuse for being 20-30 years behind on this.
And it's still not landed! By the time it finally gets to all stations I wouldn't be surprised if it's 40-50 years behind everyone else.
Well the Huawei winning scandal appeared to be real. But also, I wouldn't be surprised.
In any case, as I said I have actual expertise in this area, and exactly none of being 20-50 years late has any technical reasons. I'm not surprised if there the layers of incompetence go deeper and include what you said.
No in this case addressing the accusation is necessary.
I think what's currently been said is sufficient. You need to make a grown up version of the statement "None of that is true", but yes probably best to leave it at that.
Honestly, this being Adafruit, my default assumption is to believe them. Especially with this super vague "please read between the lines because if I actually say something false it'll be libel" accusation.
What do you mean by "move or copy constructor is used when constructing the parameter of foo"?
Nothing is constructed at call time. Check out this example, which compiles just fine, even though Foo is neither copy nor move constructible/assignable: https://godbolt.org/z/Wj57o773d
"&&" is just a type system feature, resolving function polymorphism matching rvalue reference and not lvalue reference. It's not a thing that causes a move.
The call to a move cons/move assign does not happen at call time. When a function taking rvalue reference is called, it can still have two code paths, one that copies the argument, and one that moves it.
All the && does is prevent lvalues from being passed as arguments. It's still just a reference, not a move. Indeed, in the callee it's an lvalue reference.
But yeah, you can statically check if there exists a code path that calls the copy cons/copy assign. But you'll need to check if the callee calls ANY type's copy cons/assign, because it may not be the same type as the passed in obj.
At that point, what even is a move? char*p = smartptr.release() in the callee is a valid move into a raw pointer, satisfying the interface in callee. That's a move.[1] how could you detect that?
[1] if this definition of move offends you, then instead remember that shared_ptr has a constructor that takes an rvalue unique_ptr. The move only happens inside the move constructor.
How do you detect all cases of e.g. return cons(ptr.release()) ? It may even be the same binary code as return cons(std::move(ptr))
Probably in the end shared pointer constructor probably calls .release() on the unique ptr. That's the move.
What the callee does it out of scope. We are talking about a single assignment or construction of a variable. This has nothing to do with tracing execution. It happens at one place, and you can look at the place to see if it is using a copy or move contructor.
When talking C++ move semantics it's easy to talk past each other. So I'm not sure what your claim is. Another commenter said that one can tell if something is moved or not without looking at the body of the callee. Is that what you're saying? Because you can't.
I apologize if you're making a different claim, but I'm not clear on what that is.
Anyway, for my point, here's an example where neither copy nor move happens, which one can only know by looking at the body of the callee: https://godbolt.org/z/d7f6MWcb5
Equally we can remove the use of `std::move` in the callee, and now it's instead a copy. (of course, in this example with `unique_ptr`, it means a build failure as `unique_ptr` is not copyable)
> [assignment or construction of a variable] happens at one place
Not sure what you mean by that. The callee taking an rvalue reference could first copy, then move, if it wants to. Or do neither (per my example above). Unlike in Rust, the copy/move doesn't get decided at the call point.
You can, at one point, statically determine if the (usually const) single ampersand reference function is called, or the rvalue reference function, via standard polymorphism. But that's not the point where the move cons/assign happens, so for that one has to look in the callee.
Calling a function that takes a rref will never use a move constructor to create the parameter. We can statically know that both of your foo functions will not use a move constructor when constructing p.
>By changing only the callee we can cause a move
This move is for constructing t. p still is not constructed with a move constructor.
But then I look at the comments, and it really looks like some people want this.
Now I'm depressed.
reply